Re: CLOSE SESSION failed with SK=5h/INVALID FIELD IN CDB: not harmless?

Thomas Schmitt wrote:
> Hi,
>
> me:
>   
>>> Such a message is rarely harmless.
>>>       
> Jens:
>   
>> Well, that's what I thought, but Andy Polyakov commented here:
>> http://www.mail-archive.com/[email protected]/msg12106.html
>>     
>
> Oh indeed. Now i remember.
> I stepped into that puddle previously.
>
> So for now we count it as harmless.
> It is quite out of suspicion anyway. See below.
>
>
>   
>> smally$ sudo cmp /dev/sr1 /video/oldc_backup.udf ; echo $?
>> /dev/sr1 /video/oldc_backup.udf differ: byte 8585217, line 20010
>> (my command seemed simpler :-) and as effective)
>>     
>
> I wanted to truncate /dev/sr1 to the exact size
> just in case all bytes before match the original
> and trailing trash would cause false alert.
>
>
>   
>> When I read the block from /dev/sr0 what I get back is all-zeroes. The
>> corresponding block on the udf image is full of non-zero data.
>>  the next 2048-byte block following 8585216 on /dev/sr1 is non-zero.
>>     
>
> Ouchers.
> That looks much like a failure of transport or
> drive. 
> It happens far before any Close Session failure
> could spoil it directly, and it is hard to
> imagine how such a final problem should leave
> 8 MB unaltered and spoil a single block of 2048
> bytes.
> If possible try to find out whether there are
> more differing blocks in the image.
>
> It is a bit astounding that a first altered
> block at that address disturbed the UDF tree
> without any error message.
> Did you check your kernel logs already ?
>
>
>   
>>  Spare Area:            65088/65536=99.3% free    
>> Could it be that there was a defect and things were relocated? I don't
>> really know how the spare area is used.
>>     
>
> Actually i never saw it doing any good.
>
> It should be transparent to the reader in any
> case. If the drive hands out logical block 4192
> then this should be the corrected data which
> belong to that address. Any physical address
> change should be hidden from the reader.
>
> It seems the Defect Management had reason to
> exchange some physical blocks. Of course it
> is suspicious if the media shows altered
> blocks afterwards. Normally at least the error
> detection precautions should have indicated
> a failure.
> So this could be a failure of the firmware
> to correctly perform Defect Management.
>
>   
Is it possible that this is caused by a relocated block, and for some 
reason the read is returning the bad block in stead of the relocation? 
In other words, did this mount somehow tell the device to ignore 
relocation? Might this be fixed with only a mount option (which I 
certainly didn't see)?

> On BD-RE i normally disable it in favor of
> triple speed and own MD5 checkreading.
> I have a BD burner and a BD reader drive
> so that with bulk backups i reach nearly
> triple throughput by simultaneaously
> writing and reading.
>   


-- 
E. Robert Bogusta
  It seemed like a good idea at the time


-- 
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]