summary: reading from a CD block device generates spurious errors near the end. These errors prevent reasonable tasks from being done. I think that this behaviour is new with LINUX 2.6. I'm using Fedora Core 3 with kernel 2.6.10-1.770_FC3 on x86_64. I burned a CD from a .iso (you may ignore the details): I used Fedora core 3's Nautilus desktop to burn (rightclick on .iso, choose "Write to Disc..."). -rw-rw-r-- 1 hugh hugh 582391808 Feb 4 19:37 w2k3sp1_1433_usa_x64fre_pro.iso I attempt to check the result. I moved the burnt CD to another drive, then used the command cmp w2k3sp1_1433_usa_x64fre_pro.iso /dev/hdd to test the result. I got what looks like failure: cmp: /dev/hdd: Input/output error [I later tried the same test on Fedora Core 1 with a 2.4 kernel. The drive tested as correct (using device /dev/scd0).] Let's investigate the error: dmesg of error: hdd: media error (bad sector): status=0x51 { DriveReady SeekComplete Error } hdd: media error (bad sector): error=0x30 ide: failed opcode was 100 ATAPI device hdd: Error: Medium error -- (Sense key=0x03) Unrecovered read error -- (asc=0x11, ascq=0x00) The failed "Read 10" packet command was: "28 00 00 04 56 b4 00 00 21 00 00 00 00 00 00 00 " end_request: I/O error, dev hdd, sector 1137360 Buffer I/O error on device hdd, logical block 284340 Buffer I/O error on device hdd, logical block 284341 Buffer I/O error on device hdd, logical block 284342 Buffer I/O error on device hdd, logical block 284343 Buffer I/O error on device hdd, logical block 284344 Buffer I/O error on device hdd, logical block 284345 Buffer I/O error on device hdd, logical block 284346 Buffer I/O error on device hdd, logical block 284347 Buffer I/O error on device hdd, logical block 284348 Buffer I/O error on device hdd, logical block 284349 Buffer I/O error on device hdd, logical block 284350 Buffer I/O error on device hdd, logical block 284351 Buffer I/O error on device hdd, logical block 284352 Buffer I/O error on device hdd, logical block 284353 Buffer I/O error on device hdd, logical block 284354 Buffer I/O error on device hdd, logical block 284355 Buffer I/O error on device hdd, logical block 284356 Buffer I/O error on device hdd, logical block 284357 Buffer I/O error on device hdd, logical block 284358 Buffer I/O error on device hdd, logical block 284359 Buffer I/O error on device hdd, logical block 284360 Buffer I/O error on device hdd, logical block 284361 Buffer I/O error on device hdd, logical block 284362 Buffer I/O error on device hdd, logical block 284363 Buffer I/O error on device hdd, logical block 284364 Buffer I/O error on device hdd, logical block 284365 Buffer I/O error on device hdd, logical block 284366 Buffer I/O error on device hdd, logical block 284367 Buffer I/O error on device hdd, logical block 284368 Buffer I/O error on device hdd, logical block 284369 Buffer I/O error on device hdd, logical block 284370 Buffer I/O error on device hdd, logical block 284371 Buffer I/O error on device hdd, logical block 284372 Let's decode the failing command: 28 00 00 04 56 b4 00 00 21 00 00 00 00 00 00 00 28 opcode: READ(10) [as the message said] [a 10-byte command] 00 Logical Unit = 0, DP0=0, FUA=0, RelAdr=0 00 04 56 b4 Logical Block Address = 284340 00 reserved 00 21 Transfer Length = 33 00 Control 00 00 00 00 00 00 crap??? This is a read request, asking for 33 blocks, starting at block number 284340. The .iso is 582391808 bytes or 284371 blocks of 2k. blocks in .iso - block for start of command == 284371 - 284340 == 31 So 31 good blocks should be found at 284340 on. But the read is for 33 blocks. The request is asking for blocks beyond the end of the .iso. No wonder the request is failing: you cannot read runout blocks! ==> the system should not be reading blocks it was not asked to. Or, if it wants to read them, it should not return an error when the error is for blocks that were not requested. Notice that the error is reported as being on sector 1137360 and block 284340. I'm pretty sure that is is actually on block 284372. ==> the error message ought to have the correct block number, if possible I claim this behaviour is wrong and broken. But how this happens is complicated. Where should the fix be? I now try with dd(1), hoping to control the readahead that is getting us into the runout (cmp probably uses stdio which naturally tries to read large chunks but dd should use unbuffered I/O). [hugh@redclaw hugh]$ dd if=/dev/hdd bs=2048 skip=284340 count=1 of=0 dd: reading `/dev/hdd': Input/output error 0+0 records in 0+0 records out dmesg shows: hdd: media error (bad sector): status=0x51 { DriveReady SeekComplete Error } hdd: media error (bad sector): error=0x30 ide: failed opcode was 100 ATAPI device hdd: Error: Medium error -- (Sense key=0x03) Unrecovered read error -- (asc=0x11, ascq=0x00) The failed "Read 10" packet command was: "28 00 00 04 56 b4 00 00 21 00 00 00 00 00 00 00 " end_request: I/O error, dev hdd, sector 1137360 Buffer I/O error on device hdd, logical block 284340 Notice that even though I specified a count of 1, the failing SCSI command shows a count of 33! This, itself, seems like a bug (perhaps I have UNIX expectations of LINUX). Here's another dd experiment, meant to avoid the dreaded readahead. Attempt to read several blocks, in one read, starting at 284339. It turns out that 284339 is divisible by 11, so we can try to read 11 blocks with the following command: dd if=/dev/hdd bs=22528 skip=25849 count=1 of=0 The command was successful, but only 2048 bytes were read. So the block device is acting like one: it will limit a read to one physical block. Is there any way I can stop this stupid readahead? I say stupid because it causes an I/O error by reading something that I never asked it too. It compounds the mistake by reporting the error as happening on a legitimate block.