On 3 Nov, [EMAIL PROTECTED] wrote:
>>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_.
One might argue that the operating system is allowed to read ahead by
the Yellow Book, as it requires a disc to have readable blocks after
the real ISO 9660 data.
Either way, this problem is caused by mkisofs + cdrecord producing
discs that violate the standard in their default setting.
>>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.
I have never encountered a drive that adds a post-gap. You can easily
verify this by writing two tracks and subtracting the number of
blocks delivered for the first one from the start block of the second
one on the CD. The drives add 2 run-out blocks and then (usually) 150
blocks pre-gap, but never any post-gap. Some older drives (Philips
CDD2000, Yamaha CDR100, the very first Yamaha MMC drives) also generated
a larger pre-gap with 75 blocks in the mode of the previous track at
the beginning if the new track had a different mode, but recent MMC
drives have stopped doing this (I still think the standards require it).
> 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.
The drive cannot know if the application has delivered data for the
post-gap - I guess that's why they don't add more data.
>>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.
DAO is probably less likely to trigger read-errors because there are no
run-out blocks between the last track and lead-out.
Bye, Patrick Ohly
--
[EMAIL PROTECTED]
[EMAIL PROTECTED] (MakeCD related mails)
http://home.pages.de/~Ohly/
http://makecd.core.de/ (MakeCD home page)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
