Re: Announcing cdrskin-0.4.4
Thomas Schmitt wrote:
Hi,
What is it with desire to bypass defect management? I mean I can
perfectly understand Thomas's curiosity, but why would end-user such as
Giulio want it off?
I can squeeze some scenarios out of my phantasy.
Like: 1 hour 40 minutes is too long for a backup window.
That I can accept, I was going to post something similar.
Or: The media are perfect and never ever show any bad spot.
That sounds like a fairy tale.
But i agree that disabling defect management needs
good reasons and skilled handling of the consequences.
So you say "my time is so precious that I must have
faster write at any cost, ... so I can have time to verify afterwards"?
Wearing my scdbackup hat, i object the equivalence of
hardware defect management and a verification which
uses the same means as a future restore run.
Agree, if you want trust you are going to verify the backup anyway.
It's nice to know that the drive cares for error
detection and spare block management. But it is not
overly trustworthy.
I evaluated DVD-RAM a few years ago and found them
less reliable than DVD+RW (with my old LG drive).
I used growisofs-6.0 and the original formatting
which still is:
formatted: 2236704*2048=4580769792
00h(800): 2236704*2048=4580769792
00h(800): 2295072*2048=4700307456
01h(800): 2226976*2048=4560846848
01h(800): 2217248*2048=4540923904
This obviously includes defect management reserves.
At least it ran at 0.7x DVD speed.
Today defect management worked, although terribly slow,
where plain writing yielded a bad burn. Maybe it's
also a matter of drive and firmware.
I would say that the drives have been designed to make writing work,
without adding cost to make them work *well*. The only obvious way to
get the speed up is a full read after write head, which introduces
several cost factors. These drives are being used out of their intended
use pattern, and show it. The user has a choice of solutions, none
really satisfactory.
But as backup programmer i need my own test or i
cannot lean back and smile.
So the argument that one cannot save time by
disabling defect management depends on the
use case.
Ideally a copy of the backup would be held for byte-by-byte verify, and
bad spots (only bad spots) would be rewritten. That assumes that they
CAN be written successfully eventually. All solutions are ugly.
Your opinion wins in many of those cases,
i confess.
such as what would it take for *another* kind of
application.
I begin to ponder how i can convince the libisofs
developers of having a defect list in the ISO formatter.
Possibly they will call me insane.
Good.
I have a reputation to defend.
Have a nice day :)
Thomas
--
E. Robert Bogusta
It seemed like a good idea at the time
Reply to: