propose: change some sense codes handling

[Andriy Gapon]

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