Re: CLOSE SESSION failed with SK=5h/INVALID FIELD IN CDB: not harmless?
Thomas Schmitt wrote:
> Hi,
>
>> /dev/sr1: flushing cache
>> /dev/sr1: closing track
>> /dev/sr1: closing session
>> :-[ CLOSE SESSION failed with SK=5h/INVALID FIELD IN CDB]: Input/output
>>
>
> Such a message is rarely harmless.
> The drive wrote everything but failed
> to finish properly.
>
Well, that's what I thought, but Andy Polyakov commented here:
http://www.mail-archive.com/cdwrite@other.debian.org/msg12106.html
that it was "harmless" though I'm not sure if his comment applies in
this instance.
>> Mount works ok:
>> However, there doesn't seem to be anything there:
>> smally$ ls -a /mnt
>> .
>>
>
> So the file tree was not read properly.
> No chance to verify any data this way.
>
> I see two possible reasons of failure here:
> - MMC which rules the writing of data to the
> media.
> - UDF which rules the reading of file tree
> and the access to file contents.
>
> To check the correctness of the MMC writing
> process, compare the whole media content with
> your image file
> dd if=/dev/sr1 bs=2048 count=20971520 | \
> diff - /video/oldc_backup.udf
>
> If this verifies correctly, then UDF mount
> is to blame. Possibly it does not find its
> superblock.
> For help with UDF checking you will probably
> have to look at some other mailing list.
>
I should have run the command above already. I've done it now and I see:
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)
So again I fired up python so I could easily seek around in the disk and
udf image and read the block at 8585216 (cmp's reported offsets are
origin-1, how annoying eh?).
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
preceding 2048 byte block on both media are full of non-zero data. Now
that I'm on it, I noticed that 8585216 % 64Ki == 0, so this block is
indeed at the start of a Blu-ray block (wikipedia says that BD blocks
are 64KiB).
Exploring further, I noticed that the next 2048-byte block following
8585216 on /dev/sr1 is non-zero. In fact, looking at it I can see that
it is the program header of a windows exe. So it is in fact the logical
start of a file. Strange no? Could it be coincidence? Noting that in the
mediainfo we see:
BD SPARE AREA INFORMATION:
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.
BTW Thomas thanks for the info about xorisso!
--
Jens B. Jorgensen
jbj1@ultraemail.net
Reply to: