Re: How to burn Fedora DVDs to avoid readahead bug?
On Saturday 12 May 2007, D. Hugh Redelmeier wrote:
| From: Gene Heskett <gene.heskett(a)verizon.net>
[It is good style to quote only relevant parts of a message to which
you are replying.]
| I'm totally bumfuzzled here folks, what with all this talk of padding etc.
| AIUI, by definition, the iso IS an image of the disk, in the cases I've
| played with, I have never ever come across an iso that had a mod%2048 of
| other than zero, 2048 being the block size of the iso9660 file system.
That is normal. 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...
| And, in every case where a cd or dvd failed the k3b verify phase, I
have
| been able to grab a copy of kcalc, divide the size of the .iso as it
| exists on my hard drive by 2048 to obtain a 'block count', at which point
| a
|
| dd if=/dev/cdrom BS=2048 count=the_count_above >md5sum
|
| and the result except for one occasion where my burner was actually doing
| an exit stage left, a perfect md5sum for the disk, exactly the same as the
| hard drive file.
1. just because your DVD reader works this way does not mean that other
people's DVD reader works this way. This has been reported by several
folks in this mailing list.
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...
2. the dd you use will produce a file called "md5sum" that
contains
the image of the disk (with luck) and not the hash.
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.
| And the disk of course Just Worked(TM)
|
| So whats all this 'padding' for anyway? AIUI, any padding would break the
| iso9660 file format except that it might be properly ignored due to being
| completely beyond the the reach of the filesystems ken.
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.
It has been explained in this thread: the Linux driver tries to read
ahead past the legitimate content on the DVD. Then it reports I/O
errors when the drive refuses. This is only observed with some
hardware.
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.
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.
The padding is to allow Linux to read past the end of the filesystem
without encountering I/O errors.
How would I like this problem addressed?
- Linux should ignore errors in a read-ahead block unless and until
the "client" actually tries to read the block
Agreed.
- 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?
- drives should implement READ CAPACITY accurately
Amen, but I believe they are getting better in that regard.
- 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.
- .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.
An interesting discussion this, thanks.
--
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)
Q: What is printed on the bottom of beer bottles in Minnesota?
A: Open other end.