Re: vd+rw-tools 7.1, Blu-Ray, and INVALID FIELD IN CDB on session close
Hi,
sorry for not answering earlier.
A mail provider glitch obviously swallowed mails
of february 8.
Summary:
It seems that growisofs is not really bad with
those media, but only ugly.
The failure with cdrskin is hard to explain.
The formatted sizes of the BD-R media differed
between the growisofs run and the xorriso run.
So growisofs did not overburn.
It rather formatted the media to higher capacity
at the expense of less spare blocks.
Check the media by
dd if=/dev/sr1 bs=2K count=12075457 of=/dev/null
and watch for i/o error messages.
If none appear, then the ISO image should be ok.
You should watch out for errors like the one
with cdrskin: early abort long before the end
of media is reached.
I do not expect this to be bound to a particular
burn program. I.e. growisofs or xorriso could
run into the same problem.
------------------------------------------------
Details:
> growisofs
> :-[ CLOSE SESSION failed with SK=5h/INVALID FIELD IN CDB]:
> I'm concerned this error at session close means
> either I am working with marginal media at the
> edges, or that the data was not written 100%
> correctly.
The media is not much under suspicion yet.
You can rely on its error detection codes and
just test whether all written blocks are readable
without i/o error:
dd if=/dev/sr1 bs=2K count=12075457 of=/dev/null
> growisofs:
> 12075457 extents written (23584 MB)
> dvd+rw-mediainfo:
> Track Size: 12075520*2KB
These data did fit on the media.
It was formatted to the maximum capacity with
formatted media: 12088320 blocks.
One can have them unformatted with 12219392
blocks. Formatting may be applied at most once
when the media is still unused.
Unformatted media are faster than formatted
ones because they omit verify-reading during
write. Thus they do not replace bad blocks.
It can be that growisofs is so smart that it even
did chose a formatting that is able to take your
fat image.
> cdrskin
> Track 01: 7 MB written (fifo 99%) [buf 40%] 1.3x.
> cdrskin: FATAL : SCSI error on write(3632,16): [5 21 02] Invalid address
If this was a CD-R[W] or DVD-R then i would say
you suffer from interference of other processes.
This is the typical effect with said media when
read operations occur during write.
But BD-R like DVD+R should be immune to that.
Bad media would rather cause write errors, not
"invalid address".
Was this media used in previous experiments ?
(Somehow pre-spoiled by that ?)
> Then I tried the same command again:
That won't work with the same BD-R, i fear.
> cdrskin: FATAL : SCSI error on write(0,16): [5 21 02] Invalid address
Imediate refusal to write to an address that was
already written. This is normal.
> I tried this same burn with xorriso:
> Written to media : 11717104 sectors at LBA 0
> Writing to '/dev/sr1' completed sucessfully.
xorriso and cdrskin share the same code for
burning.
So if xorriso succeeds where cdrskin fails then
i would believe in random incident problems.
This would well match the theory of external
disturbance. (But the media type does not match.)
> xorriso : FAILURE : Image size 12075443s exceeds free space on media 11826176s
This cannot be the reason why the cdrskin run
failed after only 7 MB.
11826176 blocks is the size of the default
formatting for BD-R media.
growisofs is supposed to apply formatting to
blank BD-R automatically.
cdrskin and xorriso do this only if told so.
You told cdrskin
blank=format_if_needed
so you got the default formatting.
Maximum capacity formatting would be
blank=format_defectmgt_min
No formatting is caused by no blank= option
or by
blank=format_defectmgt_none
> So, capacity issues aside, libburn seems to be doing something right
> that growisofs is doing wrong.
Although i feel flattered by the idea, i must
state that besides the ugly error message your
growisofs media is not yet decided to be bad.
The only hard error in your two posts is the
failure of cdrskin (which does not flatter me
at all).
Regrettably there is no opportunity for dummy
runs with BD-R, and the write method for BD-RE
does not resemble BD-R enough to be a good test.
So you will have to watch your BD-R production
for hints about the circumstances of eventual
failure before the end of the image is written.
Have a nice day :)
Thomas
Reply to: