Re: Announcing cdrskin-0.4.4
> AFAIK stream i/o will not disable defect repair, so this protection
> will still be active
I doubt it does checkread for badly written blocks.
The increased speed indicates we successfully
disabled normal defect management.
If the drive encounters a perceivable error during
write then it may or may not issue a write error
But the extra checking and the replacing is most
probably disabled by stream_recording=on .
> So, if firmware/media accept stream i/o, what would be a good reason
> not to use it?
Bad spots. :))
We explore an unusual region of the MMC landscape.
Whether it is harmless or not, whether it is usable
or not, has still to be found out.
You are the test pilot. Congrats. :))
We know meanwhile two ways to get the drive to
full nominal media speed. One permanent and with
any burn program that accepts BD-RE. One run-by-run
via cdrskin stream_recording=on which allows you to
stay with normally formatted BD-RE media.
We do not know what happens if the write operation
to a 64 K cluster goes bad. Neither with half speed
nor with one of our two full-speed tricks.
With full speed you will possibly learn from unusual
long writing time and from some failed MD5.
With half speed ... well i have no idea how good it
does on bad spots.
If the first time a bad spot sabotages a burn run,
then it would be interesting to see whether it
vanishes by a full certification re-format.
This is where i see the most advantage of
stream recording over no-spare formatting.
But first it would be interesting to study the
behavior and consequences of a bad spot.
Does it vanish if one writes to it in normal
half-speed mode for once ?
I guess you are not in a hurry with encountering
bad spots. But if one pops up, then please report.
> What's the difference between "fast defect repair" and "slow defect repair"?
Strictly heuristic classification. These are not
terms of the technical specs but just the grade
of perceived suffering while watching the
(non-)progress of the burn run.
The "slow" one is like my DVD-RAM which seems to
waste a lot of time with unsuccessful write retries
and then finally uses spare blocks.
This lengthens the write time of 125 MB from about
120 seconds without defect to 2025 seconds with
defects. At most 2 percent of the first 125 MB
of the media are bad.
The "fast" one would be swift and not slow down
a burn by several hundred percent if it encounters
a few bad spots.
It would be the one which i expect when paying
substantial money for drive and media.
Have a nice day :)