Damien Le Moal <dlemoal@xxxxxxxxxx> writes: >> This never happens when I am normally using the debian kernel with no >> runtime pm and just running hdparm -y to put the drives to sleep. I can >> check them hours later and they are still in standby. > > Same user space in that case ? Yes. I'll try to leave a blktrace running to see what causes the spinup. I suppose it could be another flush or other command that doesn't require media access, but triggers runtime pm to spin up the disk. > Given your description, that is my thinking exactly. The problem here for the > second part (spinning up the disk for "useless" commands) is that determining if > a command needs the drive to spinup or not is not an easy thing to do, and > potentially dangerous if mishandled. One possible micro optimization would be to > ignore flush commands to suspended disks. But not sure that is a high win change > beside *may be* avoiding a spinup on system suspend witha drive already runtime > suspended. One of the things my patch series from a decade ago did was to use the SLEEP flag in libata to decide to complete certain commands without sending them to the drive so it could remain asleep. I'm not sure if it's even possible for the driver to evaluate the command before the pm core orders a resume though. I wonder if libata could leave the EH pending and return success from the runtime resume, and then actually run the EH and wake up the drive later, when actual IO is done. On another note, I've been looking over your patches, and I still do not understand why you added the VERIFY command. The only effect it seems to have is moving the delay while the drive spins up from the first real IO to the resume path. Why does that matter?
