Bug 136986 - cdrecord pads data written to SCSI CD-RW
cdrecord pads data written to SCSI CD-RW
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: cdrtools (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-24 16:32 EDT by Allen Kistler
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-11-09 22:42:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Allen Kistler 2004-10-24 16:32:33 EDT
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.
Comment 1 Harald Hoyer 2004-10-25 06:49:58 EDT
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.
Comment 2 Allen Kistler 2004-10-25 22:44:39 EDT
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.
Comment 3 Harald Hoyer 2004-10-26 04:42:21 EDT
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!??
Comment 4 Allen Kistler 2004-11-09 22:42:12 EST
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.

Note You need to log in before you can comment on or make changes to this bug.