In kernel 2.0.32 the IDE and SCSI CDROM drivers behave differently at
the end of data on a CDROM. The IDE driver returns an I/O error. The
SCSI driver returns the end of file.
For example, on IDE this fails with an I/O error:
10:18:33 [3] ~ root-l29$ md5sum /dev/hda
md5sum: /dev/hda: I/O error
While it will complete normally on SCSI:
[root@cray /root]# md5sum /dev/scd0
f474d26e7bac5b755b4ac261947bd89c /dev/scd0
[root@cray /root]# dd if=/dev/scd0 | md5sum
1275728+0 records in
1275728+0 records out
f474d26e7bac5b755b4ac261947bd89c -
Of course, it's easy enough to buffer programs from the I/O error on
IDE devices using dd:
11:01:38 [5] ~ root-l29$ dd if=/dev/hda | md5sum
dd: /dev/hda: I/O error
1275724+0 records in
1275724+0 records out
0aa766e51134fe1cc1750380e45ae32d -
Also, note that the number of records read is slightly different. The
SCSI driver successfully reads 318932 2K blocks and the IDE driver
reads 318931 2K blocks (the I/O error presumably coming on block
318932).
Shouldn't the SCSI and IDE drivers be consistent in handling this?
That would make sense, if possible.
There's logic in the SCSI CD-ROM driver to catch this case and return EOF
rather than an I/O error (though a CD-ROM I/O error is still logged by the
kernel). According to the SCSI specification, the results of a READ_CAPACITY
command is allowed to be over by up to 75 2KB blocks, so the size saved from
READ_CAPACITY may be wrong. So if an error occurs within 75 blocks of the end,
it is assumed that the size is wrong, and we correct the size and return EOF.
See sr.c for the details. I have no idea what the specs are for IDE/ATAPI
CD-ROMs.
Leonard