>From: [EMAIL PROTECTED] (Bill Davidsen)
>> >From: "W. Michael Petullo" <[EMAIL PROTECTED]>
>>
>> >I have been burning CD-R media using cdrecord 1.9 and Linux 2.4.0-test*
>> >(through test10) for some time now successfully. I am using a Yamaha
>> >CRW4416S on a card supported by the aic7xxx driver.
>>
>> >Recently I have come across a file that seems to cause cdrecord to fail
>> >on my platform. Normally, I have been burning filesystem trees with
>> >no files larger than a few megabytes. What is uncharacteristic about
>> >the filesystem I am now burning is that it contains a long QuickTime
>> >file; 469MB.
>>
>> >I use mkisofs 1.9 to generate an ISO 9660 filesystem. The filesystem
>> >checks out okay versus the source directory when I use md5sum to compare
>> >files.
>>
>> >However, after burning, the same md5sum check fails. I have tried
>> >varying parameters such as the burn speed. Could the large file size
>> >be causing my problem? Or perhaps something else? Is this something
>> >that should be brought up with Jens Axboe or Doug Gilbert?
>>
>> This is most likely the Linux read-ahead bug.
>??? 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?
This is the reason, why I assume that the read ahead bug is causing the problem.
In this case, usually mounting the image checks OK while mounting
the CD gives problems. BTW: another check could easily verify the read-ahead bug.
if mounting the CD on Solaris (execpt Solaris 7 FCS) is OK too, then
you definitely hit the read ahead bug.
>If he has no trouble making big CDs full of little files I have no
>suggestions, but if it only happens when the total iso filesize being
>burned is large, it may well be a {hard,firm}ware problem in the burner.
>I've seen this before, I think you noted that a cleaning of the guide
>rail (I added a microdot of non-gumming oil) addresses the issue in many
>cases. I've done that on several units since.
Now we are probably seing some probability effects:
- The read ahead bug will not hit on all CD's
if the size of the CD is a multiple of the
kernel buffer size nothing bad happens.
- If you have many small files, only one (the very last on CD)
is affected. If you don't check all files you don't
realize that there is a problem.
- If you only have one big file, _this_ file would be affected.
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]
