Re: smartd causing SATA timeouts on sleeping drives

[Tejun Heo <htejun@gmail.com>]

Andrew Paprocki wrote:
> On 10/10/07, Tejun Heo <htejun@gmail.com> wrote:
>> Maybe what should be done is to track sleep mode in libata and issue
>> SRST automatically if a command is issued to a sleeping drive.  I'll
>> work on it.
> 
> Another tidbit of info.. I just went through the pain of tracking down
> everything in my system (system apps as well as my own code)
> responsible for waking up sleeping drives. My end goal was to make
> sure sleeping drives stayed asleep to reduce power consumption and
> wear due to unnecessary spin-ups. I'm sure distros targeting laptops
> or embedded systems that use live disks go through this pain
> frequently.
> 
> Would all SRST cmds sent from libata come from the ata_std_softreset()
> call? Could something like SystemTap be used without modifying libata
> to track all pids which cause that function to be called? If that
> would work, it could be an easy way to do what I did manually. That
> is, unless someone knows of an easier way that I'm overlooking.. :) I
> might give that a try to see if it works well and document the result.

All resets come from ata_eh_reset() and you can attach probes to it but
the problem is that you can't identify the cause this way.  libata EH
thread would always be the issuing thread.  I think the best way to
track this is to use blktrace and look at which processes issue what
requests.

-- 
tejun