Damien Le Moal <dlemoal@xxxxxxxxxx> writes: > But who is issuing these commands ? If it is systemd/udev, then *that* need to > be patched to avoid it issuing these commands when the drive is sleeping. > Otherwise, there is no end to this. Next time systemd/udev is modified and start > issuing another command, we'll need to ignore that one as well. This is a > dangerous path that I am not willing to accept. I have seen both smartd and udisks2 do this when they attempt to check the SMART status of the drive. They already issue a CHECK POWER MODE command first and skip the SMART read if the drive is in standby, but even this causes a drive that is in SLEEP mode to be woken up. Also filesystems often issue FLUSH CACHE even though they have not written anything to the disk, and there is nothing in the cache. Drives in standby just treat this as a NOOP, but a drive in SLEEP can not. > That would mean having a sysfs attribute indicating that the device is sleeping > though. So the sleep case needs more work. Having a sysfs attribute that smartd/udisks2 could check before issuing CHECK POWER MODE would help that case, but not the FLUSH CACHE case. > As long as you can only set sleep mode with hdparm, there is not much we can do. > hdparm uses passthrough commands, and so handling whatever that tool does in the > kernel becomes a nightmare as libata would need to parse the issued commands and > handle their result. Only a few cases are done now. Extending that would be > difficult and fragile. It already does that. When the SLEEP command is issued, libata sets ATA_DFLAG_SLEEPING. > And yes, please split the series ! One for what you want to do for puis and > another for improved sleep handling. Everything together is simply too confusing. I realized that one of the patches was redundant anyhow, and just finished writing up a good cover letter for the remaining 3. Incoming.
