On 2/2/24 05:01, Phillip Susi wrote: > Damien Le Moal <dlemoal@xxxxxxxxxx> writes: > >> What does not work ? Everything is fine with my testing: the drive is always >> woken up whenever someone (FS, applications etc) issue a block IO (including >> flush) to the block layer. That is the expected behavior. If you want to have >> the disk keep sleeping, the device users must stop poking at the drive. > > It seems that I have put my foot in my mouth. When I first started > working on these patches way back when, I did see flushes without any > writes in the blktrace keeping the drive awake. I assumed that was > still a problem that I needed to tackle. I should have tested it > first. It seems this problem has been fixed already. > > ext4 does still seem to issue a flush with no writes in the sync path > though, causing a drive to spin up for no reason, then right back down > when you suspend-to-ram. I guess I'll ask about this on the ext4 list. > > Circling back to the PuiS patch, did I understand correctly that you are > fine with that as long as it integrates with runtime pm? Yes, but only for drives that report full identify data when PUIS is enabled. For drives that report incomplete identify data, we have no choice but to wake them up. And yes, we need integration with runtime pm to set the initial power state of the drive to standby (instead of "on") for both the ata device and its scsi device. > I had tried at one point to add support for REQUEST SENSE to libata so > that sd can issue that to find out if the disk is powered up or not, and > set the runtime_pm status of the disk accordingly. Does that make sense > to you? I need to check that. I think there may be a better/easier way to get the current power state of a drive. Will get back to you on that. -- Damien Le Moal Western Digital Research
