Re: [smartmontools-support] smartd causing SATA timeouts on sleeping drives

[Bruce A. <ba...@gr...>]

Tejun,

Hmm, it sounds as if smartmontools should send a SRST to spin up the 
drive, but I do not know enough to be sure.

Could I add you to the developers list and give you CVS write access? 
This might make it easier for you to fix the various little smartmontools 
problems like this that keep cropping up!  Just fixing the code might be a 
lot faster than explaining it and sending patches...

If this is OK with you, please send me your sourceforge username, and I'll 
add you to the developers list.

Cheers,
 	Bruce


On Mon, 8 Oct 2007, Andrew Paprocki wrote:

> Yes, the drives were in sleep mode. That is the only case where these
> timeouts/resets occur. It seems like the "-n never" mode of smartd
> should send the SRST if the drive is truly sleeping, otherwise libata
> will soft reset the drive when it sees the timeout. The "-n standby"
> option sounds like a more sane default, but there might be legacy
> reasons why it isn't configured that way.
>
> On 10/8/07, Tejun Heo <ht...@gm...> wrote:
>> Andrew Paprocki wrote:
>>> I found out after posting that this is governed by the -n parameter to
>>> smartd. The default behavior is "-n never" which means smartd will
>>> send the cmds regardless of the drive status. The man page indicates
>>> that may cause the drive to spin-up to answer the cmds. It appears for
>>> some drives (?) the cmds just timeout and libata performs a soft
>>> reset. I'm going to change my setup to "-n standby", but it seems
>>> strange to me that "-n never" is the default if it has this drastic of
>>> a result (at least under Linux). Is there any way to know if the drive
>>> will actually spin up as a result of the cmd instead of timing out?
>>
>> If in standby mode, the drive would automatically spin up to process
>> command.  If in sleep mode, it needs SRST to spin back up.  Was your
>> drive in sleep mode?
>