Damien Le Moal <dlemoal@xxxxxxxxxx> writes: > I did propose to allow for runtime suspend to to use sleep state instead of > standby. That would be fairly easy to do and replace manual "hdparm -Y" with a > well integrated control of the disk power state up to the block layer. > You never commented back about this. That would be nice. I assume that would involve changing how libata-scsi.c translates SYNCHRONIZE CACHE from the scsi layer? > What is this legacy standby timer ? What control path does it trigger ? Do > udisks2/gnome-disk-utility use that timer to issue commands like "hdparm -Y" ? > Or does that timer tigh into the regular runtime suspend ? The ATA disk internal auto standby timer, i.e. hdparm -S. > No. As said many times now, I am not going to do anything about the hdparm -Y > hacking. If a user want better power management features, he/she should enable > power management in their kernels. So you are saying that we need to patch the kernel to make runtime pm work better, then patch smartd and udisks2 to check for runtime pm before issuing their SMART commands, and patch udsisks2 to enable runtime pm rather than using the legacy ATA standby timer? > No. The scsi layer issues a FLUSH CACHE whenever a disk is removed, goes to > sleep or the system shutdown. And there is no need to do that if the disk is > already in standby. If you see that happening, then we need to fix that. I'm almost certain that I have seen this happen, and I don't currently see any code in sd.c that would would prevent it from issuing a FLUSH CACHE to a disk that is runtime suspended when the system suspends or shuts down. The block layer also would need patched to avoid turning a barrier into a FLUSH CACHE if the disk is runtime suspended, and also the sync() path. Is that even sensible to do? It is true that for all block devices, their caches do not need flushed while they are runtime suspended? It seems like it may be, but I'm not certain.
