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
