Red Hat Bugzilla – Bug 136986
cdrecord pads data written to SCSI CD-RW
Last modified: 2007-11-30 17:10:52 EST
Description of problem: I've got a Plextor PX-W4012S SCSI CD-RW drive that I'm trying to use to burn a CD-R. Example: The iso has 332201984 bytes (162208 sectors). cdrecord -dao says it wrote 162208 sectors (without error). dd if=/dev/scd0 of=readback.iso bs=2048 reads in 168956 sectors. That's 6748 extra sectors than what's supposed to be there. hexdump shows that the extra sectors are all zeros. Using cdrecord -tao yields the correct results. I can produce other examples with different numbers, but all to the same effect. Version-Release number of selected component (if applicable): cdrecord-2.01.1-5 How reproducible: Always Steps to Reproduce: 1. cdrecord -dao dev=/dev/scd0 original.iso 2. dd if=/dev/scd0 of=readback.iso bs=2048 3. compare files sizes/sector counts of original and readback Actual Results: Data written to CD is padded compared to iso image. Truncating the extra sectors yields a file identical to the original iso. Expected Results: dd should read back the same iso that was written. Additional info: Kernel version: kernel-2.6.9-1.640smp See also bug 127783 for contrast (dao works, tao doesn't). BTW, I'm not convinced -tao not working there is NOTABUG. FWIW, I have some deep suspicions about the underlying SCSI code that I am unable to quantify more than by example. The bug may lie there rather than with cdrtools.
well, I can only tell DAO/SAO differ from TAO ... $ man cdrecord ... -isosize ... In the second case the option -isosize is needed to prevent cdrecord from reading the two run out blocks that are appended by each CD- recorder in track at once mode. These two run out blocks cannot be read and would cause a buffer underrun that would cause a defective copy. Do not use this option on files created by mkisofs and in case cdrecord reads the track data from stdin.
If I understand correctly the purpose of -isosize is to keep -tao from padding a CD with zeros when it's recorded, if the track size cannot be determined from an iso file size. In this bug, -dao is padding the CD with zeros.
that is very strange, are you really, really sure? normally it's the other way round! -tao pads with zeros, -dao does not. I tried it myself several times... -dao does not pad. Maybe it's your drive that does it wrong!??
Sorry that it's been a while. Yes, I'm absolutely positive that I had it right. I spent/wasted several blanks making sure. For kicks, though, I tried again just now using the same version of cdrecord and kernel-2.6.9-1.649smp. Guess what? No errors with either -tao or -dao. I'll close this bug for now, but my paranoia of the underlying SCSI subsystem remains.