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.
