From: Phillip Susi <phill@thesusis.net>
To: Damien Le Moal <dlemoal@kernel.org>, linux-ide@vger.kernel.org
Cc: Sergey Shtylyov <s.shtylyov@omp.ru>
Subject: Re: [PATCH 1/3] libata: avoid waking disk for several commands
Date: Mon, 08 Jan 2024 08:27:32 -0500 [thread overview]
Message-ID: <878r50uf97.fsf@vps.thesusis.net> (raw)
In-Reply-To: <f6110204-338d-42b5-8ec2-153dd862e799@kernel.org>
Damien Le Moal <dlemoal@kernel.org> writes:
> sleep and standby are different power states. So saying that a disk that is
> sleeping is in standby does not make sense. And if you wake up a drive from
There is no way to answer CHECK POWER MODE and say the drive is in
sleep. It can only be either active, or standby, so standby is the
closest fit. At least it gets smartd and udisks2 to leave the drive
alone.
> The problem here is that ATA_DFLAG_SLEEPING is a horrible hack to not endup with
> lots of timeout failures if the user execute "hdparm -Y". Executing such
> passthrough command with a disk being used by an FS (for instance) is complete
> nonsense and should not be done.
I'm not sure what you propose be done instead. Regardless, this is how
it has always been done, so I don't think there is any changing it now.
You also have the legacy standby timer that is exposed to users through
udisks2/gnome-disk-utility that still has to be supported.
> So I would rather see this handled correctly, through the kernel pm runtime
> suspend/resume:
I'd eventually like to as well, but it should also work in kernels that
aren't built with runtime pm enabled.
> Now, the annoying thing is the drive being randomly woken-up due to commands
> being issued, like the ones you mention. This is indeed bad, and seeing news
> like this:
>
> https://www.phoronix.com/news/Linux-PM-Regulatory-Bugs
>
> I think we really should do better...
That sounds like broken firmware to me. When you ask the firmware to
power off the system, it should really be powered off.
> For FSes issued commands like flush, these are generally not random at all. If
> you see them appearing randomly, then there is a problem with the FS and
> patching the FS may be needed. Beside flush, there are other things to
> consider
I'm not sure the filesystem maintainers will see it that way. They
generally issue barriers as part of a commit at regular intervals, and
that gets turned into FLUSH CACHE. Also the kernel issues one during
system suspend, and I think that happens even if no filesystem is
mounted. I think systemd also issues a sync() during shutdown, which
would wake up a sleeping disk only to shut down.
I don't think it is up to all of these other sources to be patched to
avoid this. libata knows the disk is in sleep mode, so that is the
place to handle it.
> here. Ex: FSes using zoned block devices (SMR disks) doing garbage collection
> while idle. We cannot prevent this from happening, which is why I seriously
> dislike the idea of faking any command for a sleeping disk.
I don't see the connection. If the FS issues IO in the background, the
disk will wake up, just like it does when in standby. The faking of the
commands simply replicates the behavior you get from standby in sleep
mode. With this patch, as far as anyone can tell, a sleeping disk is
exactly the same as one in standby.
next prev parent reply other threads:[~2024-01-08 13:27 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-25 15:19 [PATCH 0/1] Only activate drive once during system resume Phillip Susi
2023-12-25 15:19 ` [PATCH 1/1] libata: only wake a drive once on " Phillip Susi
2023-12-30 18:21 ` [PATCH 0/1 v2] Only activate drive once during " Phillip Susi
2023-12-30 18:21 ` [PATCH 1/1] libata: only wake a drive once on " Phillip Susi
2023-12-30 19:42 ` Sergey Shtylyov
2024-01-02 23:17 ` Damien Le Moal
2024-01-03 21:00 ` Phillip Susi
2024-01-04 1:21 ` Damien Le Moal
2024-01-04 14:05 ` Phillip Susi
2024-01-04 22:39 ` [PATCH 1/4] " Phillip Susi
2024-01-04 22:39 ` [PATCH 2/4] libata: don't wake sleeping disk during system suspend Phillip Susi
2024-01-05 12:25 ` Damien Le Moal
2024-01-05 16:18 ` Phillip Susi
2024-01-04 22:39 ` [PATCH 3/4] libata: avoid waking disk for several commands Phillip Susi
2024-01-05 8:46 ` Sergei Shtylyov
2024-01-05 16:24 ` Phillip Susi
2024-01-05 18:33 ` Sergei Shtylyov
2024-01-06 19:49 ` Phillip Susi
2024-01-06 20:29 ` Phillip Susi
2024-01-08 8:57 ` Sergei Shtylyov
2024-01-05 12:29 ` Damien Le Moal
2024-01-05 16:30 ` Phillip Susi
2024-01-06 23:14 ` Damien Le Moal
2024-01-07 17:57 ` Phillip Susi
2024-01-07 18:02 ` [PATCH 0/3] Let sleeping disks lie Phillip Susi
2024-01-07 18:02 ` [PATCH 1/3] libata: avoid waking disk for several commands Phillip Susi
2024-01-08 6:25 ` Damien Le Moal
2024-01-08 13:27 ` Phillip Susi [this message]
2024-01-10 2:39 ` Damien Le Moal
2024-01-16 17:06 ` Phillip Susi
2024-01-19 20:43 ` Phillip Susi
2024-01-20 18:08 ` Phillip Susi
2024-01-21 0:37 ` Damien Le Moal
2024-01-21 0:37 ` Damien Le Moal
2024-01-24 16:04 ` Phillip Susi
2024-01-24 21:51 ` Damien Le Moal
2024-02-01 20:01 ` Phillip Susi
2024-02-02 1:08 ` Damien Le Moal
2024-02-02 19:53 ` Phillip Susi
2024-02-02 23:17 ` Damien Le Moal
2024-02-05 19:52 ` Phillip Susi
2024-01-08 8:48 ` Sergey Shtylyov
2024-01-08 13:30 ` Phillip Susi
2024-01-07 18:02 ` [PATCH 2/3] libata: only wake a drive once on system resume Phillip Susi
2024-01-08 6:04 ` Damien Le Moal
2024-01-07 18:02 ` [PATCH 3/3] libata: don't start PuiS disks on resume Phillip Susi
2024-01-08 6:03 ` Damien Le Moal
2024-01-08 13:39 ` Phillip Susi
2024-01-10 2:19 ` Damien Le Moal
2024-01-16 17:13 ` Phillip Susi
2024-01-04 22:39 ` [PATCH 4/4] " Phillip Susi
2024-01-05 8:57 ` Sergei Shtylyov
2024-01-05 12:42 ` Damien Le Moal
2024-01-05 16:44 ` Phillip Susi
2024-01-05 12:13 ` [PATCH 1/4] libata: only wake a drive once on system resume Damien Le Moal
2024-01-05 17:03 ` Phillip Susi
2024-01-06 23:06 ` Damien Le Moal
2024-01-05 12:44 ` Damien Le Moal
2024-01-09 15:20 ` [PATCH 0/1 v2] Only activate drive once during " Niklas Cassel
2024-01-16 17:23 ` Phillip Susi
2024-01-02 22:46 ` [PATCH 0/1] " Damien Le Moal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878r50uf97.fsf@vps.thesusis.net \
--to=phill@thesusis.net \
--cc=dlemoal@kernel.org \
--cc=linux-ide@vger.kernel.org \
--cc=s.shtylyov@omp.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).