(Originally filed as https://bugzilla.redhat.com/show_bug.cgi?id=1013117) (Using the Fedora user-space programs.) Description of problem: Attempting to read an entire track of a CD using dd gets an "Input/output error". The data read is sometimes slightly (2kib) shorter or longer than the data written. The data read matches the initial portion of the data written. Version-Release number of selected component (if applicable): kernel-3.11.1-200.fc19.x86_64 How reproducible: reproducible Steps to Reproduce: (detailed instructions are later in the description) 1. Write a track to a CD-R using wodim using the default (TAO) mode. 2. Eject and reinsert the CD-R to refresh the kernel's information about the disk (see https://bugzilla.redhat.com/show_bug.cgi?id=918200) 3. Read the track using "dd if=/dev/cdrom of=cdrom.track bs=512" Actual results: dd terminates with "dd: error reading ‘/dev/cdrom’: Input/output error" The output file is nearly correct in length and contents, though. Expected results: dd reports no error and always reads contents that exactly match the written contents. Additional info: This appears to be a continuation of the bug reported in https://bugzilla.redhat.com/show_bug.cgi?id=151088 The device names involved are: /dev: lrwxrwxrwx. 1 root root 3 Sep 26 15:44 cdrom -> sr0 brw-rw----+ 1 root cdrom 11, 0 Sep 26 15:44 sr0 I believe that this is the read-ahead problem described in the genisoimage manual page: -pad Pad the end of the whole image by 150 sectors (300 kB). [...] The padding is needed as many operating systems (e.g. Linux) implement read-ahead bugs in their filesystem I/O. These bugs result in read errors on files that are located near the end of a track, particularly if the disc is written in Track At Once mode, or where a CD audio track follows the data track. Here is the shell transcript of the problem: $ # Burn CD-R with ISO file system image using TAO mode. $ wodim dev=/dev/cdrom -multi speed=32 fs=32m -v -data burn-fs-isofs.31518 $ eject /dev/cdrom $ # Reinsert the CD-R. $ # Mount and read the CD-R. $ mount /dev/cdrom /mnt/cdrom $ time cp -a /mnt/cdrom cdrom-copy real 4m6.620s user 0m0.011s sys 0m1.600s $ umount /mnt/cdrom $ # Copy the contents of the CD-R track into a file. $ dd if=/dev/cdrom of=cdrom.track bs=512 dd: error reading ‘/dev/cdrom’: Input/output error 1260464+0 records in 1260464+0 records out 645357568 bytes (645 MB) copied, 257.921 s, 2.5 MB/s $ # Verify that the read contents of the track match the file used to burn $ # the CD-R, despite that dd saw a read error. $ cmp burn-fs-isofs.31518 cdrom.track $ # Loopback device mount of the read CD-R track contents. $ mount -o loop cdrom.track /mnt/cdrom $ # Copy the files in the ISO image. $ time cp -a /mnt/cdrom cdrom-copy2 real 0m2.986s user 0m0.008s sys 0m1.155s $ # Verify that the two copies of the files in the ISO image are the same $ # in this instance. $ diff --brief -r cdrom-copy cdrom-copy2 $ umount /mnt/cdrom $
The messages that appear in /var/log/messages are: Sep 27 17:26:27 hobgoblin kernel: [166448.858612] sr 1:0:0:0: [sr0] Unhandled sense code Sep 27 17:26:27 hobgoblin kernel: [166448.858619] sr 1:0:0:0: [sr0] Sep 27 17:26:27 hobgoblin kernel: [166448.858621] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE Sep 27 17:26:27 hobgoblin kernel: [166448.858624] sr 1:0:0:0: [sr0] Sep 27 17:26:27 hobgoblin kernel: [166448.858627] Sense Key : Hardware Error [current] Sep 27 17:26:27 hobgoblin kernel: [166448.858631] sr 1:0:0:0: [sr0] Sep 27 17:26:27 hobgoblin kernel: [166448.858635] Add. Sense: Timeout on logical unit Sep 27 17:26:27 hobgoblin kernel: [166448.858639] sr 1:0:0:0: [sr0] CDB: Sep 27 17:26:27 hobgoblin kernel: [166448.858641] Read(10): 28 00 00 04 ce ba 00 00 34 00 Sep 27 17:26:27 hobgoblin kernel: [166448.858651] end_request: I/O error, dev sr0, sector 1260264 Sep 27 17:26:27 hobgoblin kernel: [166448.858656] Buffer I/O error on device sr0, logical block 157533 Sep 27 17:26:27 hobgoblin kernel: [166448.858665] Buffer I/O error on device sr0, logical block 157534 Sep 27 17:26:27 hobgoblin kernel: [166448.858668] Buffer I/O error on device sr0, logical block 157535 Sep 27 17:26:27 hobgoblin kernel: [166448.858671] Buffer I/O error on device sr0, logical block 157536 Sep 27 17:26:27 hobgoblin kernel: [166448.858675] Buffer I/O error on device sr0, logical block 157537 Sep 27 17:26:27 hobgoblin kernel: [166448.858678] Buffer I/O error on device sr0, logical block 157538 Sep 27 17:26:27 hobgoblin kernel: [166448.858681] Buffer I/O error on device sr0, logical block 157539 Sep 27 17:26:27 hobgoblin kernel: [166448.858684] Buffer I/O error on device sr0, logical block 157540 Sep 27 17:26:27 hobgoblin kernel: [166448.858687] Buffer I/O error on device sr0, logical block 157541 Sep 27 17:26:34 hobgoblin kernel: [166455.617288] sr 1:0:0:0: [sr0] Unhandled sense code Sep 27 17:26:34 hobgoblin kernel: [166455.617294] sr 1:0:0:0: [sr0] Sep 27 17:26:34 hobgoblin kernel: [166455.617297] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE Sep 27 17:26:34 hobgoblin kernel: [166455.617300] sr 1:0:0:0: [sr0] Sep 27 17:26:34 hobgoblin kernel: [166455.617302] Sense Key : Hardware Error [current] Sep 27 17:26:34 hobgoblin kernel: [166455.617307] sr 1:0:0:0: [sr0] Sep 27 17:26:34 hobgoblin kernel: [166455.617311] Add. Sense: Timeout on logical unit Sep 27 17:26:34 hobgoblin kernel: [166455.617314] sr 1:0:0:0: [sr0] CDB: Sep 27 17:26:34 hobgoblin kernel: [166455.617316] Read(10): 28 00 00 04 ce ec 00 00 02 00 Sep 27 17:26:34 hobgoblin kernel: [166455.617326] end_request: I/O error, dev sr0, sector 1260464 Sep 27 17:26:34 hobgoblin kernel: [166455.617330] quiet_error: 17 callbacks suppressed Sep 27 17:26:34 hobgoblin kernel: [166455.617333] Buffer I/O error on device sr0, logical block 157558
The end of a CD-R is not actually precisely defined, which is what causes this. There is a good argument it should be quiet about it, and we do try to be on devices that return the error codes we expect.
(In reply to Alan from comment #2) > The end of a CD-R is not actually precisely defined, which is what causes > this. It sounds as if there is no proper EOF mark on the data. So applications that do not attempt to read beyond the data that is actually written (e.g., when it contains an ISO file system) will succeed, but applications that "read until EOF" will get an I/O error, because the driver can't tell if it has reached EOF or if it has hit a bad part of the media.
Since this problem seems to be unfixable (due to the organization of CD-ROM data), I am marking it as RESOLVED/WILL_NOT_FIX.