> ??? Since he used mkisofs to create the image, and he says the image
> checks, presumably by mounting with a loopback mount and doing an md5sum
> on the files. When he does a burn he is reading from disk and writing to
> CD, and I don't quite see how read-ahead causes a problem, unless you
> use it to do writes?
It would be very worthwhile knowing whether the system's kernel logs
are reporting any evidence of a read error at the end of reading
the data. Usually, the "readahead bug" (to use J�rg's term) results
in an I/O error being logged. It's possible that the md5sum program
doesn't distinguish adequately between "end of file" and "unreadable
file".
In fact, I have a moderately-vague recollection of seeing similar
md5sum mismatches when I did a burn on low-quality unbranded
media, and then tried to read the disc back in my old ATAPI CD-ROM
drive. I don't recall for certain whether the kernel and drivers
were reporting read errors, or were just getting bad data from the
drive... but the symptom I saw was an MD5 mismatch.
It looks to me as if the md5sum source (the GNU version, at least)
does distinguish between end-of-file and read errors... so it may be
that the CD-ROM driver is failing to return the error via the filesystem,
or perhaps the CD-ROM drive is just returning bad data without warning.
On the subject of "readahead bug" - the last time this was discussed
in detail (several months ago), I recall that somebody turned up
some specs which indicate that a CD track is supposed to be padded
out with several blocks (recorded in the same mode, and not including
any significant data) whenever the following track is recorded in a
different mode... and we concluded that the CD's leadout probably
qualifies as a "following track" for this purpose.
Hence, if you make an ISO filesystem which has significant data
up through its last block (i.e. no padding), and burn this to
a disc, and don't include some data-block padding prior to the leadout
or the first audio track, then you may very well be creating a CD-ROM
which is not formally "in spec". It's pretty clear that certain
operating systems (e.g. Linux and FreeBSD) have difficult reading
such discs due to their readahead.
I also suspect that some CD-ROM drives will have difficulty reading such
discs, even if the operating system never tries to read beyond the
"last significant block" in the filesystem.
I had problems like this some years ago on the 3DO videogame system,
working with CD-ROM drives made by MKE (Matsushita / Panasonic).
In this particular case, I *KNOW* for certain that the CD-ROM driver
and the operating / file system were *NOT* reading ahead (since I wrote
all of the code involved).
The problem turned out to be the drive's own firmware, and its management
of the drive readahead buffer. It turned out that if you try to
read the last Mode 1 block on the CD-R, the firmware would gag when it
hit the end of this block and hit the first audio-like block in the
leadout, and it would return bad data or a "mode error" indication
as a result.
I ended up concluding that trying to actually use the last Mode 1 block
on the track for meaningful data was a Bad Idea, modified our
filesystem builder to add a few kilobytes of padding to the
(non-ISO9660) filesystem image, and the problem entirely went away.
So - J�rg - I _strongly_ encourage you to have the "-pad" option
be the default, in the next version of mkisofs - provide a "-nopad"
option for those who really wish to skate close to the edge. I really
do believe that without this padding, mkisofs/cdrecord are writing
CD-ROMs which do not meet the letter of the spec. Although some
operating systems and CD-ROM drives seem to tolerate these disks
just fine, others do not... and if the discs really aren't entirely
to spec, blaming those drives and systems isn't really productive.
At the least, making this change will relieve you of the need to
keep saying "This is the Linux read-ahead bug" and "Refer to
README.copy" every few days ;-)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
