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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
