Re: linux kernel error reading end of cd/dvd
Volker Kuhlmann wrote:
This is caused by reading past the end of written data. You can either
(a) get the size of the ISO filesystem with cdrecord or isoinfo, and
then use dd to read only what's valid, or complain to the creator of the
CD. There's an option which fixes this, from memory -dao.
if anyone is able to shed some more light on this kernel problem I'd
appreciate it. It's been going on for years.
When reading the whole of an iso9660 filesystem from a cd or dvd, I
often get I/O errors within the last blocks of the filesystem. Using
as test is not a good idea, as the kernel often has problems detecting
the end of the recording on the media (however it does that). Also,
reading additional blocks past the end of the filesystem makes it
impossible to use md5 sums. A better way is to obtain the number of
blocks used by the filesystem and reading exactly that many blocks:
isoinfo -d -i /dev/cdrom
dd if=/dev/cdrom bs=2k count=X
(I scripted that a long time ago). In the mid nineties it was necessary
to use cdrecord -pad to make linux read all the files, described as
read-ahead bug in linux's iso9660 driver in the cdrecord man page. When
I checked again a few years ago it was still necessary to use -pad, so
I kept on always using it as a matter of course. This year I find that
cdrecord -pad is no longer enough, and the same problem shows up again.
It affects cds and dvds, and all pressed commercial cds cerated on
non-linux systems. The problem shows up at varying degrees, I suspect
it has to do with the modulus of the number of filesystem blocks of the
particular disk. Several times I was unable to completely read the
filesystem from cds, I/O error 2 or more blocks beore its end no matter
what I did. Often it helps to use dd skip= to only read the last 10
filesystem blocks, and it works. Reading all filesystem blocks from the
beginning, or from a suitably large distance from the end - I/O error.
Sometimes the problem goes away when turning DMA off for the cd/dvdrom
drive, but that is not an acceptable way of running it. I really doubt
it's hardwaredependent, as I have seen it on 3 totally different
machines now. Kernels 2.4.19, 2.4.20. It doesn't help that read
problems on a cd/dvd can cause the IDE bus, if not the system, to lock
up for some time. Appending 2MB of zeroes to the disk image file before
burning makes it disappear reliably. I keep on wasting CDs because I
forget to append that dummy data.
The issue could be explained with the kernel always reading whole
chunks, and that the chunk size was increased somewhere around 2.4.19
with the effect that cdrecord -pad (writing an extra 15 blocks = 30kb)
is no longer sufficient to ensure the last chunk is readable. This is
This state of affairs is not really acceptable. Does anyone know what
the problem is caused by, and what can/should be done about it?
E. Robert Bogusta
It seemed like a good idea at the time