Re: unable to read some of a DVD contents
Hi,
>> - or to compare the data image on DVD with a checksum
> > which was made when that image was written to DVD.
>
> First time heard about this method. How to actually obtain the DVD checksum?
If you got the image stored on disk you may use
program md5sum.
If you generate and burn the image on-the-fly
compute the checksum by a pipe filter. With bash
there is a trick called "Process Substitution"
which would allow to do that by md5sum, too.
On Aug 25 2004, Robert Schiele wrote regarding
a related topic :
: On bash you can do simply:
: $ mkisofs ... | tee >(md5sum) | cdrecord
Ok, it's not that simple but it shows a path.
You will have to record the output of md5sum
as well as the exact size of the image. The
size is important since you will hardly get
an exact EOF from DVD or CD. At least with
CD you need to pad about 300 kB after the
the checksumed image to ensure that the
image can be completely read. (DVD unsure)
So you would need a script which invokes
md5sum, counts the bytes and records them in
some kind of database. Best is if the checksum
gets appended to the image on DVD, too.
In my own project i use a C language program
for that. So i do not have to rely on exotic
>(...) gestures. This also allows additional
stunts. For details see
http://scdbackup.webframe.org/README
search for "Verifying CDs and DVDs" and
"Appendix VERIFY". See also
http://scdbackup.webframe.org/cd_backup_planer_help
for details about some options mentioned in
README.
> Will this method run faster than the first one?
> (We normally have around 10000 files to compare).
It should not be slower. It avoids directory lookups
and random access movements. On my system reading
begins with about 4.8 MB/s and accelerates up to
10 MB/s while computing uses up 30% of an AMD 2600+.
A full DVD verify of 4.7e bytes lasts about
10 minutes if the media is ok. Damaged media are
often quite slow.
> Brief explanation on this method will be appreciated (keen to try this out).
To make it brief would be serious work ;-)
> How did you know there was 300MB data missing at the end of media?
> In our case, the file sizes exactly match the file sizes on the harddrive.
Those sizes are read from the ISO filesystem
directory which is located at the beginning
of the disk. That part of your DVD seems to
be ok. But it refers to data areas which seem
to be damaged.
The missing size was detectable because my
checksum records contain the size measurement
from writing.
In my role as developer of backup software
i am looking for trouble. Therefore i not only
compute a single checksum for the whole backup
but one for each 64 kB of data. So i can
recognize wether the damage forms single spots
or wether it hits wide areas.
(For details see README, Appendix REDUNDANCY)
> > :-[ PERFORM OPC failed with SK=3h/ASC=73h/ACQ=03h]: Input/output error
> Got this problem before upgrading growisofs.
Well, i'm on 5.21. No newer version known.
Also, the problem is restricted to a single disk.
I'll try cdrecord-ProDVD on it next.
It's just for illustration how important a
trustworthy checkread is.
Have a nice day :)
Thomas
Reply to: