Date: Tue, 05 Apr 2011 19:16:01 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Borja Marcos <borjam@sarenet.es> Cc: freebsd-scsi@FreeBSD.org Subject: Re: propose: change some sense codes handling Message-ID: <4D9B4041.4010206@FreeBSD.org> In-Reply-To: <4D9B0DF7.8020104@FreeBSD.org> References: <4D9AF9B7.9030107@FreeBSD.org> <D10B0D62-E11E-445C-B9FA-DB4276F678B0@sarenet.es> <4D9B0DF7.8020104@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
on 05/04/2011 15:41 Andriy Gapon said the following:
> on 05/04/2011 14:30 Borja Marcos said the following:
>>
>> On Apr 5, 2011, at 1:15 PM, Andriy Gapon wrote:
>>
>>>
>>> I propose the following changes:
>>>
>>> - { SST(0x28, 0x00, SS_FATAL | ENXIO,
>>> + { SST(0x28, 0x00, SS_TUR | SSQ_MANY | SSQ_DECREMENT_COUNT | EBUSY,
>>> "Not ready to ready change, medium may have changed") },
>>> In my opinion this condition doesn't really mean a fatal error, but implies that
>>> we should retry while new medium "settles down".
>>
>> As far as I know, this shouldn't be reported by a non-removable media device. It should be used by removable media such as tape units, magneto-optical drives, CDROM drives, WORMs...
>>
>> Many years ago I used to write to SCSI tapes. If the operator changed a tape, for example, while the tape was idle, the next read or write command returned this code, indicating that there was a media change. And it was important indeed, as our application sometimes wrote to tape in relatively small chunks and it only rewound the tape when necessary.
>>
>> So, if the system was expecting a given tape to be in the unit and it tried to write, that try failed reporting a tape change. The software issued a rewind command and read the tape label to ensure that it was the right tape (in which case it issued a seek to the end of the recorded data) or created a new tape label, labelled it, etc etc.
>>
>> Assuming that manufacturers are using it as expected, if this was reported by a removable media random access device (say, a magneto optical disk) it should result in the disappearance of the "changed disk", creation of a new disk. I mean, reread partition table et all, and invalidation of any mount points related to the "disappeared" device.
>>
>>> In my testing this change actually helps with some USB flashdrives and
>>> cardreaders with slow access to media.
>>
>> If a card read reports this, I assume that either the reader has crappy firmware _or_ it has an electrical contact problem with the media. But ignoring this error just could lead to data loss. In the case of a user replacing a memory card with a mounted filesystem, it would be certainly a data loss (blocks intended for one card written to a different card?)
>
> Interesting. Thank you for sharing this information!
> Let me think about it :)
OK. I completely agree with you here.
I think that this sense code should be handled by peripheral drivers where it
makes sense. E.g. da(4) could simply retry a command while at probing stage (i.e.
there was no previous media detected), otherwise "spoil" its previous disk and
probe a new disk.
Thanks for straightening me :)
--
Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D9B4041.4010206>