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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
