Tino Keitel wrote:
> On Mon, Oct 19, 2009 at 22:24:43 +0200, Stefan Richter wrote:
>
> [...]
>
>>> No. All it does is cause an error message to be printed in the system
>>> log. But it's possible that a failure lower down in the SCSI stack has
>>> this effect.
>> I wonder what this might be.
>
> I my case, XFS threw a lot of errors because of an incaccessible device
> and set the filesystem offline.
Perhaps this happens:
- START STOP UNIT does not get through to the disk since
firewire-sbp2 could not reconnect early enough.
- The kernel _does not_ actually care, unlike I thought.
It logs a device resume failure like Alan mentioned, then
goes about its business.
- Linux attempts to use the filesystem and issues read/ write/
whatever requests.
- Spindle motor is still off, disk returns errors.
At this moment, the target should fail these requests with a specific
sense code which tells the SCSI core that another START STOP UNIT is
required now. However, it is just as likely that the target firmware
sends something nonsensical or nothing at all. Or maybe the SCSI core
does even proceed to request START STOP UNIT but the firmware already
went belly-up. Finally, SCSI core gives up and takes the disk offline.
--
Stefan Richter
-=====-==--= =-=- =--==
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
