Re: [PATCH v8 04/23] scsi: sd: Differentiate system and runtime start/stop management

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Damien Le Moal <dlemoal@xxxxxxxxxx> writes:

> Yes. I rechecked the specs regarding this and there is nothing preventing
> IDENTIFY from completing with the drive spun down. The only corner case is when
> PUIS is enabled, in which case IDENTIFY may return incomplete data. But that is
> handled already and that is not something we can get with a system
> suspend/resume or runtime suspend/resume.

It *IS* something we get on suspend/resume.  During suspend the drive
loses power, and on resume, it regains power.  As far as the drive is
concerned, the computer was shutdown and booted back up, so it powers up
in standby.

> From re-reading the specs and testing with all my drives, the port reset spins
> up the drives and IDENTIFY completes OK before the spinup completes, so there
> is no delay.

Interesting.  I was under the impression that most disks have to read
their sererial number and possibly other information from the media in
order to report that in IDENTIFY, and therefore, they would have to
finish spinning up before they could return complete information.

> I CC-ed you a couple of patches that move the VERIFY command
> issuin to after revalidation (so execution of IDENTIFY, READ LOG etc). That
> works well. I also added a CHECK POWER MODE command to check if sending the
> verify is actually needed. And even while the disks are spinning up, I get
> power mode 0xFF indicating ACTIVE state, so no need to send the VERIFY command
> at all. The end result is that we get to finish the libata EH context doing the
> resume well before the disk finishes spinning up (which can take 10+ seconds).
>
> With this, the first read or write command following the resume will be delayed
> until the drive finishes spinning up. But that is fine given the default 30s
> tiemout and retries. I do not expect any problems with that.

That looks very good.  I think I will try to adapt my old patch to allow
the eh to return -EAGAIN and leave the drive in standby rather than
force it to wake up with the VERIFY in the system resume path.  The eh
can be retried later when the drive is actually accessed and that time
it can force it to spin up.



[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux