Re: CLOSE SESSION failed with SK=5h/INVALID FIELD IN CDB: not harmless?
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/cdwrite@other.debian.org/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.
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.
Nevertheless it may also be a failure of
transport. Error detection and verifying
happens only after the data reached the drive.
Well, it would be expensive to make lots of
experiments and to compare the outcome.
But currently i see not much other opportunity
to gain wisdom.
My own experience with BD-R and BD-RE tells me
that they are quite reliable. At least compared
with early DVDs.
So if you need that backup then first try
single layer media. It should be not too
cumbersome to split 37 GB onto 22.5 GB media.
(I could provide my splitting backup program
scdbackup, though.)
Any problem with the bus should show up with
BD-RE as much as with BD-R or BD-R DL.
> BTW Thomas thanks for the info about xorisso!
Google says "Did you mean: xorriso".
That makes me proud. It's now famous enough to
be a proposal in the spelling check. In the
beginning, google proposed "sorriso" instead.
xorriso = X/Open on Rock Ridge enhanced ISO 9660.
Have a nice day :)
Thomas
Reply to: