On 10/3/23 09:27, Phillip Susi wrote: > > Phillip Susi <phill@xxxxxxxxxxxx> writes: > >> I noticed though, that when entering system suspend, a disk that has >> already been runtime suspended is resumed only to immediately be >> suspended again before the system suspend. That shouldn't happen should >> it? > > It seems that it is /sys/power/sync_on_suspend. The problem went away > when I unmounted the disk, or I could make the disk wake up by running > sync. I thought that it used to be that as long as you mounted an ext4 > filesystem with -o relatime, it wouldn't keep dirtying the cache as long > as you weren't actually writing to the filesystem. Either I'm > misremembering something, or this is no longer the case. Also if there > are dirty pages in the cache, I thought the default was for them to be > written out after 5 seconds, which would keep the disk awake, rather > than waiting until system suspend to sync. > > I guess I could mount the filesystem readonly. It's probably not a good > idea to disable sync_on_suspend for the whole system. Hmmm... So this could be the fs suspend then, which issues a sync but the device is already suspended and was synced already. In that case, we should turn that sync into a nop to not wakeup the drive unnecessarily. The fix may be needed on scsi sd side rather than libata. Let me check. -- Damien Le Moal Western Digital Research
