How to burn Fedora DVDs to avoid readahead bug?

[Gene Heskett]

On Sunday 13 May 2007, D. Hugh Redelmeier wrote:
>| From: Gene Heskett <gene.heskett at verizon.net>
>|
>| On Saturday 12 May 2007, D. Hugh Redelmeier wrote:
>| >| From: Gene Heskett <gene.heskett at verizon.net>
>| >
>| >[It is good style to quote only relevant parts of a message to which
>| >you are replying.]
>| >
>| >  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.

The atapi std I think isn't what we should be talking about.  I believe the 
applicable document is known as the "Orange Book"?  And some of it is because 
a legal copy of it costs a lot of real USA $ money.  Standard bodies get 
their income from the publishing of very well protected documents.  I've not 
seen a quote for the Orange book, but one I did inquire about several years 
ago (USB IIRC) was a cool kilobuck, at which point I had a rather profound 
loss of interest in pursuing that path any farther.

>| >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).

I think I have, but didn't recognize it other than a "this damned thing ain't 
workin" observation. :)  Since buying this one I haven't had any seemingly 
similar to this problems.  OTOH, ISTR I also upgraded the burner soft to the 
new non-schily cdtools, which could also have solved 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.

Got an address?  I'd like to send Vinny and Luigi around to have a chat with 
them.

>| >- .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.

That was what I was saying, rather tongue-in-cheek.  In my case a couple of 
times I've retired the drive when it could still make visible tracks on the 
disk.  It still reads other drives disks ok, but it can't read what it wrote.

>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.

Agreed and amen.

>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?

An excellent question, and one that we will never have more than a SWAG number 
to put in front of the % sign because they won't know enough to come here and 
ask.  And everytime it happens, its another black mark against linux in the 
potential users eyes.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Pauca sed matura.
	[Few but excellent.]
		-- Gauss