Hi,
> So the size wish of 23610 MiB got through to the SCSI command that was
> sent to the drive.
> But the drive did not obey.
So this means the drive firmware has a bug and there is nothing which can be done by Unix libs and tools? If so, I would need a new drive.
BTW: Is BD defect management (the reread and compare) done by the drive itself or is it implemented in libburn? It seems to me it does not work with at least growisofs (burn fails unexpected with good quality Verbatim BD-R, the spare range seems to be left untouched).
>> $ dvd+rw-format -ssa=268435456 /dev/sr0
>> ...
>> - illegal command-line option for this media.
>> - BD-R can be pre-formatted only once
> Yeah. Regrettably you will have to wait with further experiments until you
> need to format a BD-R again.
OK, since from what I unterstand I do not need dvd+rw-format anymore when I have migrated to xorriso. Currently I live either with the much too large 768M spare or no spare at all, all formatting done (or none) by growisofs.
Is it a good idea to disable defect management for long term archiving?
> do you feel apt to do a code experiment to disable the fov bit ?
> (i'd tell you from where to get the source and which line to disable.
> you'd need vanilla equipment for c language compiling and linking,
> plus the ability to find and change a line in the code.)
If the source does not have too much dependencies and is not too experimental so I can use it for my long term archiving, this would be wise.
My goal is to use xorriso either without defect management--if this is suggested, or with no more then 256MB spare are. I only burn ready UDF images made with other tools.
But currently it seems that the bug is in the drive firmware?
--Carsten