Damien Le Moal <dlemoal@xxxxxxxxxx> 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.
