Re: How to burn Fedora DVDs to avoid readahead bug?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Saturday 12 May 2007, D. Hugh Redelmeier wrote:
>| From: Gene Heskett <gene.heskett@xxxxxxxxxxx>
>
>[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.


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux