>From: "Dave Platt" <[EMAIL PROTECTED]>
>> ??? 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".
It is not only my terms:
The kernel ingnores the size of the FS and does a prefetch that
includes parts on the media that are not granted to be accessable.
This (complete) IO request which is in fact illegal fails and
the kernel now marks the complete request as unsuccessful.
If the kernel would either only read from that part of the FS that
is a granted part of the FS or verify that parts of the IO request
did not fail there would be no problem.
You see, this is definitely a read-ahead _bug_.
>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.
In TAO mode I assume that the CD-drive is responsible for making sure
that the CD standards are met. This is done with the pre-gap
and I would assume that if there is a requirement for a post gap
it would do also.
>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.
The problem does not occur if the disk is written in DAO mode.
I write all my CD's in DAO mode since about 2 years.
>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.
It is not the CD-ROM but the kernel which send a request that
includes parts of the media that are _not_ part of the FS area.
>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).
I cannot believe this. You should verify your statement.
If I take such a CD and read it with "readcd" I have no problems if I don't
read the run-out sectors.
>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.
This is definitely not true for all drives I own. The problem has been
reproted for several differnt drives and all reporters that I had
written to personally have been able to read the CD using the drive in
question when telling readcd to ommit the last two blocks.
>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
This are OS that are written correctly...
J�rg
EMail:[EMAIL PROTECTED] (home) J�rg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni) If you don't have iso-8859-1
[EMAIL PROTECTED] (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
