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 <htejun@xxxxxxxxx> 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?
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
