Re: DVD+, buffer underrun, write speed and verification issues
Wow, what a well-researched posting! Talk about putting fingers into all
the sore spots...
> I am using a Toshiba SD-R5272 DVD+/-RW drive on an older K6-2 400Mhz
> Linux 2.6.8.1 system (which is even further slowed by the need to
> disable IDE DMA due to hardware issues).
The maximum system throughput without DMA would then be below 1xDVD
speed, by necessity you're relying on buffer-underrun protection in the
burner.
It is my experience on two different systems (P4 2GHz, Duron-600) that
with DMA off, the Linux kernel's time keeping goes haywire (perhaps
because interrupts are getting lost), and the transfer speeds reported
by cdrecord-prodvd (I didn't try growisofs) are twice as what they
should be. You need to check the total burn time against a real wall
clock and not rely on what time the Linux system says has elapsed.
> I do not trust the "burnfree" approach - if I get an underrun during
> recording, I won't trust the disk.)
This approach was justified in the early days of CDs, technology has
become more precise and it's probably ok now. I find it virtually
impossible to not keep up on a P3-450 with DMA burning CDs at 24x, and
the total time it takes is so short I don't care about the 24x, even
though the drive says it would do 52x.
DVDs are much more precise in finding the spot again from which to
continue burning, especially DVD+ which I understand is similar to
DVD-RAM. DVD-RAM effectively goes on nothing but underruns. You needn't
be concerned about engaging underruns with DVDs.
Growisofs unconditionally engages buffer underrun protection, and Andy
is right with his argument that a DVD which is virtually
indistinguishable from one which didn't make use of underrun protection
is better than a coaster. Think of all the users who might get cought
out and annoyed. As Andy says: "technology takes care of that".
> It does not help that this is also in the README:
>
> > IMPORTANT NOTE: DVD+R and DVD+RW are not official DVD formats
> > from the DVD-Forum.
Correct, it does not help. Put it down to Jörg's political agenda to be
on a crusade against DVD+. DVD+ is here to stay, not least because it
has features DVD- isn't ever able to match. Is it still possible to buy
a burner these days which isn't DVD+ as well as DVD-? No doubt about the
format issues being a pain and a half though.
> 1. Do I not have to worry about underruns with growisofs when writing
> to DVD+ media on a slow system?
No need to worry. Just today I yet again had the Linux kernel get stuck
with a fast disk on an older IDE chipset - symptom is that the kernel
spends 90% of the CPU time in some unnecessary wait. It's triggered by
too much disk activity and can only be fixed by a reboot (very
unbefitting to Linux). It happened when being a third into burning a
DVD+RW - transfer speeds were then 0.1x (minimum for +RW is 2.4x). It
took ages, but the disk is fine.
> cmp -b myfile.iso /dev/dvd
Inefficient, as you need to read all the data twice, from 2 different
disks. Use md5sum. Even better, the scripts writecd and md5 in my
scriptutils package will take care of a range of issues for you.
> noting that cmp will encounter the EOF of the image file first as reading
> from /dev/dvd does not complete at the end of the recorded image unless
> the recorded image fills the media entirely (or is it just to the end of
> the next 32k boundary?).
DON'T get me started on this. Linux has a bug in detecting the end of
recording on CDs, and has had since 1.3.x days (hence options -pad in
mkisofs and cdrecord, which are a workaround). The basic problem is
caching and read-ahead engaged by the block driver, which doesn't know
how big the filesystem is. On CDs, the kernel will bomb with an I/O
error even before you have read the end of the filesystem(!!), and also
turn your DMA off because it thinks it has to recover from a fatal
condition). On DVDs I don't remember having an occasion where the kernel
read short, but as you found, it'll read long. My scripts will take care
of it:
md5 -I yourimage.iso (it'll do ext2 as well)
md5 -y /dev/dvdrom yourimage.iso.md5
> IMHO, if you have to read all the bytes anyway, you might as well use cmp.
No, this needs twice the IDE-I/O bandwidth, not what you want on a slow
system.
> md5sum's are the way to go when you want to delete the original image and
> need to verify sometime afterward.
Absolutely! I always keep my yourimage.iso.md5 around. Instant verify
any time after.
> I'd much rather have something like readcd's -c2scan - it is just
> unbelievable that after all that effort to develop DVD writer standards,
> there seems to be no way to verify written data at the lower levels
Yes, it's pathetic. I wonder whether the DVD burner industry thinks Joe
Average couldn't care less about quality, he just wants to burn. I fear
industry is right...
> As it stands now, I am not so confident in the reliability of DVD disks
> for backup applications. It seems so hit and miss: "What do you expect
> from cheap media?" I dunno, I for one expect it to work - how does
> media that cannot record reliably differ from, say, a hockey puck?!
Damn good questions. No matter how much money you spend, you can not buy
media which comes with some kind of guaranteed reliability. This has
also been true for CDs ever since the likes of Kodak stopped producing
their Kodak Gold media some years back. People are simply not prepared
to spend the extra cash. Your best bet is to burn the same image onto
both DVD+R and DVD-R and store them properly (dry, not too warm,
dark(!), in paper sleeves/spindles/jewel cases and not in any plastic
pcokets). I have not seen any indication that this would not last at
least 2 or 3 years. Then, if you don't have too many disks, burn them
onto fresh media periodically if it's really important. Your bigger
problem is to find media for which your burner can work out the correct
burn power. When you have found it, buy enough for 2 years. I don't see
any other remotely cost-effective way. Well you could use a hard disk -
hmmm.
> I have no experience as to how DVD media stands up to real-world use
> (dust, fingerprint accidents, etc.).
Same as CDs.
> I sure would not trust it as the
> only means to store critical data of any sort - even with
> user-land-add-on sector level redundancy.
It's not worse with DVDs than with CDs.
> No offense, but as far as DVD-land goes, what a mess!
Seems like an accurate observation to me!
Volker
--
Volker Kuhlmann is possibly list0570 with the domain in header
http://volker.dnsalias.net/ Please do not CC list postings to me.
Reply to: