| 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. | 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. 2. the dd you use will produce a file called "md5sum" that contains the image of the disk (with luck) and not the hash. | 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. 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. 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. 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 - there should be an ioctl to let a program override the information provided by READ CAPACITY - drives should implement READ CAPACITY accurately - growisofs should accept the pad flag as direction to write padding after an image. - .iso providers (eg. Fedora) should consider padding images them so the unfortunate customers don't need to know this lore
