How to burn Fedora DVDs to avoid readahead bug?

Mon May 14 00:02:25 UTC 2007

| From: Gene Heskett <gene.heskett at verizon.net>

| >  Sun used to use blocksizes of 512 on CDs but I don't
| >know that they ever used them for iso9660 file systems.
| 
| I didn't know there were cd writers that could write that small a block still 
| extant on the planet.  I think I may have a scsi based 4x Hitachi drive in 
| the basement that dates back to around 1997 that might, if it still works.  
| Amazing...

Sun machines originally could only boot from CD drives that defaulted
to 512 byte blocks.  So when I bought my Sparc Classic in 1993, I had
to spend $1000 on a Sun CD drive (1x!).  A little later I got a 3x NEC
CD drive that could do this (under control of a DIP switch).

| I've had lousy luck with optical drives here up until I got a dual layer 
| lightscribe model about 6 months back, but that method did work for the 
| previous 3 drives I had in that slot of a very large tower case.  As long as 
| the drive was working that is, I had 1 that only burnt one disk, but because 
| I wasn't using nero on a winderz box they wouldn't warranty it.  That's twice 
| now that Memorex has screwed me.  But that is not germain to this...

One hopes that newer drives are better.  But they might just be less
expensive and cheaper.

I have had several drives that seemed to need padding.  I have not
kept good notes.

The 2.4 kernel + ide-scsi (remember that?) seemed to behave better.
That's why I think that the kernel is implicated.

Note that my technique has solved the original poster's problem.  So it
is at least on the right track.

| Its been so long since I had to do that that I may miss-remember and used a 
| pipe instead of a redirect.  In any event whatever symbol I did use at the 
| time resulted in md5sum outputting a valid md5sum of the file fed to it.

  dd if=/dev/cdrom BS=2048 count=the_count_above | md5sum

I have used this technique (|, not >) but not recently.  Piping a
whole CD's worth of stuff had a horrible impact on the Linux box's
performance.  I imagine that it displaced all the useful content from the
system's buffer cache.  Some bad kernel policies: it should be obvious
that the content of a pipe should be discarded after it is consumed.

| >Padding does not break an iso9660 filesystem.  It contains information
| >about its extent.  That's what makes isosize(8) possible.  Of course
| >there is a chance that padding might cause the image to be too big for
| >the medium.
| 
| Padding in the context that I might use it in, would be the equ of sending 
| several kilobytes of /dev/zero >>name_of_iso file.  If you are adding data of 
| some kind for use with an iso wrapper, then to me its not padding but data.  
| Data the iso filesystem can't see when its mounted, but data none the less.

What is "an iso wrapper"?

There are layers of representation.  Kind of like layers in
networking.  Inside the .iso is a filesystem conforming to ISO 9660.
Inside that are files.  Inside them are...

A .iso file is something to dump on a writeable drive.  Other things
are added to the burn, before and after either by the sofware or the
firmware.  I refuse to learn all the stuff in the various standards --
too much information that I don't need.  But there is no rule that
says adding zero bytes to the end of a .iso is wrong.

| And I might point out, some older kernel versions.  IIRC that was fixed back 
| at about 2.6.17 or so, but I don't have a handy bible to swear on as to the 
| exact version so I won't argue the point.

Actually, the kernel got worse in this respect when ide-scsi was
dumped.  I don't know of improvement since.  Since you don't observe
the problem, how would you know?

| >As I understand it (I've not checked), the driver does a READ CAPACITY
| >command on the drive and feels it can read ahead up until that size.
| >The problem is that on some drives READ CAPACITY does not yield the
| >precise result needed.  It is unknown to me whether the ATAPI specs
| >require READ CAPACITY to yield what Linux is assuming.  In other
| >words, I know that there is a bug but I don't know whether it is the
| >Linux kernel or the drives that are not following the standards.
| 
| That's one of the reasons, the main one in fact, for burner stuffs like k3b 
| ejecting the disk and reloading it before they start a verify, this is to 
| force the drive/driver to re-read the disk and update the data.  Now if the 
| driver doesn't believe the drive/disk when it says there is only 609 megs of 
| data on a 700 meg disk, then one or the other is out of spec.

You assert this, but I suspect that you've never read the standard
documents.  I'm sure folks have mentioned the problem to drive makers
and no fix has been forthcoming.

READ CAPACITY was invented for SCSI fixed disks.  In that context, it
is like getting the disk sizes from hdparam.  Transferring this
concept efficiently to CDROMs might not be feasible -- would you want
the drive to actually have to read to the end of the burned data to
find out how much there is?

I very carefully said that I expect either the Kernel or the drives
are wrong.  I half expect that the ATAPI standard isn't clear on this.
In which case, the Kernel is wrong for assuming too much.

| >How would I like this problem addressed?

| >- there should be an ioctl to let a program override the information
| >  provided by READ CAPACITY
| 
| And just where would it get the data to override what READ CAPACITY returns?

The program could get the size the way isosize(8) does.  I'd write a
utility that takes the isosize output and uses it to issue the ioctl.
Perhaps the Fedora installation code would do the same.

| >- drives should implement READ CAPACITY accurately
| 
| Amen, but I believe they are getting better in that regard.

I don't have any data on this and I'm sure that you don't (since
you've never observed the problem).

| >- growisofs should accept the pad flag as direction to write padding
| >  after an image.
| 
| That's a crutch IMO, but if it saves a broken drive that would otherwise LOOK 
| as if it had burned a coaster until such time as the laser turns up its toes, 
| I suppose it is usable.

It is a pragmatic approach.  The principled approach is to go read
the standards and bash the appropriate party over the head with them
until that party reforms.

| >- .iso providers (eg. Fedora) should consider padding images them so
| >  the unfortunate customers don't need to know this lore
| 
| Why?  If it demonstrates to the user that his drive/driver is a bit duff and 
| bears carefull watching, eventually one or the other will get fixed.

Drives don't get fixed.  Quite the opposite: they eventually break
seriously and get replaced.

Anyway, it is a small concession to a real problem in the real world.
I wonder how many folks have given up on Linux when their first
experience is with being unable to verify the installation disk.  This
stuff is really really arcane and saving users from having to
understand it is a useful goal.

Every time there is a new release of Fedora, I think there are a few
people on this list that say that they cannot seem to burn a disk that
verifies.  How many just give up without knowing to ask here?  How
many who do ask get told the right advice?