Re: Re: linux kernel error reading end of cd/dvd
Sorry about this being old, but I'm just catching up on the group, and thought this was important should someone be considering rewriting some low-level code... case. One can wonder if the common block buffer could do better job spotting the last addressible sector? Well, yes, but do keep in mind that it's a *common* block buffer, which is not aware of CD technicalities... So that I'd say that it's perfectly legitimate to advice as following. If you really have to checksum the whole image, then make sure to bypass the block buffer *and* provide sane block count value. A. Well, it seems to me that the block driver gets the capacity from the underlying device driver. So if that driver gives the correct capacity to the block layer, things should actually work fine. The question is how to get the device driver to give the correct capacity, if READ CAPACITY doesn't work well enough. I can see two options: 1) Modify ide-cd.c and sr.c to use READ CAPACITY, and then try to read the 75 2k sectors before that. Catch the IO error, and adjust the capacity based on the number of succesfully read sectors. 2) Modify ide-cd.c and sr.c to read the TOC and get the capacity directly from the disc, thus completely circumventing the READ CAPACITY command. Comments? - I vote number 2, if necessary, but why not pass bogus requests through to the drive and then pass the error codes back trans- parently through the command chain? I've always wound up coming back to that simple approach which solves problems that are encountered over time (ie, 2.88 floppies, etc.). A request for size should not necessarily block future requests for large sector numbers just because the driver thinks they're bogus. One should be very careful assuming that a read error marks the end of the readable disk. I frequently encounter errors reading at the end of a CD (usually the last 2 sectors) and have always assumed that this is related to the common misunderstanding (applies also to Hard Drives since the beginning of time) as to the difference between the number of sectors and the number of the LAST sector when the first sector is numbered 0. Disks written by certain mastering programs always require --read-raw (cdrdao) when reading, most don't. My point, though, in this particular discussion is that often the last few sectors of a disk are difficult to read requiring many retries. Sometimes repeated attempts, even through reported hard errors, will succeed; especially on extremely full disks or ones that are overburned, so the driver and/or buffer layers should NOT assume that a read error necessarily indicates the end of the write. Daniel A. Gauthier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: linux kernel error reading end of cd/dvd
Sorry about this being old, but I'm just catching up on the group, and thought this was important should someone be considering rewriting some low-level code... case. One can wonder if the common block buffer could do better job spotting the last addressible sector? Well, yes, but do keep in mind that it's a *common* block buffer, which is not aware of CD technicalities... So that I'd say that it's perfectly legitimate to advice as following. If you really have to checksum the whole image, then make sure to bypass the block buffer *and* provide sane block count value. A. Well, it seems to me that the block driver gets the capacity from the underlying device driver. So if that driver gives the correct capacity to the block layer, things should actually work fine. The question is how to get the device driver to give the correct capacity, if READ CAPACITY doesn't work well enough. I can see two options: 1) Modify ide-cd.c and sr.c to use READ CAPACITY, and then try to read the 75 2k sectors before that. Catch the IO error, and adjust the capacity based on the number of succesfully read sectors. 2) Modify ide-cd.c and sr.c to read the TOC and get the capacity directly from the disc, thus completely circumventing the READ CAPACITY command. Comments? - I vote number 2, if necessary, but why not pass bogus requests through to the drive and then pass the error codes back trans- parently through the command chain? I've always wound up coming back to that simple approach which solves problems that are encountered over time (ie, 2.88 floppies, etc.). A request for size should not necessarily block future requests for large sector numbers just because the driver thinks they're bogus. One should be very careful assuming that a read error marks the end of the readable disk. I frequently encounter errors reading at the end of a CD (usually the last 2 sectors) and have always assumed that this is related to the common misunderstanding (applies also to Hard Drives since the beginning of time) as to the difference between the number of sectors and the number of the LAST sector when the first sector is numbered 0. Disks written by certain mastering programs always require --read-raw (cdrdao) when reading, most don't. My point, though, in this particular discussion is that often the last few sectors of a disk are difficult to read requiring many retries. Sometimes repeated attempts, even through reported hard errors, will succeed; especially on extremely full disks or ones that are overburned, so the driver and/or buffer layers should NOT assume that a read error necessarily indicates the end of the write. Daniel A. Gauthier [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
What value do you call sane - count=N with N = isoinfo -d? Sane block count is obviously the number of last *significant* block. Yes, for mkisofs mastered images the value returned by isoinfo suffices. As long as this sane value can't be obtained easily, even with non-mkisofs-mastered disks, it has little practical use. I never claimed I have all the answers! I just tried to give most accurate definition and applied it to a particular case:-) I checked a few M$-style mass-produced CDs which came with various hardware, and isoinfo -d was identical to df, df output equals to isoinfo -d per definition. I mean df *always* shows same value as isoinfo (provided that we keep talking about single session media:-). It's simply two ways to examine same value, so it does not prove anything. What you should compare it with is lead-out location. all files were readable, Once again. All files being readable is what basically counts. Yes, we have formal right to expect kernel to provide for direct access to /dev/cdrom as well, but only if it's free from technicalities specific to media manufacturing, recorder firmware implementation, player firmware implementation, etc. Bypassing the block buffer and finding sane block count is a way of telling to the system I'll take care of technicalities and I think that we should *just do* that. not necessarily all isoinfo -d blocks (last ones give read error). Then play with programs in mkisofs/diag, make one to print last significant block of file system to figure this one out... The media size can't then be smaller than the filesystem size, For mkisofs mastered images!!! But generally speaking there is nothing preventing you from putting value of 500MB to volume descriptor (value returned by df and isoinfo), having last significant block at 300MB and burn 400MB on the media. The media will be perfectly mountable, all 300MB worth files will be accesible, df will return 500MB and lead-out will be at 400MB... * The SCSI specification allows for the value returned * by READ CAPACITY to be up to 75 2K sectors past the * last readable block. What idiot came up with that idea... ? It's the way CD media is. The catch is that MSF addressing information is smashed across the whole block [in one of those side channels] and transition between two streams (data to lead-out in this case) always has a window of uncertainty. DVD is completely different story. Well, it looks like that's up to the drive's firmware. READ CAPACITY is pretty much useless, since it's allowed to give wrong information. Who said it's wrong? The fact that it's not what you expect it to be in some particular situation doesn't necessarily mean it's wrong! OK, I have to admit that I might have mislead you people by calling it READ CAPACITY as it was a media capacity in respect to read operations, but the fact is that it's just a name of command reading a media capacity, not necessarily in respect to read operations. Does the block-buffer Andy described handle both hard disks and CD/DVDs (I understand yes)? Yes. There never is a problem with reading past the end of a hard disk partition (if there was, things would bomb out all over). Does this mean that in the case of CD/DVDs, the device driver hands a too-large limit up to higher levels? Yes, and under some circumstances it's more or less intentional (e.g. random access DVD+RW), or hard to predict (e.g. CD player can't tell apart media recorded in DAO and TAO, while TAO media is guaranteed(?) to have unaccessible blocks before lead-out). But what makes us human geeks? Ability to adjust to situations! So bypass the block buffer and figure out sane block count in user land:-) Cheers. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
From [EMAIL PROTECTED] Tue Oct 14 18:47:59 2003 If you really have to checksum the whole image, then make sure to bypass the block buffer *and* provide sane block count value. A. Sane block count is obviously the number of last *significant* block. Yes, for mkisofs mastered images the value returned by isoinfo suffices. Not if this is e.g. a Solaris boot CD. Note that last part of the statement reads as for *mkisofs* *mastered* images. Is Solaris boot CD image mastered with mkisofs? I can't confirm it is, at least not Solaris 8 (strings reveal MakeDisc ver. 1.20). May be wrong for S 8 FCS, but who is talking about things outdated for a long time? Since January 2000, Solaris CDs are made with mkisofs. mkisofs -B on the other hand does cover SPARC boot block[s] by value returned by isoinfo. But even if ISO9660 partition of Solaris boot CD was prepared with mkisofs, there're UFS partitions which are surely appended by *separate* means and therefore resulting layout can hardly be classified as *mastered* with mkisofs. In other words I'm not convinced that my statement doesn't hold true. Sane block count is still the last *significant* block even for Solaris boot CD. And as long as output from mkisofs is fed *immediately* to recording program, value returned by isoinfo is suitable for discussed purposes. A. Why don't you first read README.sparcbot before starting to guess? Mkisofs is able to create a Sun disk partition table. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
From: Lourens Veen [EMAIL PROTECTED] If set to (A2) the P-MIN, P-SEC and P-FRAC fields specify the beginning of the Lead-out Track, thus the address of the first Section of the Lead-out Track. The TOC basically consists of a list of records, each of which specifies a track number and a start address in min:sec:frac format (with a fraction being 1/75th of a second). The last element in the list describes the start of the Lead-out, as quoted above. Now the interesting bit is that this is actually section-accurate, and that each section holds one block (ie 2k) of data. Also note that the last readable block before the Lead-out is at address_of_lead_out - 1. At any rate, unless I missed something, the amount of readable blocks is actually stored on the CD, and the number is accurate. Interesting point! If you have a multi session disk, then bad things may happen if the OS reads more then 150 kB bejond a session end ad the read capacity command returns the end of the last session. If the OS fails because it tries to read more than 150 kB bejond an ardess that is listed as part of the used media, then it is broken. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
From: Andy Polyakov [EMAIL PROTECTED] df output equals to isoinfo -d per definition. I mean df *always* shows same value as isoinfo (provided that we keep talking about single session media:-). It's simply two ways to examine same value, so it does not prove anything. What you should compare it with is lead-out location. This may be true for single session disks, but for multi session disks either of both output may be nonsense. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
From: Andy Polyakov [EMAIL PROTECTED] Disregard this comment! Yes, there is a window of uncertainty, but not as big as 75 blocks! These 75 blocks is most likely reservation for the fact that player unit has no way to tell apart media recorded in DAO and TAO or something in that style. Yet this allow for 75 blocks thing doesn't really have something to do with SCSI itself. It has everything to do with media recording process[es], which just happened to be reflected in SCSI specification in such way. So if you ought to look for an idiot, relevant SCSI working group would be the last place to look:-) A. 75 blocks exist nowhere in a seek related paper The basic position accuracy (without starting to read!) for a CD player must be 2 seconds (150 sectors). This is why at least 150 sectors of lead out are required to prevent the drive from hitting the outer barrier. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
mkisofs -B on the other hand does cover SPARC boot block[s] by value returned by isoinfo. But even if ISO9660 partition of Solaris boot CD was prepared with mkisofs, there're UFS partitions which are surely appended by *separate* means and therefore resulting layout can hardly be classified as *mastered* with mkisofs. In other words I'm not convinced that my statement doesn't hold true. Sane block count is still the last *significant* block even for Solaris boot CD. And as long as output from mkisofs is fed *immediately* to recording program, value returned by isoinfo is suitable for discussed purposes. A. Why don't you first read README.sparcbot before starting to guess? And why don't you ever *read* what's written? Mkisofs is able to create a Sun disk partition table. Did I say that mkisofs can't create Sun disk paritition table? Can anybody point at the sentence in my post which would say that? I did *not* say that, but rather opposite! I said that if SPARC bootable image is prepared with mkisofs, then SPARC boot block[s] (or partition[s] if you wish) appear *within* the value returned by isoinfo [even though they are not referenced to from ISO9660 directory structure]. And I implied that this is distinct from layout I've observed on original Sun media(*). All this means that I actually *tried* and *verified* that if I follow the instructions in README.sparcboot and get X sectors large bootable image, isoinfo *still* reports X sectors. Which in turn means that the original statement that isoinfo output can be used as sane block count for images mastered *with* *mkisofs* holds true *even* for SPARC bootable images. A. (*) On original Sun media the value reported by isoinfo is noticeably smaller than track size. But I do get almost the track size if I sum up the value returned by isoinfo and sizes of those UFS bootable partitions, which makes me conclude that UFS partitions were appended to ISO9660 image by means other than mkisofs -B command line. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
mkisofs -B on the other hand does cover SPARC boot block[s] by value returned by isoinfo. But even if ISO9660 partition of Solaris boot CD was prepared with mkisofs, there're UFS partitions which are surely appended by *separate* means and therefore resulting layout can hardly be classified as *mastered* with mkisofs. In other words I'm not convinced that my statement doesn't hold true. Sane block count is still the last *significant* block even for Solaris boot CD. And as long as output from mkisofs is fed *immediately* to recording program, value returned by isoinfo is suitable for discussed purposes. A. Why don't you first read README.sparcbot before starting to guess? And why don't you ever *read* what's written? I did, but you did not read the posting I wrote before. The reason _why_ I mentioned the Solaris boot CD was that isoinfo's outout cannot be used to copy such disk correctly. I *agree* that you can *not* use isoinfo output to copy the *original* Solaris media as it's delivered from Sun. But I maintain that *if* *I* *myself* prepare a SPARC bootable image with mkisofs -B on *my* system and just burn it, then I'll be prefectly able to use isoinfo output to copy such disk correctly. Can you really refute this statement? Can you really confirm that after *you* complete all the steps in README.sparcboot, value returned by isoinfo will differ from actual size of the image file? A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
On Wed 15 October 2003 16:19, Joerg Schilling wrote: From: Andy Polyakov [EMAIL PROTECTED] [...] 75 blocks exist nowhere in a seek related paper The basic position accuracy (without starting to read!) for a CD player must be 2 seconds (150 sectors). This is why at least 150 sectors of lead out are required to prevent the drive from hitting the outer barrier. That makes sense. Do you know for sure whether the capacity that is returned by READ CAPACITY is actually supposed (as in according to the SCSI bus spec) to be sector accurate? Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
From [EMAIL PROTECTED] Wed Oct 15 17:26:12 2003 mkisofs -B on the other hand does cover SPARC boot block[s] by value returned by isoinfo. But even if ISO9660 partition of Solaris boot CD was prepared with mkisofs, there're UFS partitions which are surely appended by *separate* means and therefore resulting layout can hardly be classified as *mastered* with mkisofs. In other words I'm not convinced that my statement doesn't hold true. Sane block count is still the last *significant* block even for Solaris boot CD. And as long as output from mkisofs is fed *immediately* to recording program, value returned by isoinfo is suitable for discussed purposes. A. Why don't you first read README.sparcbot before starting to guess? And why don't you ever *read* what's written? I did, but you did not read the posting I wrote before. The reason _why_ I mentioned the Solaris boot CD was that isoinfo's outout cannot be used to copy such disk correctly. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
I *agree* that you can *not* use isoinfo output to copy the *original* Solaris media as it's delivered from Sun. Just had a chance to examine SPARC Solaris 9 DVD. ISO9660 layout appears to be prepared by mkisofs, *but* UFS partitions are clearly appended to iso-image by means *other than* mkisofs -B. Yes, mkisofs was used, but it was not the last program which generated the resulting image. The layout is therefore can't be classified as mastered *with mkisofs* and I still maintain that isoinfo can be used to retrieve sane block count for *any* image mastered with mkisofs. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
What value do you call sane - count=N with N = isoinfo -d? Sane block count is obviously the number of last *significant* block. Yes, for mkisofs mastered images the value returned by isoinfo suffices. As long as this sane value can't be obtained easily, even with non-mkisofs-mastered disks, it has little practical use. I never claimed I have all the answers! I just tried to give most accurate definition and applied it to a particular case:-) I checked a few M$-style mass-produced CDs which came with various hardware, and isoinfo -d was identical to df, df output equals to isoinfo -d per definition. I mean df *always* shows same value as isoinfo (provided that we keep talking about single session media:-). It's simply two ways to examine same value, so it does not prove anything. What you should compare it with is lead-out location. all files were readable, Once again. All files being readable is what basically counts. Yes, we have formal right to expect kernel to provide for direct access to /dev/cdrom as well, but only if it's free from technicalities specific to media manufacturing, recorder firmware implementation, player firmware implementation, etc. Bypassing the block buffer and finding sane block count is a way of telling to the system I'll take care of technicalities and I think that we should *just do* that. not necessarily all isoinfo -d blocks (last ones give read error). Then play with programs in mkisofs/diag, make one to print last significant block of file system to figure this one out... The media size can't then be smaller than the filesystem size, For mkisofs mastered images!!! But generally speaking there is nothing preventing you from putting value of 500MB to volume descriptor (value returned by df and isoinfo), having last significant block at 300MB and burn 400MB on the media. The media will be perfectly mountable, all 300MB worth files will be accesible, df will return 500MB and lead-out will be at 400MB... * The SCSI specification allows for the value returned * by READ CAPACITY to be up to 75 2K sectors past the * last readable block. What idiot came up with that idea... ? It's the way CD media is. The catch is that MSF addressing information is smashed across the whole block [in one of those side channels] and transition between two streams (data to lead-out in this case) always has a window of uncertainty. DVD is completely different story. Well, it looks like that's up to the drive's firmware. READ CAPACITY is pretty much useless, since it's allowed to give wrong information. Who said it's wrong? The fact that it's not what you expect it to be in some particular situation doesn't necessarily mean it's wrong! OK, I have to admit that I might have mislead you people by calling it READ CAPACITY as it was a media capacity in respect to read operations, but the fact is that it's just a name of command reading a media capacity, not necessarily in respect to read operations. Does the block-buffer Andy described handle both hard disks and CD/DVDs (I understand yes)? Yes. There never is a problem with reading past the end of a hard disk partition (if there was, things would bomb out all over). Does this mean that in the case of CD/DVDs, the device driver hands a too-large limit up to higher levels? Yes, and under some circumstances it's more or less intentional (e.g. random access DVD+RW), or hard to predict (e.g. CD player can't tell apart media recorded in DAO and TAO, while TAO media is guaranteed(?) to have unaccessible blocks before lead-out). But what makes us human geeks? Ability to adjust to situations! So bypass the block buffer and figure out sane block count in user land:-) Cheers. A.
Re: linux kernel error reading end of cd/dvd
* The SCSI specification allows for the value returned * by READ CAPACITY to be up to 75 2K sectors past the * last readable block. What idiot came up with that idea... ? It's the way CD media is. The catch is that MSF addressing information is smashed across the whole block [in one of those side channels] and transition between two streams (data to lead-out in this case) always has a window of uncertainty. Disregard this comment! Yes, there is a window of uncertainty, but not as big as 75 blocks! These 75 blocks is most likely reservation for the fact that player unit has no way to tell apart media recorded in DAO and TAO or something in that style. Yet this allow for 75 blocks thing doesn't really have something to do with SCSI itself. It has everything to do with media recording process[es], which just happened to be reflected in SCSI specification in such way. So if you ought to look for an idiot, relevant SCSI working group would be the last place to look:-) A.
Re: linux kernel error reading end of cd/dvd
From: Lourens Veen [EMAIL PROTECTED] If set to (A2) the P-MIN, P-SEC and P-FRAC fields specify the beginning of the Lead-out Track, thus the address of the first Section of the Lead-out Track. The TOC basically consists of a list of records, each of which specifies a track number and a start address in min:sec:frac format (with a fraction being 1/75th of a second). The last element in the list describes the start of the Lead-out, as quoted above. Now the interesting bit is that this is actually section-accurate, and that each section holds one block (ie 2k) of data. Also note that the last readable block before the Lead-out is at address_of_lead_out - 1. At any rate, unless I missed something, the amount of readable blocks is actually stored on the CD, and the number is accurate. Interesting point! If you have a multi session disk, then bad things may happen if the OS reads more then 150 kB bejond a session end ad the read capacity command returns the end of the last session. If the OS fails because it tries to read more than 150 kB bejond an ardess that is listed as part of the used media, then it is broken. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Re: linux kernel error reading end of cd/dvd
From: Andy Polyakov [EMAIL PROTECTED] Disregard this comment! Yes, there is a window of uncertainty, but not as big as 75 blocks! These 75 blocks is most likely reservation for the fact that player unit has no way to tell apart media recorded in DAO and TAO or something in that style. Yet this allow for 75 blocks thing doesn't really have something to do with SCSI itself. It has everything to do with media recording process[es], which just happened to be reflected in SCSI specification in such way. So if you ought to look for an idiot, relevant SCSI working group would be the last place to look:-) A. 75 blocks exist nowhere in a seek related paper The basic position accuracy (without starting to read!) for a CD player must be 2 seconds (150 sectors). This is why at least 150 sectors of lead out are required to prevent the drive from hitting the outer barrier. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Re: linux kernel error reading end of cd/dvd
mkisofs -B on the other hand does cover SPARC boot block[s] by value returned by isoinfo. But even if ISO9660 partition of Solaris boot CD was prepared with mkisofs, there're UFS partitions which are surely appended by *separate* means and therefore resulting layout can hardly be classified as *mastered* with mkisofs. In other words I'm not convinced that my statement doesn't hold true. Sane block count is still the last *significant* block even for Solaris boot CD. And as long as output from mkisofs is fed *immediately* to recording program, value returned by isoinfo is suitable for discussed purposes. A. Why don't you first read README.sparcbot before starting to guess? And why don't you ever *read* what's written? Mkisofs is able to create a Sun disk partition table. Did I say that mkisofs can't create Sun disk paritition table? Can anybody point at the sentence in my post which would say that? I did *not* say that, but rather opposite! I said that if SPARC bootable image is prepared with mkisofs, then SPARC boot block[s] (or partition[s] if you wish) appear *within* the value returned by isoinfo [even though they are not referenced to from ISO9660 directory structure]. And I implied that this is distinct from layout I've observed on original Sun media(*). All this means that I actually *tried* and *verified* that if I follow the instructions in README.sparcboot and get X sectors large bootable image, isoinfo *still* reports X sectors. Which in turn means that the original statement that isoinfo output can be used as sane block count for images mastered *with* *mkisofs* holds true *even* for SPARC bootable images. A. (*) On original Sun media the value reported by isoinfo is noticeably smaller than track size. But I do get almost the track size if I sum up the value returned by isoinfo and sizes of those UFS bootable partitions, which makes me conclude that UFS partitions were appended to ISO9660 image by means other than mkisofs -B command line.
Re: linux kernel error reading end of cd/dvd
mkisofs -B on the other hand does cover SPARC boot block[s] by value returned by isoinfo. But even if ISO9660 partition of Solaris boot CD was prepared with mkisofs, there're UFS partitions which are surely appended by *separate* means and therefore resulting layout can hardly be classified as *mastered* with mkisofs. In other words I'm not convinced that my statement doesn't hold true. Sane block count is still the last *significant* block even for Solaris boot CD. And as long as output from mkisofs is fed *immediately* to recording program, value returned by isoinfo is suitable for discussed purposes. A. Why don't you first read README.sparcbot before starting to guess? And why don't you ever *read* what's written? I did, but you did not read the posting I wrote before. The reason _why_ I mentioned the Solaris boot CD was that isoinfo's outout cannot be used to copy such disk correctly. I *agree* that you can *not* use isoinfo output to copy the *original* Solaris media as it's delivered from Sun. But I maintain that *if* *I* *myself* prepare a SPARC bootable image with mkisofs -B on *my* system and just burn it, then I'll be prefectly able to use isoinfo output to copy such disk correctly. Can you really refute this statement? Can you really confirm that after *you* complete all the steps in README.sparcboot, value returned by isoinfo will differ from actual size of the image file? A.
Re: linux kernel error reading end of cd/dvd
On Wed 15 October 2003 16:19, Joerg Schilling wrote: From: Andy Polyakov [EMAIL PROTECTED] [...] 75 blocks exist nowhere in a seek related paper The basic position accuracy (without starting to read!) for a CD player must be 2 seconds (150 sectors). This is why at least 150 sectors of lead out are required to prevent the drive from hitting the outer barrier. That makes sense. Do you know for sure whether the capacity that is returned by READ CAPACITY is actually supposed (as in according to the SCSI bus spec) to be sector accurate? Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: linux kernel error reading end of cd/dvd
From [EMAIL PROTECTED] Wed Oct 15 17:26:12 2003 mkisofs -B on the other hand does cover SPARC boot block[s] by value returned by isoinfo. But even if ISO9660 partition of Solaris boot CD was prepared with mkisofs, there're UFS partitions which are surely appended by *separate* means and therefore resulting layout can hardly be classified as *mastered* with mkisofs. In other words I'm not convinced that my statement doesn't hold true. Sane block count is still the last *significant* block even for Solaris boot CD. And as long as output from mkisofs is fed *immediately* to recording program, value returned by isoinfo is suitable for discussed purposes. A. Why don't you first read README.sparcbot before starting to guess? And why don't you ever *read* what's written? I did, but you did not read the posting I wrote before. The reason _why_ I mentioned the Solaris boot CD was that isoinfo's outout cannot be used to copy such disk correctly. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Re: linux kernel error reading end of cd/dvd
I *agree* that you can *not* use isoinfo output to copy the *original* Solaris media as it's delivered from Sun. Just had a chance to examine SPARC Solaris 9 DVD. ISO9660 layout appears to be prepared by mkisofs, *but* UFS partitions are clearly appended to iso-image by means *other than* mkisofs -B. Yes, mkisofs was used, but it was not the last program which generated the resulting image. The layout is therefore can't be classified as mastered *with mkisofs* and I still maintain that isoinfo can be used to retrieve sane block count for *any* image mastered with mkisofs. A.
Re: linux kernel error reading end of cd/dvd
Meet the players in the field: - block buffer which provides for read-ahead, I/O requests' slicing and coalescing; - value returned by READ CAPACITY command, hereafter simply READ CAPACITY; - actual lead-out position; Rules of the game (please note that I'm not claiming that I know all the rules in detail:-): - block buffer rearranges I/O depending on *momentary* availability of spare memory, e.g. even if you ask for bs=2k, it may coalesce them to e.g. 126KB chunks, or it may break larger requests to a number of 4KB ones; - no requests are posed beyond the READ CAPACITY; - READ CAPACITY coincides with lead-out position most of the time, *but not always*; - CD lead-out position is documented to be inaccurate [with 75 blocks inaccuracy?], DVD lead-out position is believed to be accurate; - CD lead-out is preceded by few unaccesible blocks (unless disk is recorded in DAO mode?), lead-out itself is unaccesible; Last and middle rules form the ground for I/O errors in general and in read-ahead in particular. The first rule explains why the problem with dd count=X appears to be intermittent. It also makes it impossible to find the magic modulo coefficient, which would predict if any particular combination of bs=, count= and READ CAPACITY is bound to fail or not [as it all depends on *momentary* availability of spare memory]. Bypassing the block buffer naturally makes all the problems with count=sanevalue disappear, as well as makes it possible to accurately and reliably locate the last accessible block. Relevant question is when READ CAPACITY is not equal to lead-out offset? I don't know about CD, but in DVD case most units would report full media capacity for READ CAPACITY under following circumstances: - DVD+RW and DVD-RW Restricted Overwrite(?) media in recorder unit. READ CAPACITY is not associated with lead-out position and equals to full media capacity; - DVD-RW Restricted Overwrite, Incremental DVD-R[W] and DVD+R which were not finalized in first session in legacy DVD-ROM unit. Unit replies with full media capacity (as legacy lead-out points to the outer edge); [- if you [still] have DVD+RW kernel patch applied, it will also *replace* the READ CAPACITY with full media capacity for DVD+R media in recordred unit]; I tried mounting the CD that did not work, and copy all files off of it. No problems there. Note this is not necessarily an indicator that the filesystem is not affected, it only means none of the files are directly affected. But that's basically what should and does count... There are more blocks in a filesystem than just the files' data. If we're talking about ISO9660 layout prepared by mkisofs, then those more blocks are known to be insignificant and you can as well checksum every file instead of the whole filesystem image, can't you? Does it really have to be whole image? But in either case. One can wonder if the common block buffer could do better job spotting the last addressible sector? Well, yes, but do keep in mind that it's a *common* block buffer, which is not aware of CD technicalities... So that I'd say that it's perfectly legitimate to advice as following. If you really have to checksum the whole image, then make sure to bypass the block buffer *and* provide sane block count value. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
Wow! Someone who knows what he's talking about - I'm impressed. - CD lead-out position is documented to be inaccurate [with 75 blocks inaccuracy?] Silly question - where/how? How do you arrive at 75? I have observed the same problem with DVD+R burnt by Nero (different box), reading on the box as previously stated, so I don't think it's limited to CDs - it affects DVDs in the same manner. There are more blocks in a filesystem than just the files' data. If we're talking about ISO9660 layout prepared by mkisofs, then those more blocks are known to be insignificant and you can as well checksum every file instead of the whole filesystem image, can't you? No. Checksumming only files does not checksum (all of) the filesystem's metadata. From an efficiency viewpoint, checksumming files is out of the question. Checksumming the disk is very fast, and independent of the filesystem used. In the case of iso9660, checksumming files may be slower by only a factor of two (sorry can't remember right now), for udf and ext2 you can plain forget about it from a practical perspective. The only fast way of doing it would be to read the whole CD/DVD image to disk, loopmount, check files - might check the disk itself in the first place. Does it really have to be whole image? Yes. And it *ought* to work ;) I ran a number of readcd -c2scan on the CD in question, and found a varying number of errors (and that readcd kills the CPU). No errors at 12x speed, always some at 24x, it also seems to vary with system load. None of the errors are close to the end - all are at 347143 with a filesystem size of 349552. None of the errors are hard read errors. If you really have to checksum the whole image, then make sure to bypass the block buffer *and* provide sane block count value. A. Obvious question ;): is there an easy way to bypass the block buffer? What value do you call sane - count=N with N = isoinfo -d? No point in an N larger than that. Thanks much, Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
- CD lead-out position is documented to be inaccurate [with 75 blocks inaccuracy?] Silly question - where/how? Note the question mark in the [comment]. It means I'm not sure where I read/heard this and I admit that I might be wrong about this:-) How do you arrive at 75? 75 sectors is one second CD-DA, right? I have observed the same problem with DVD+R burnt by Nero (different box), reading on the box as previously stated, so I don't think it's limited to CDs - it affects DVDs in the same manner. Can you confirm that the value returned by isoinfo on Nero mastered disk did not cross the address of lead-out? Then it naturally can vary from one DVD recorder manufacturer to another. What I'm trying to say is that I can't confirm your experience with DVD+R, not with ISO9660 layouts generated by mkisofs. Which is why I wrote DVD lead-out position *is believed* to be accurate. If you really have to checksum the whole image, then make sure to bypass the block buffer *and* provide sane block count value. A. Obvious question ;): is there an easy way to bypass the block buffer? Well, already mentioned readcd effectively bypasses the block buffer, but you can trick Linux kernel to bypass it by binding the device to /dev/raw/rawN and referring to the latter instead of real device (there're limitations though, consult the manual page). What value do you call sane - count=N with N = isoinfo -d? Sane block count is obviously the number of last *significant* block. Yes, for mkisofs mastered images the value returned by isoinfo suffices. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
From: Volker Kuhlmann [EMAIL PROTECTED] Thanks for all your thoughts. I'll combine the reply. Why are you mailing cdwrite? If it's a kernel bug, you should send a bug report to linux-kernel I'd say. I am not sure where the bug is, but it affects CDs. This is a CD writing list? (a) get the size of the ISO filesystem with cdrecord or isoinfo, and then use dd to read only what's valid, or complain to the creator of the CD. There's an option which fixes this, from memory -dao. (a) I am always doing that. (b) If you mean the person, that's me. If you mean the software, I don't think Jörg is going to be to sympathetic ;) If you write the CD on SAO mode (using -dao) the whole CD is readble or your drive or kernel is bad. If you write in TAO mode, then in theory you are not allowed to read more than the size value from isoinfo -d. As mkisofs at least adds 150 NULLed sectors to this value, a I/O error from reading filesystem content verifies a kernel bug. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
From: Ambrose Li [EMAIL PROTECTED] (From someone who doesn't know much about CD's) I used to checksum all the files (after finding that checksumming the whole disk doesn't work -- something beyond my understanding). This stopped abruptly after I upgraded my Linux kernel to 2.4, when mounting a hfs disk started to crash the kernel. I had to simply give people disks that I could not verify as having been written correctly. If your kernel did crash, then you definitely found a kernel bug. So if I might add something to the efficiency argument, I might add that for me to checksum my disk, I'll need to checksum all the files twice (once for iso9660, once for hfs), and all this is provided that checksumming all the files would actually work (which is not the case right now). IF you write in SAO mode and your drive is not broken (use -raw96r with Lite-ON drives for this reason), then you may simply checksum the complete content of the session. The CD definitely gives you exactly the same content back that has been in the *.iso file. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
From: Andy Polyakov [EMAIL PROTECTED] If you really have to checksum the whole image, then make sure to bypass the block buffer *and* provide sane block count value. A. Obvious question ;): is there an easy way to bypass the block buffer? Well, already mentioned readcd effectively bypasses the block buffer, but you can trick Linux kernel to bypass it by binding the device to /dev/raw/rawN and referring to the latter instead of real device (there're limitations though, consult the manual page). What value do you call sane - count=N with N = isoinfo -d? Sane block count is obviously the number of last *significant* block. Yes, for mkisofs mastered images the value returned by isoinfo suffices. A. Not if this is e.g. a Solaris boot CD. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
If you really have to checksum the whole image, then make sure to bypass the block buffer *and* provide sane block count value. A. Sane block count is obviously the number of last *significant* block. Yes, for mkisofs mastered images the value returned by isoinfo suffices. Not if this is e.g. a Solaris boot CD. Note that last part of the statement reads as for *mkisofs* *mastered* images. Is Solaris boot CD image mastered with mkisofs? I can't confirm it is, at least not Solaris 8 (strings reveal MakeDisc ver. 1.20). mkisofs -B on the other hand does cover SPARC boot block[s] by value returned by isoinfo. But even if ISO9660 partition of Solaris boot CD was prepared with mkisofs, there're UFS partitions which are surely appended by *separate* means and therefore resulting layout can hardly be classified as *mastered* with mkisofs. In other words I'm not convinced that my statement doesn't hold true. Sane block count is still the last *significant* block even for Solaris boot CD. And as long as output from mkisofs is fed *immediately* to recording program, value returned by isoinfo is suitable for discussed purposes. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
On Tue 14 October 2003 12:30, Andy Polyakov wrote: Meet the players in the field: - block buffer which provides for read-ahead, I/O requests' slicing and coalescing; - value returned by READ CAPACITY command, hereafter simply READ CAPACITY; - actual lead-out position; Rules of the game (please note that I'm not claiming that I know all the rules in detail:-): - block buffer rearranges I/O depending on *momentary* availability of spare memory, e.g. even if you ask for bs=2k, it may coalesce them to e.g. 126KB chunks, or it may break larger requests to a number of 4KB ones; - no requests are posed beyond the READ CAPACITY; - READ CAPACITY coincides with lead-out position most of the time, *but not always*; - CD lead-out position is documented to be inaccurate [with 75 blocks inaccuracy?], DVD lead-out position is believed to be accurate; - CD lead-out is preceded by few unaccesible blocks (unless disk is recorded in DAO mode?), lead-out itself is unaccesible; Thanks for the explanation! That sheds some more light on the case. I've dug up the ECMA-130 spec (== Yellow Book for all practical purposes) from www.ecma-international.org and after a bit of searching I found this (from section 22.3.4.2): If set to (A2) the P-MIN, P-SEC and P-FRAC fields specify the beginning of the Lead-out Track, thus the address of the first Section of the Lead-out Track. The TOC basically consists of a list of records, each of which specifies a track number and a start address in min:sec:frac format (with a fraction being 1/75th of a second). The last element in the list describes the start of the Lead-out, as quoted above. Now the interesting bit is that this is actually section-accurate, and that each section holds one block (ie 2k) of data. Also note that the last readable block before the Lead-out is at address_of_lead_out - 1. At any rate, unless I missed something, the amount of readable blocks is actually stored on the CD, and the number is accurate. Okay, so that's how the information is stored on the disc physically. A bit of Googling got me to http://www.t10.org/ftp/t10/document.01/01-246r0.pdf, which states that the READ CAPACITY SCSI bus command returns a logical block address (LBA) and a block length in bytes. The LBA is the address of the last logical block on the disc, so the number of blocks in total before the Lead-out is actually LBA + 1. From /usr/src/linux-2.4.21/drivers/ide/ide-cd.c, cdrom_read_capacity: pc.c[0] = GPCMD_READ_CDVD_CAPACITY; pc.buffer = (char *)capbuf; pc.buflen = sizeof(capbuf); stat = cdrom_queue_packet_command(drive, pc); if (stat == 0) *capacity = 1 + be32_to_cpu(capbuf.lba); return stat; So it seems that as long as the drive gives the correct LBA number (should be P-MIN * 60 * 75 + P-SEC * 75 + P-FRAC - 1 with values as above), ide-cd will report the correct media size. Readcd from cdrecord uses the exact same way to get the capacity from the drive, and displays the amount of blocks correctly. According to it, my Nero CD has 169825 blocks. Unfortunately the -fulltoc option of readcd isn't implemented, so I can't verify that this matches the information on the disc. Does anyone know of another way to get to the raw TOC data on a CD? Now, as I said ide-cd.c reads the amount of blocks the same way, so it will get the same value. I'm not sure what happens with this value though, presumably it ends up with the block driver as Andy described, but I haven't found out how yet. Looking at the Linux SCSI stuff, I found this in drivers/scsi/sr.c: /* * The SCSI specification allows for the value returned * by READ CAPACITY to be up to 75 2K sectors past the * last readable block. Therefore, if we hit a medium * error within the last 75 2K sectors, we decrease the * saved size value. */ if ((error_sector 1) sr_sizes[device_nr] scsi_CDs[device_nr].capacity - error_sector 4 *75) sr_sizes[device_nr] = error_sector 1; So it seems that you were correct about that. snip Relevant question is when READ CAPACITY is not equal to lead-out offset? I don't know about CD, but in DVD case most units would report full media capacity for READ CAPACITY under following circumstances: Well, it looks like that's up to the drive's firmware. READ CAPACITY is pretty much useless, since it's allowed to give wrong information. snip case. One can wonder if the common block buffer could do better job spotting the last addressible sector? Well, yes, but do keep in mind that it's a *common* block buffer, which is not aware of CD technicalities... So that I'd say that it's perfectly legitimate to advice as following. If you really have to checksum the whole image, then make sure to bypass the block buffer *and* provide sane block count value. A. Well, it seems to me that the block driver gets the capacity from the underlying device driver. So if that driver gives
Re: linux kernel error reading end of cd/dvd
75 sectors is one second CD-DA, right? Yes. I have observed the same problem with DVD+R burnt by Nero (different box), reading on the box as previously stated, so I don't think it's limited to CDs - it affects DVDs in the same manner. Can you confirm that the value returned by isoinfo on Nero mastered disk did not cross the address of lead-out? No I can't, I probably don't have the disks any more. The original was pressed (one of the SuSE 8.2 DVDs), mastered with mkisofs 1.15a27, copied with Nero. The copy didn't read properly with dd count=`isoinfo -d`, read error near end. I doubt Nero would start the lead out before isoinfo -d. One of the copies I have (probably cdrecord-prodvd): # dvd+rw-mediainfo /dev/hdb Media Book Type: A1h, DVD+R book [revision 1] Legacy lead-out at:1923680*2KB=3939696640 # isoinfo -d -i /dev/cdrom Volume size is: 1923680 (Can't get -toc with cdrecord-prodvd to get lead-out because it spits a fit on this dvdrom drive.) What value do you call sane - count=N with N = isoinfo -d? Sane block count is obviously the number of last *significant* block. Yes, for mkisofs mastered images the value returned by isoinfo suffices. As long as this sane value can't be obtained easily, even with non-mkisofs-mastered disks, it has little practical use. I checked a few M$-style mass-produced CDs which came with various hardware, and isoinfo -d was identical to df, all files were readable, not necessarily all isoinfo -d blocks (last ones give read error). If you write the CD on SAO mode (using -dao) the whole CD is readble or your drive or kernel is bad. Out of interest, whole disk is how much? Total media capacity before first burn? That doesn't seem right. If you write in TAO mode, then in theory you are not allowed to read more than the size value from isoinfo -d. If I could only read that much... (beyond that number is of no interest to anyone, well not me). As mkisofs at least adds 150 NULLed sectors to this value this = ? Whenever I checked in the past, the file created by mkisofs -o had a size (ls -l) identical to the size reported by isoinfo -d. Where are these 150 blocks added? mkisofs -pad only pads up to the nearest 32k boundary (i.e. adds up to 15 blocks), and I presume this padding counts into the isoinfo -d value. How reliably does isoinfo -d correlate to the size of the filesystem? 100% in case of mkisofs I assume. Are there any counter-examples known (mkisofs or not)? So it seems that as long as the drive gives the correct LBA number (should be P-MIN * 60 * 75 + P-SEC * 75 + P-FRAC - 1 with values as above), ide-cd will report the correct media size. Good. The media size can't then be smaller than the filesystem size, but will be larger if padding is used. On my last CD, readcd reads 16 more blocks before hitting the wall, 15 of which are due to cdrecord -pad. * The SCSI specification allows for the value returned * by READ CAPACITY to be up to 75 2K sectors past the * last readable block. What idiot came up with that idea... ? Well, it looks like that's up to the drive's firmware. READ CAPACITY is pretty much useless, since it's allowed to give wrong information. Ack. I can see two options: 1) Modify ide-cd.c and sr.c to use READ CAPACITY, and then try to read the 75 2k sectors before that. Catch the IO error, and adjust the capacity based on the number of succesfully read sectors. 2) Modify ide-cd.c and sr.c to read the TOC and get the capacity directly from the disc, thus completely circumventing the READ CAPACITY command. Since READ CAPACITY is braindead, 2) gets my vote. 2) also has the advantage of not relying on possibly buggy firmware. If one wanted to put more effort in, one could perhaps take the smaller of 1) and 2). Surely the drive's firmware itself determines the READ CAPACITY from the TOC? Does the block-buffer Andy described handle both hard disks and CD/DVDs (I understand yes)? There never is a problem with reading past the end of a hard disk partition (if there was, things would bomb out all over). Does this mean that in the case of CD/DVDs, the device driver hands a too-large limit up to higher levels? Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
Meet the players in the field: - block buffer which provides for read-ahead, I/O requests' slicing and coalescing; - value returned by READ CAPACITY command, hereafter simply READ CAPACITY; - actual lead-out position; Rules of the game (please note that I'm not claiming that I know all the rules in detail:-): - block buffer rearranges I/O depending on *momentary* availability of spare memory, e.g. even if you ask for bs=2k, it may coalesce them to e.g. 126KB chunks, or it may break larger requests to a number of 4KB ones; - no requests are posed beyond the READ CAPACITY; - READ CAPACITY coincides with lead-out position most of the time, *but not always*; - CD lead-out position is documented to be inaccurate [with 75 blocks inaccuracy?], DVD lead-out position is believed to be accurate; - CD lead-out is preceded by few unaccesible blocks (unless disk is recorded in DAO mode?), lead-out itself is unaccesible; Last and middle rules form the ground for I/O errors in general and in read-ahead in particular. The first rule explains why the problem with dd count=X appears to be intermittent. It also makes it impossible to find the magic modulo coefficient, which would predict if any particular combination of bs=, count= and READ CAPACITY is bound to fail or not [as it all depends on *momentary* availability of spare memory]. Bypassing the block buffer naturally makes all the problems with count=sanevalue disappear, as well as makes it possible to accurately and reliably locate the last accessible block. Relevant question is when READ CAPACITY is not equal to lead-out offset? I don't know about CD, but in DVD case most units would report full media capacity for READ CAPACITY under following circumstances: - DVD+RW and DVD-RW Restricted Overwrite(?) media in recorder unit. READ CAPACITY is not associated with lead-out position and equals to full media capacity; - DVD-RW Restricted Overwrite, Incremental DVD-R[W] and DVD+R which were not finalized in first session in legacy DVD-ROM unit. Unit replies with full media capacity (as legacy lead-out points to the outer edge); [- if you [still] have DVD+RW kernel patch applied, it will also *replace* the READ CAPACITY with full media capacity for DVD+R media in recordred unit]; I tried mounting the CD that did not work, and copy all files off of it. No problems there. Note this is not necessarily an indicator that the filesystem is not affected, it only means none of the files are directly affected. But that's basically what should and does count... There are more blocks in a filesystem than just the files' data. If we're talking about ISO9660 layout prepared by mkisofs, then those more blocks are known to be insignificant and you can as well checksum every file instead of the whole filesystem image, can't you? Does it really have to be whole image? But in either case. One can wonder if the common block buffer could do better job spotting the last addressible sector? Well, yes, but do keep in mind that it's a *common* block buffer, which is not aware of CD technicalities... So that I'd say that it's perfectly legitimate to advice as following. If you really have to checksum the whole image, then make sure to bypass the block buffer *and* provide sane block count value. A.
Re: linux kernel error reading end of cd/dvd
Wow! Someone who knows what he's talking about - I'm impressed. - CD lead-out position is documented to be inaccurate [with 75 blocks inaccuracy?] Silly question - where/how? How do you arrive at 75? I have observed the same problem with DVD+R burnt by Nero (different box), reading on the box as previously stated, so I don't think it's limited to CDs - it affects DVDs in the same manner. There are more blocks in a filesystem than just the files' data. If we're talking about ISO9660 layout prepared by mkisofs, then those more blocks are known to be insignificant and you can as well checksum every file instead of the whole filesystem image, can't you? No. Checksumming only files does not checksum (all of) the filesystem's metadata. From an efficiency viewpoint, checksumming files is out of the question. Checksumming the disk is very fast, and independent of the filesystem used. In the case of iso9660, checksumming files may be slower by only a factor of two (sorry can't remember right now), for udf and ext2 you can plain forget about it from a practical perspective. The only fast way of doing it would be to read the whole CD/DVD image to disk, loopmount, check files - might check the disk itself in the first place. Does it really have to be whole image? Yes. And it *ought* to work ;) I ran a number of readcd -c2scan on the CD in question, and found a varying number of errors (and that readcd kills the CPU). No errors at 12x speed, always some at 24x, it also seems to vary with system load. None of the errors are close to the end - all are at 347143 with a filesystem size of 349552. None of the errors are hard read errors. If you really have to checksum the whole image, then make sure to bypass the block buffer *and* provide sane block count value. A. Obvious question ;): is there an easy way to bypass the block buffer? What value do you call sane - count=N with N = isoinfo -d? No point in an N larger than that. Thanks much, Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
Re: linux kernel error reading end of cd/dvd
On Wed, Oct 15, 2003 at 12:33:12AM +1300, Volker Kuhlmann wrote: If we're talking about ISO9660 layout prepared by mkisofs, then those more blocks are known to be insignificant and you can as well checksum every file instead of the whole filesystem image, can't you? No. Checksumming only files does not checksum (all of) the filesystem's metadata. From an efficiency viewpoint, checksumming files is out of the question. Checksumming the disk is very fast, and independent of the filesystem used. In the case of iso9660, checksumming files may be slower by only a factor of two (sorry can't remember right now), for udf and ext2 you can plain forget about it from a practical perspective. The only fast way of doing it would be to read the whole CD/DVD image to disk, loopmount, check files - might check the disk itself in the first place. Does it really have to be whole image? Yes. And it *ought* to work ;) (From someone who doesn't know much about CD's) I used to checksum all the files (after finding that checksumming the whole disk doesn't work -- something beyond my understanding). This stopped abruptly after I upgraded my Linux kernel to 2.4, when mounting a hfs disk started to crash the kernel. I had to simply give people disks that I could not verify as having been written correctly. So if I might add something to the efficiency argument, I might add that for me to checksum my disk, I'll need to checksum all the files twice (once for iso9660, once for hfs), and all this is provided that checksumming all the files would actually work (which is not the case right now).
Re: linux kernel error reading end of cd/dvd
- CD lead-out position is documented to be inaccurate [with 75 blocks inaccuracy?] Silly question - where/how? Note the question mark in the [comment]. It means I'm not sure where I read/heard this and I admit that I might be wrong about this:-) How do you arrive at 75? 75 sectors is one second CD-DA, right? I have observed the same problem with DVD+R burnt by Nero (different box), reading on the box as previously stated, so I don't think it's limited to CDs - it affects DVDs in the same manner. Can you confirm that the value returned by isoinfo on Nero mastered disk did not cross the address of lead-out? Then it naturally can vary from one DVD recorder manufacturer to another. What I'm trying to say is that I can't confirm your experience with DVD+R, not with ISO9660 layouts generated by mkisofs. Which is why I wrote DVD lead-out position *is believed* to be accurate. If you really have to checksum the whole image, then make sure to bypass the block buffer *and* provide sane block count value. A. Obvious question ;): is there an easy way to bypass the block buffer? Well, already mentioned readcd effectively bypasses the block buffer, but you can trick Linux kernel to bypass it by binding the device to /dev/raw/rawN and referring to the latter instead of real device (there're limitations though, consult the manual page). What value do you call sane - count=N with N = isoinfo -d? Sane block count is obviously the number of last *significant* block. Yes, for mkisofs mastered images the value returned by isoinfo suffices. A.
Re: linux kernel error reading end of cd/dvd
From: Volker Kuhlmann [EMAIL PROTECTED] Thanks for all your thoughts. I'll combine the reply. Why are you mailing cdwrite? If it's a kernel bug, you should send a bug report to linux-kernel I'd say. I am not sure where the bug is, but it affects CDs. This is a CD writing list? (a) get the size of the ISO filesystem with cdrecord or isoinfo, and then use dd to read only what's valid, or complain to the creator of the CD. There's an option which fixes this, from memory -dao. (a) I am always doing that. (b) If you mean the person, that's me. If you mean the software, I don't think Jörg is going to be to sympathetic ;) If you write the CD on SAO mode (using -dao) the whole CD is readble or your drive or kernel is bad. If you write in TAO mode, then in theory you are not allowed to read more than the size value from isoinfo -d. As mkisofs at least adds 150 NULLed sectors to this value, a I/O error from reading filesystem content verifies a kernel bug. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Re: linux kernel error reading end of cd/dvd
From: Ambrose Li [EMAIL PROTECTED] (From someone who doesn't know much about CD's) I used to checksum all the files (after finding that checksumming the whole disk doesn't work -- something beyond my understanding). This stopped abruptly after I upgraded my Linux kernel to 2.4, when mounting a hfs disk started to crash the kernel. I had to simply give people disks that I could not verify as having been written correctly. If your kernel did crash, then you definitely found a kernel bug. So if I might add something to the efficiency argument, I might add that for me to checksum my disk, I'll need to checksum all the files twice (once for iso9660, once for hfs), and all this is provided that checksumming all the files would actually work (which is not the case right now). IF you write in SAO mode and your drive is not broken (use -raw96r with Lite-ON drives for this reason), then you may simply checksum the complete content of the session. The CD definitely gives you exactly the same content back that has been in the *.iso file. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Re: linux kernel error reading end of cd/dvd
From: Andy Polyakov [EMAIL PROTECTED] If you really have to checksum the whole image, then make sure to bypass the block buffer *and* provide sane block count value. A. Obvious question ;): is there an easy way to bypass the block buffer? Well, already mentioned readcd effectively bypasses the block buffer, but you can trick Linux kernel to bypass it by binding the device to /dev/raw/rawN and referring to the latter instead of real device (there're limitations though, consult the manual page). What value do you call sane - count=N with N = isoinfo -d? Sane block count is obviously the number of last *significant* block. Yes, for mkisofs mastered images the value returned by isoinfo suffices. A. Not if this is e.g. a Solaris boot CD. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Re: linux kernel error reading end of cd/dvd
If you really have to checksum the whole image, then make sure to bypass the block buffer *and* provide sane block count value. A. Sane block count is obviously the number of last *significant* block. Yes, for mkisofs mastered images the value returned by isoinfo suffices. Not if this is e.g. a Solaris boot CD. Note that last part of the statement reads as for *mkisofs* *mastered* images. Is Solaris boot CD image mastered with mkisofs? I can't confirm it is, at least not Solaris 8 (strings reveal MakeDisc ver. 1.20). mkisofs -B on the other hand does cover SPARC boot block[s] by value returned by isoinfo. But even if ISO9660 partition of Solaris boot CD was prepared with mkisofs, there're UFS partitions which are surely appended by *separate* means and therefore resulting layout can hardly be classified as *mastered* with mkisofs. In other words I'm not convinced that my statement doesn't hold true. Sane block count is still the last *significant* block even for Solaris boot CD. And as long as output from mkisofs is fed *immediately* to recording program, value returned by isoinfo is suitable for discussed purposes. A.
Re: linux kernel error reading end of cd/dvd
On Tue 14 October 2003 12:30, Andy Polyakov wrote: Meet the players in the field: - block buffer which provides for read-ahead, I/O requests' slicing and coalescing; - value returned by READ CAPACITY command, hereafter simply READ CAPACITY; - actual lead-out position; Rules of the game (please note that I'm not claiming that I know all the rules in detail:-): - block buffer rearranges I/O depending on *momentary* availability of spare memory, e.g. even if you ask for bs=2k, it may coalesce them to e.g. 126KB chunks, or it may break larger requests to a number of 4KB ones; - no requests are posed beyond the READ CAPACITY; - READ CAPACITY coincides with lead-out position most of the time, *but not always*; - CD lead-out position is documented to be inaccurate [with 75 blocks inaccuracy?], DVD lead-out position is believed to be accurate; - CD lead-out is preceded by few unaccesible blocks (unless disk is recorded in DAO mode?), lead-out itself is unaccesible; Thanks for the explanation! That sheds some more light on the case. I've dug up the ECMA-130 spec (== Yellow Book for all practical purposes) from www.ecma-international.org and after a bit of searching I found this (from section 22.3.4.2): If set to (A2) the P-MIN, P-SEC and P-FRAC fields specify the beginning of the Lead-out Track, thus the address of the first Section of the Lead-out Track. The TOC basically consists of a list of records, each of which specifies a track number and a start address in min:sec:frac format (with a fraction being 1/75th of a second). The last element in the list describes the start of the Lead-out, as quoted above. Now the interesting bit is that this is actually section-accurate, and that each section holds one block (ie 2k) of data. Also note that the last readable block before the Lead-out is at address_of_lead_out - 1. At any rate, unless I missed something, the amount of readable blocks is actually stored on the CD, and the number is accurate. Okay, so that's how the information is stored on the disc physically. A bit of Googling got me to http://www.t10.org/ftp/t10/document.01/01-246r0.pdf, which states that the READ CAPACITY SCSI bus command returns a logical block address (LBA) and a block length in bytes. The LBA is the address of the last logical block on the disc, so the number of blocks in total before the Lead-out is actually LBA + 1. From /usr/src/linux-2.4.21/drivers/ide/ide-cd.c, cdrom_read_capacity: pc.c[0] = GPCMD_READ_CDVD_CAPACITY; pc.buffer = (char *)capbuf; pc.buflen = sizeof(capbuf); stat = cdrom_queue_packet_command(drive, pc); if (stat == 0) *capacity = 1 + be32_to_cpu(capbuf.lba); return stat; So it seems that as long as the drive gives the correct LBA number (should be P-MIN * 60 * 75 + P-SEC * 75 + P-FRAC - 1 with values as above), ide-cd will report the correct media size. Readcd from cdrecord uses the exact same way to get the capacity from the drive, and displays the amount of blocks correctly. According to it, my Nero CD has 169825 blocks. Unfortunately the -fulltoc option of readcd isn't implemented, so I can't verify that this matches the information on the disc. Does anyone know of another way to get to the raw TOC data on a CD? Now, as I said ide-cd.c reads the amount of blocks the same way, so it will get the same value. I'm not sure what happens with this value though, presumably it ends up with the block driver as Andy described, but I haven't found out how yet. Looking at the Linux SCSI stuff, I found this in drivers/scsi/sr.c: /* * The SCSI specification allows for the value returned * by READ CAPACITY to be up to 75 2K sectors past the * last readable block. Therefore, if we hit a medium * error within the last 75 2K sectors, we decrease the * saved size value. */ if ((error_sector 1) sr_sizes[device_nr] scsi_CDs[device_nr].capacity - error_sector 4 *75) sr_sizes[device_nr] = error_sector 1; So it seems that you were correct about that. snip Relevant question is when READ CAPACITY is not equal to lead-out offset? I don't know about CD, but in DVD case most units would report full media capacity for READ CAPACITY under following circumstances: Well, it looks like that's up to the drive's firmware. READ CAPACITY is pretty much useless, since it's allowed to give wrong information. snip case. One can wonder if the common block buffer could do better job spotting the last addressible sector? Well, yes, but do keep in mind that it's a *common* block buffer, which is not aware of CD technicalities... So that I'd say that it's perfectly legitimate to advice as following. If you really have to checksum the whole image, then make sure to bypass the block buffer *and* provide sane block count value. A. Well, it seems to me that the block driver gets the capacity from the underlying device driver. So if that driver gives
Re: linux kernel error reading end of cd/dvd
75 sectors is one second CD-DA, right? Yes. I have observed the same problem with DVD+R burnt by Nero (different box), reading on the box as previously stated, so I don't think it's limited to CDs - it affects DVDs in the same manner. Can you confirm that the value returned by isoinfo on Nero mastered disk did not cross the address of lead-out? No I can't, I probably don't have the disks any more. The original was pressed (one of the SuSE 8.2 DVDs), mastered with mkisofs 1.15a27, copied with Nero. The copy didn't read properly with dd count=`isoinfo -d`, read error near end. I doubt Nero would start the lead out before isoinfo -d. One of the copies I have (probably cdrecord-prodvd): # dvd+rw-mediainfo /dev/hdb Media Book Type: A1h, DVD+R book [revision 1] Legacy lead-out at:1923680*2KB=3939696640 # isoinfo -d -i /dev/cdrom Volume size is: 1923680 (Can't get -toc with cdrecord-prodvd to get lead-out because it spits a fit on this dvdrom drive.) What value do you call sane - count=N with N = isoinfo -d? Sane block count is obviously the number of last *significant* block. Yes, for mkisofs mastered images the value returned by isoinfo suffices. As long as this sane value can't be obtained easily, even with non-mkisofs-mastered disks, it has little practical use. I checked a few M$-style mass-produced CDs which came with various hardware, and isoinfo -d was identical to df, all files were readable, not necessarily all isoinfo -d blocks (last ones give read error). If you write the CD on SAO mode (using -dao) the whole CD is readble or your drive or kernel is bad. Out of interest, whole disk is how much? Total media capacity before first burn? That doesn't seem right. If you write in TAO mode, then in theory you are not allowed to read more than the size value from isoinfo -d. If I could only read that much... (beyond that number is of no interest to anyone, well not me). As mkisofs at least adds 150 NULLed sectors to this value this = ? Whenever I checked in the past, the file created by mkisofs -o had a size (ls -l) identical to the size reported by isoinfo -d. Where are these 150 blocks added? mkisofs -pad only pads up to the nearest 32k boundary (i.e. adds up to 15 blocks), and I presume this padding counts into the isoinfo -d value. How reliably does isoinfo -d correlate to the size of the filesystem? 100% in case of mkisofs I assume. Are there any counter-examples known (mkisofs or not)? So it seems that as long as the drive gives the correct LBA number (should be P-MIN * 60 * 75 + P-SEC * 75 + P-FRAC - 1 with values as above), ide-cd will report the correct media size. Good. The media size can't then be smaller than the filesystem size, but will be larger if padding is used. On my last CD, readcd reads 16 more blocks before hitting the wall, 15 of which are due to cdrecord -pad. * The SCSI specification allows for the value returned * by READ CAPACITY to be up to 75 2K sectors past the * last readable block. What idiot came up with that idea... ? Well, it looks like that's up to the drive's firmware. READ CAPACITY is pretty much useless, since it's allowed to give wrong information. Ack. I can see two options: 1) Modify ide-cd.c and sr.c to use READ CAPACITY, and then try to read the 75 2k sectors before that. Catch the IO error, and adjust the capacity based on the number of succesfully read sectors. 2) Modify ide-cd.c and sr.c to read the TOC and get the capacity directly from the disc, thus completely circumventing the READ CAPACITY command. Since READ CAPACITY is braindead, 2) gets my vote. 2) also has the advantage of not relying on possibly buggy firmware. If one wanted to put more effort in, one could perhaps take the smaller of 1) and 2). Surely the drive's firmware itself determines the READ CAPACITY from the TOC? Does the block-buffer Andy described handle both hard disks and CD/DVDs (I understand yes)? There never is a problem with reading past the end of a hard disk partition (if there was, things would bomb out all over). Does this mean that in the case of CD/DVDs, the device driver hands a too-large limit up to higher levels? Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
Re: linux kernel error reading end of cd/dvd
Thanks for all your thoughts. I'll combine the reply. Why are you mailing cdwrite? If it's a kernel bug, you should send a bug report to linux-kernel I'd say. I am not sure where the bug is, but it affects CDs. This is a CD writing list? (a) get the size of the ISO filesystem with cdrecord or isoinfo, and then use dd to read only what's valid, or complain to the creator of the CD. There's an option which fixes this, from memory -dao. (a) I am always doing that. (b) If you mean the person, that's me. If you mean the software, I don't think Jörg is going to be to sympathetic ;) Actually, that doesn't work. I took a random pressed CD, used isoinfo to find that there were 160525 blocks on it, and then used dd to read the blocks, with bs=2k count=160525. It stops at 160484 blocks with an IO error every time. Turning off readahead with Thanks very much for that! I was beginning to think nobody takes me serious. Eaxactly what I am seeing quite often. Could be media, hardware/firmware, or as you say, something we don't understand. I am undecided, but would say the kernel is involved. If hardware/firmware is involved, I'd say it affects roughly over 50% of it. I tried mounting the CD that did not work, and copy all files off of it. No problems there. Note this is not necessarily an indicator that the filesystem is not affected, it only means none of the files are directly affected. There are more blocks in a filesystem than just the files' data. With several trouble CDs, I could read all the files correctly, but the read error was 2 blocks before the end of the iso9660 filesystem (as indicated by isoinfo -d, I never had reason to suspect it has ever given bogus numbers). When I did manage to find out what those 2 last blocks contained (can't remember how, in some cases by looking at the iso image file I just burnt) those 2 blocks only contained nulls. Meaning those 2 blocks are not relevant, but they're nevertheless part of the filesystem and part of its md5 sum. Perhaps it's some sort of odd copy protection? (it's a Nero install CD that came with my burner, I I don't think these CDs contain copy protections. The software is crippleware, only of use if you have the hardware, and everyone who has the hardware has paid the Nero tax as well (don't get me started). There is no need to use -pad! My experience clearly shows otherwise. If you mean *should* be no need for -pad, by all means yes. It's a right PITA. If you use unapropriate software like dd and don't even send a problem report, it is impossible to help you :-( As for dd: a cdrom is a block device and I can expect to use it as such. Are you wishing to argue about that? Apart from the problem I have been describing, it works fine (with the obvious restrictions of spead and read-only). As for problem report: well dunno where the problem is, and it looks to me as if everyone on this list knows that you're not very, what's the word, responsive to reports which have nothing to do with cdrecord. mkisofs now adds paddinf for a long time Sure, but remembering that option is the same as remembering to bang a bunch of nulls at the end of the iso file. ;) He unfortunately not even send a error message. Not true. I gave a detailed description of the situations in which the error occurs, and that the error is read error. If you want more than that, no problem but you should ask properly. Actually, not sure I can tell you more than that. Using dd is a bad idea and only readcd will give helpful messages in case the medium is not readable. Good point, haven't used readcd before (sorry but simply didn't see a need), but for gettng better error info it has a place. Hardware: PIII-450 with Intel 440BX chipset, Asus E616 16x dvdrom drive /dev/hdb: HDIO_GET_MULTCOUNT failed: Invalid argument IO_support = 0 (default 16-bit) unmaskirq= 1 (on) using_dma= 1 (on) keepsettings = 0 (off) readonly = 1 (on) readahead= 8 (on) HDIO_GETGEO failed: Invalid argument Software: SuSE 8.2, mkisofs + cdrecord 2 final isoinfo -d: Volume size is: 349552 readcd -v dev=ATAPI:1,1,0 f=somedisk.raw scsidev: 'ATAPI:1,1,0' devname: 'ATAPI' scsibus: 1 target: 1 lun: 0 Warning: Using ATA Packet interface. Warning: The related libscg interface code is in pre alpha. Warning: There may be fatal problems. Read speed: 8448 kB/s (CD 48x, DVD 6x). Write speed: 0 kB/s (CD 0x, DVD 0x). Capacity: 349569 Blocks = 699138 kBytes = 682 MBytes = 715 prMB Sectorsize: 2048 Bytes Copy from SCSI (1,1,0) disk to file 'somedisk.raw' end:349569 ... addr: 349209 cnt: 63 addr: 349272 cnt: 63 addr: 349335 cnt: 63 addr: 349398 cnt: 63 addr: 349461 cnt: 63 addr: 349524 cnt: 45 readcd: Input/output error. read_g1: scsi sendcmd: no error CDB: 28 00 00 05 55 54 00 00 2D 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 64
Re: linux kernel error reading end of cd/dvd
Thanks for all your thoughts. I'll combine the reply. Why are you mailing cdwrite? If it's a kernel bug, you should send a bug report to linux-kernel I'd say. I am not sure where the bug is, but it affects CDs. This is a CD writing list? (a) get the size of the ISO filesystem with cdrecord or isoinfo, and then use dd to read only what's valid, or complain to the creator of the CD. There's an option which fixes this, from memory -dao. (a) I am always doing that. (b) If you mean the person, that's me. If you mean the software, I don't think Jörg is going to be to sympathetic ;) Actually, that doesn't work. I took a random pressed CD, used isoinfo to find that there were 160525 blocks on it, and then used dd to read the blocks, with bs=2k count=160525. It stops at 160484 blocks with an IO error every time. Turning off readahead with Thanks very much for that! I was beginning to think nobody takes me serious. Eaxactly what I am seeing quite often. Could be media, hardware/firmware, or as you say, something we don't understand. I am undecided, but would say the kernel is involved. If hardware/firmware is involved, I'd say it affects roughly over 50% of it. I tried mounting the CD that did not work, and copy all files off of it. No problems there. Note this is not necessarily an indicator that the filesystem is not affected, it only means none of the files are directly affected. There are more blocks in a filesystem than just the files' data. With several trouble CDs, I could read all the files correctly, but the read error was 2 blocks before the end of the iso9660 filesystem (as indicated by isoinfo -d, I never had reason to suspect it has ever given bogus numbers). When I did manage to find out what those 2 last blocks contained (can't remember how, in some cases by looking at the iso image file I just burnt) those 2 blocks only contained nulls. Meaning those 2 blocks are not relevant, but they're nevertheless part of the filesystem and part of its md5 sum. Perhaps it's some sort of odd copy protection? (it's a Nero install CD that came with my burner, I I don't think these CDs contain copy protections. The software is crippleware, only of use if you have the hardware, and everyone who has the hardware has paid the Nero tax as well (don't get me started). There is no need to use -pad! My experience clearly shows otherwise. If you mean *should* be no need for -pad, by all means yes. It's a right PITA. If you use unapropriate software like dd and don't even send a problem report, it is impossible to help you :-( As for dd: a cdrom is a block device and I can expect to use it as such. Are you wishing to argue about that? Apart from the problem I have been describing, it works fine (with the obvious restrictions of spead and read-only). As for problem report: well dunno where the problem is, and it looks to me as if everyone on this list knows that you're not very, what's the word, responsive to reports which have nothing to do with cdrecord. mkisofs now adds paddinf for a long time Sure, but remembering that option is the same as remembering to bang a bunch of nulls at the end of the iso file. ;) He unfortunately not even send a error message. Not true. I gave a detailed description of the situations in which the error occurs, and that the error is read error. If you want more than that, no problem but you should ask properly. Actually, not sure I can tell you more than that. Using dd is a bad idea and only readcd will give helpful messages in case the medium is not readable. Good point, haven't used readcd before (sorry but simply didn't see a need), but for gettng better error info it has a place. Hardware: PIII-450 with Intel 440BX chipset, Asus E616 16x dvdrom drive /dev/hdb: HDIO_GET_MULTCOUNT failed: Invalid argument IO_support = 0 (default 16-bit) unmaskirq= 1 (on) using_dma= 1 (on) keepsettings = 0 (off) readonly = 1 (on) readahead= 8 (on) HDIO_GETGEO failed: Invalid argument Software: SuSE 8.2, mkisofs + cdrecord 2 final isoinfo -d: Volume size is: 349552 readcd -v dev=ATAPI:1,1,0 f=somedisk.raw scsidev: 'ATAPI:1,1,0' devname: 'ATAPI' scsibus: 1 target: 1 lun: 0 Warning: Using ATA Packet interface. Warning: The related libscg interface code is in pre alpha. Warning: There may be fatal problems. Read speed: 8448 kB/s (CD 48x, DVD 6x). Write speed: 0 kB/s (CD 0x, DVD 0x). Capacity: 349569 Blocks = 699138 kBytes = 682 MBytes = 715 prMB Sectorsize: 2048 Bytes Copy from SCSI (1,1,0) disk to file 'somedisk.raw' end:349569 ... addr: 349209 cnt: 63 addr: 349272 cnt: 63 addr: 349335 cnt: 63 addr: 349398 cnt: 63 addr: 349461 cnt: 63 addr: 349524 cnt: 45 readcd: Input/output error. read_g1: scsi sendcmd: no error CDB: 28 00 00 05 55 54 00 00 2D 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 64
Re: linux kernel error reading end of cd/dvd
On Wed 8 October 2003 05:09, Rob Bogus wrote: Volker Kuhlmann wrote: Esteemed gurus, if anyone is able to shed some more light on this kernel problem I'd appreciate it. It's been going on for years. When reading the whole of an iso9660 filesystem from a cd or dvd, I often get I/O errors within the last blocks of the filesystem. Using snip This is caused by reading past the end of written data. You can either (a) get the size of the ISO filesystem with cdrecord or isoinfo, and then use dd to read only what's valid, or complain to the creator of the CD. There's an option which fixes this, from memory -dao. Actually, that doesn't work. I took a random pressed CD, used isoinfo to find that there were 160525 blocks on it, and then used dd to read the blocks, with bs=2k count=160525. It stops at 160484 blocks with an IO error every time. Turning off readahead with hdparm doesn't make any difference. The interesting thing is, 160484 = 2 * 2 * 53 * 757. If this is indeed a block readahead problem, then the readahead block size is 8k max. (unless it's 106k, but that seems unlikely to me). However, if it's 8k, then it should read at least up to the last 4 blocks, and not stop 41 blocks before the end. So, it's either not a block readahead problem, or I'm missing something. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
Lourens Veen wrote: On Wed 8 October 2003 05:09, Rob Bogus wrote: Volker Kuhlmann wrote: Esteemed gurus, if anyone is able to shed some more light on this kernel problem I'd appreciate it. It's been going on for years. When reading the whole of an iso9660 filesystem from a cd or dvd, I often get I/O errors within the last blocks of the filesystem. Using snip This is caused by reading past the end of written data. You can either (a) get the size of the ISO filesystem with cdrecord or isoinfo, and then use dd to read only what's valid, or complain to the creator of the CD. There's an option which fixes this, from memory -dao. Actually, that doesn't work. I took a random pressed CD, used isoinfo to find that there were 160525 blocks on it, and then used dd to read the blocks, with bs=2k count=160525. It stops at 160484 blocks with an IO error every time. Turning off readahead with hdparm doesn't make any difference. The interesting thing is, 160484 = 2 * 2 * 53 * 757. If this is indeed a block readahead problem, then the readahead block size is 8k max. (unless it's 106k, but that seems unlikely to me). However, if it's 8k, then it should read at least up to the last 4 blocks, and not stop 41 blocks before the end. So, it's either not a block readahead problem, or I'm missing something. Well, it could be a bad CD ;-) I just tried using dd on my old burner (real SCSI), my recent burner (ATAPI+ide-scsi), and the 52x reader only (ATAPI+ide-cd) and a Redhat 2.4.18-24.8.0 kernel, and no error on any of them. I can't try a 2.6 kernel without rebooting, but I'll try that at work. Could be media, hardware/firmware, or as you say, something we don't understand. Another thought, with some older cdrecord versions I convinced myself that using -pad making the ISO image was more successful than using the option in cdrecord. Don't know if that was/is true or just based on too few trials. Also seem to remember that readcd works differently with the ide-cd driver. Too many possibilities, and Joerg is not motivated to do anything with Linux except whine that the kernel people doing the work won't take orders and do it his way. -- E. Robert Bogusta It seemed like a good idea at the time
Re: linux kernel error reading end of cd/dvd
On Wed 8 October 2003 13:03, Rob Bogus wrote: Well, it could be a bad CD ;-) I just tried using dd on my old burner (real SCSI), my recent burner (ATAPI+ide-scsi), and the 52x reader only (ATAPI+ide-cd) and a Redhat 2.4.18-24.8.0 kernel, and no error on any of them. I can't try a 2.6 kernel without rebooting, but I'll try that at work. I'm running a standard 2.4.21 kernel.org kernel. My original experiment was with my LG DVD-ROM (ATAPI+ide-cd). I tried the same CD in my burner (LiteOn, ATAPI+ide-scsi) and it gives the same error. I've also tried a different CD, with 38789, and it reads correctly in both, as did another burned CD with 14425 blocks. I tried mounting the CD that did not work, and copy all files off of it. No problems there. Perhaps it's some sort of odd copy protection? (it's a Nero install CD that came with my burner, I figured I'd paid for it but never used it before so now would be a good time :-)) Could be media, hardware/firmware, or as you say, something we don't understand. Well, I'm not at all sure what it is anymore now. Perhaps it's just the quality of CDs that's less than people expect. Another thought, with some older cdrecord versions I convinced myself that using -pad making the ISO image was more successful than using the option in cdrecord. Don't know if that was/is true or just based on too few trials. Also seem to remember that readcd works differently with the ide-cd driver. Hmm, I've never used the -pad option either way, can't comment there. Too many possibilities, and Joerg is not motivated to do anything with Linux except whine that the kernel people doing the work won't take orders and do it his way. He doesn't seem to be doing much with cdrecord at all lately. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
From: Volker Kuhlmann [EMAIL PROTECTED] (I scripted that a long time ago). In the mid nineties it was necessary to use cdrecord -pad to make linux read all the files, described as read-ahead bug in linux's iso9660 driver in the cdrecord man page. When I checked again a few years ago it was still necessary to use -pad, so I kept on always using it as a matter of course. This year I find that cdrecord -pad is no longer enough, and the same problem shows up again. It affects cds and dvds, and all pressed commercial cds cerated on non-linux systems. The problem shows up at varying degrees, I suspect it has to do with the modulus of the number of filesystem blocks of the particular disk. Several times I was unable to completely read the filesystem from cds, I/O error 2 or more blocks beore its end no matter what I did. Often it helps to use dd skip= to only read the last 10 filesystem blocks, and it works. Reading all filesystem blocks from the beginning, or from a suitably large distance from the end - I/O error. Sometimes the problem goes away when turning DMA off for the cd/dvdrom drive, but that is not an acceptable way of running it. I really doubt it's hardwaredependent, as I have seen it on 3 totally different machines now. Kernels 2.4.19, 2.4.20. It doesn't help that read problems on a cd/dvd can cause the IDE bus, if not the system, to lock up for some time. Appending 2MB of zeroes to the disk image file before burning makes it disappear reliably. I keep on wasting CDs because I forget to append that dummy data. This is wrong. There is no need to use -pad! If you use unapropriate software like dd and don't even send a problem report, it is impossible to help you :-( http://www.fokus.fhg.de/research/cc/glone/employees/joerg.schilling/private/problems.html mkisofs now adds paddinf for a long time Unfortunately, the Linux kernel hackers constantly add new bugs to the kernel :-( It would really be nice if they woutl start to listen to people who know how to do things right. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
From: Lourens Veen [EMAIL PROTECTED] I'd appreciate it. It's been going on for years. snip This state of affairs is not really acceptable. Does anyone know what the problem is caused by, and what can/should be done about it? Why are you mailing cdwrite? If it's a kernel bug, you should send a bug report to linux-kernel I'd say. Posting it here is just going to get you another Linus is stupid remark from Jörg, and probably not much of a resolution. Right :-( He unfortunately not even send a error message. Using dd is a bad idea and only readcd will give helpful messages in case the medium is not readable. For more information, he should read README.copy README.verify Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
On Wed 8 October 2003 05:09, Rob Bogus wrote: Volker Kuhlmann wrote: Esteemed gurus, if anyone is able to shed some more light on this kernel problem I'd appreciate it. It's been going on for years. When reading the whole of an iso9660 filesystem from a cd or dvd, I often get I/O errors within the last blocks of the filesystem. Using snip This is caused by reading past the end of written data. You can either (a) get the size of the ISO filesystem with cdrecord or isoinfo, and then use dd to read only what's valid, or complain to the creator of the CD. There's an option which fixes this, from memory -dao. Actually, that doesn't work. I took a random pressed CD, used isoinfo to find that there were 160525 blocks on it, and then used dd to read the blocks, with bs=2k count=160525. It stops at 160484 blocks with an IO error every time. Turning off readahead with hdparm doesn't make any difference. The interesting thing is, 160484 = 2 * 2 * 53 * 757. If this is indeed a block readahead problem, then the readahead block size is 8k max. (unless it's 106k, but that seems unlikely to me). However, if it's 8k, then it should read at least up to the last 4 blocks, and not stop 41 blocks before the end. So, it's either not a block readahead problem, or I'm missing something. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: linux kernel error reading end of cd/dvd
Lourens Veen wrote: On Wed 8 October 2003 05:09, Rob Bogus wrote: Volker Kuhlmann wrote: Esteemed gurus, if anyone is able to shed some more light on this kernel problem I'd appreciate it. It's been going on for years. When reading the whole of an iso9660 filesystem from a cd or dvd, I often get I/O errors within the last blocks of the filesystem. Using snip This is caused by reading past the end of written data. You can either (a) get the size of the ISO filesystem with cdrecord or isoinfo, and then use dd to read only what's valid, or complain to the creator of the CD. There's an option which fixes this, from memory -dao. Actually, that doesn't work. I took a random pressed CD, used isoinfo to find that there were 160525 blocks on it, and then used dd to read the blocks, with bs=2k count=160525. It stops at 160484 blocks with an IO error every time. Turning off readahead with hdparm doesn't make any difference. The interesting thing is, 160484 = 2 * 2 * 53 * 757. If this is indeed a block readahead problem, then the readahead block size is 8k max. (unless it's 106k, but that seems unlikely to me). However, if it's 8k, then it should read at least up to the last 4 blocks, and not stop 41 blocks before the end. So, it's either not a block readahead problem, or I'm missing something. Well, it could be a bad CD ;-) I just tried using dd on my old burner (real SCSI), my recent burner (ATAPI+ide-scsi), and the 52x reader only (ATAPI+ide-cd) and a Redhat 2.4.18-24.8.0 kernel, and no error on any of them. I can't try a 2.6 kernel without rebooting, but I'll try that at work. Could be media, hardware/firmware, or as you say, something we don't understand. Another thought, with some older cdrecord versions I convinced myself that using -pad making the ISO image was more successful than using the option in cdrecord. Don't know if that was/is true or just based on too few trials. Also seem to remember that readcd works differently with the ide-cd driver. Too many possibilities, and Joerg is not motivated to do anything with Linux except whine that the kernel people doing the work won't take orders and do it his way. -- E. Robert Bogusta It seemed like a good idea at the time
Re: linux kernel error reading end of cd/dvd
On Wed 8 October 2003 13:03, Rob Bogus wrote: Well, it could be a bad CD ;-) I just tried using dd on my old burner (real SCSI), my recent burner (ATAPI+ide-scsi), and the 52x reader only (ATAPI+ide-cd) and a Redhat 2.4.18-24.8.0 kernel, and no error on any of them. I can't try a 2.6 kernel without rebooting, but I'll try that at work. I'm running a standard 2.4.21 kernel.org kernel. My original experiment was with my LG DVD-ROM (ATAPI+ide-cd). I tried the same CD in my burner (LiteOn, ATAPI+ide-scsi) and it gives the same error. I've also tried a different CD, with 38789, and it reads correctly in both, as did another burned CD with 14425 blocks. I tried mounting the CD that did not work, and copy all files off of it. No problems there. Perhaps it's some sort of odd copy protection? (it's a Nero install CD that came with my burner, I figured I'd paid for it but never used it before so now would be a good time :-)) Could be media, hardware/firmware, or as you say, something we don't understand. Well, I'm not at all sure what it is anymore now. Perhaps it's just the quality of CDs that's less than people expect. Another thought, with some older cdrecord versions I convinced myself that using -pad making the ISO image was more successful than using the option in cdrecord. Don't know if that was/is true or just based on too few trials. Also seem to remember that readcd works differently with the ide-cd driver. Hmm, I've never used the -pad option either way, can't comment there. Too many possibilities, and Joerg is not motivated to do anything with Linux except whine that the kernel people doing the work won't take orders and do it his way. He doesn't seem to be doing much with cdrecord at all lately. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: linux kernel error reading end of cd/dvd
From: Volker Kuhlmann [EMAIL PROTECTED] (I scripted that a long time ago). In the mid nineties it was necessary to use cdrecord -pad to make linux read all the files, described as read-ahead bug in linux's iso9660 driver in the cdrecord man page. When I checked again a few years ago it was still necessary to use -pad, so I kept on always using it as a matter of course. This year I find that cdrecord -pad is no longer enough, and the same problem shows up again. It affects cds and dvds, and all pressed commercial cds cerated on non-linux systems. The problem shows up at varying degrees, I suspect it has to do with the modulus of the number of filesystem blocks of the particular disk. Several times I was unable to completely read the filesystem from cds, I/O error 2 or more blocks beore its end no matter what I did. Often it helps to use dd skip= to only read the last 10 filesystem blocks, and it works. Reading all filesystem blocks from the beginning, or from a suitably large distance from the end - I/O error. Sometimes the problem goes away when turning DMA off for the cd/dvdrom drive, but that is not an acceptable way of running it. I really doubt it's hardwaredependent, as I have seen it on 3 totally different machines now. Kernels 2.4.19, 2.4.20. It doesn't help that read problems on a cd/dvd can cause the IDE bus, if not the system, to lock up for some time. Appending 2MB of zeroes to the disk image file before burning makes it disappear reliably. I keep on wasting CDs because I forget to append that dummy data. This is wrong. There is no need to use -pad! If you use unapropriate software like dd and don't even send a problem report, it is impossible to help you :-( http://www.fokus.fhg.de/research/cc/glone/employees/joerg.schilling/private/problems.html mkisofs now adds paddinf for a long time Unfortunately, the Linux kernel hackers constantly add new bugs to the kernel :-( It would really be nice if they woutl start to listen to people who know how to do things right. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Re: linux kernel error reading end of cd/dvd
From: Lourens Veen [EMAIL PROTECTED] I'd appreciate it. It's been going on for years. snip This state of affairs is not really acceptable. Does anyone know what the problem is caused by, and what can/should be done about it? Why are you mailing cdwrite? If it's a kernel bug, you should send a bug report to linux-kernel I'd say. Posting it here is just going to get you another Linus is stupid remark from Jörg, and probably not much of a resolution. Right :-( He unfortunately not even send a error message. Using dd is a bad idea and only readcd will give helpful messages in case the medium is not readable. For more information, he should read README.copy README.verify Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Re: linux kernel error reading end of cd/dvd
On Wed 8 October 2003 13:41, Lourens Veen wrote: On Wed 8 October 2003 13:03, Rob Bogus wrote: Well, it could be a bad CD ;-) I just tried using dd on my old burner (real SCSI), my recent burner (ATAPI+ide-scsi), and the 52x reader only (ATAPI+ide-cd) and a Redhat 2.4.18-24.8.0 kernel, and no error on any of them. I can't try a 2.6 kernel without rebooting, but I'll try that at work. I'm running a standard 2.4.21 kernel.org kernel. My original experiment was with my LG DVD-ROM (ATAPI+ide-cd). I tried the same CD in my burner (LiteOn, ATAPI+ide-scsi) and it gives the same error. I've also tried a different CD, with 38789, and it reads correctly in both, as did another burned CD with 14425 blocks. As Jörg said in his out-of-thread mail that readcd is better than dd, just for fun I gave readcd a go with the broken CD. It sees 169825 blocks (where isoinfo saw 160525) and could read 160512 of them before giving an IO error. Interesting. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: linux kernel error reading end of cd/dvd
Volker Kuhlmann wrote: Esteemed gurus, if anyone is able to shed some more light on this kernel problem I'd appreciate it. It's been going on for years. When reading the whole of an iso9660 filesystem from a cd or dvd, I often get I/O errors within the last blocks of the filesystem. Using cat /dev/cdrom as test is not a good idea, as the kernel often has problems detecting the end of the recording on the media (however it does that). Also, reading additional blocks past the end of the filesystem makes it impossible to use md5 sums. A better way is to obtain the number of blocks used by the filesystem and reading exactly that many blocks: isoinfo -d -i /dev/cdrom dd if=/dev/cdrom bs=2k count=X (I scripted that a long time ago). In the mid nineties it was necessary to use cdrecord -pad to make linux read all the files, described as read-ahead bug in linux's iso9660 driver in the cdrecord man page. When I checked again a few years ago it was still necessary to use -pad, so I kept on always using it as a matter of course. This year I find that cdrecord -pad is no longer enough, and the same problem shows up again. It affects cds and dvds, and all pressed commercial cds cerated on non-linux systems. The problem shows up at varying degrees, I suspect it has to do with the modulus of the number of filesystem blocks of the particular disk. Several times I was unable to completely read the filesystem from cds, I/O error 2 or more blocks beore its end no matter what I did. Often it helps to use dd skip= to only read the last 10 filesystem blocks, and it works. Reading all filesystem blocks from the beginning, or from a suitably large distance from the end - I/O error. Sometimes the problem goes away when turning DMA off for the cd/dvdrom drive, but that is not an acceptable way of running it. I really doubt it's hardwaredependent, as I have seen it on 3 totally different machines now. Kernels 2.4.19, 2.4.20. It doesn't help that read problems on a cd/dvd can cause the IDE bus, if not the system, to lock up for some time. Appending 2MB of zeroes to the disk image file before burning makes it disappear reliably. I keep on wasting CDs because I forget to append that dummy data. The issue could be explained with the kernel always reading whole chunks, and that the chunk size was increased somewhere around 2.4.19 with the effect that cdrecord -pad (writing an extra 15 blocks = 30kb) is no longer sufficient to ensure the last chunk is readable. This is speculation however. This state of affairs is not really acceptable. Does anyone know what the problem is caused by, and what can/should be done about it? This is caused by reading past the end of written data. You can either (a) get the size of the ISO filesystem with cdrecord or isoinfo, and then use dd to read only what's valid, or complain to the creator of the CD. There's an option which fixes this, from memory -dao. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux kernel error reading end of cd/dvd
On Tue 7 October 2003 00:06, Volker Kuhlmann wrote: Esteemed gurus, if anyone is able to shed some more light on this kernel problem I'd appreciate it. It's been going on for years. snip This state of affairs is not really acceptable. Does anyone know what the problem is caused by, and what can/should be done about it? Why are you mailing cdwrite? If it's a kernel bug, you should send a bug report to linux-kernel I'd say. Posting it here is just going to get you another Linus is stupid remark from Jörg, and probably not much of a resolution. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: linux kernel error reading end of cd/dvd
Volker Kuhlmann wrote: Esteemed gurus, if anyone is able to shed some more light on this kernel problem I'd appreciate it. It's been going on for years. When reading the whole of an iso9660 filesystem from a cd or dvd, I often get I/O errors within the last blocks of the filesystem. Using cat /dev/cdrom as test is not a good idea, as the kernel often has problems detecting the end of the recording on the media (however it does that). Also, reading additional blocks past the end of the filesystem makes it impossible to use md5 sums. A better way is to obtain the number of blocks used by the filesystem and reading exactly that many blocks: isoinfo -d -i /dev/cdrom dd if=/dev/cdrom bs=2k count=X (I scripted that a long time ago). In the mid nineties it was necessary to use cdrecord -pad to make linux read all the files, described as read-ahead bug in linux's iso9660 driver in the cdrecord man page. When I checked again a few years ago it was still necessary to use -pad, so I kept on always using it as a matter of course. This year I find that cdrecord -pad is no longer enough, and the same problem shows up again. It affects cds and dvds, and all pressed commercial cds cerated on non-linux systems. The problem shows up at varying degrees, I suspect it has to do with the modulus of the number of filesystem blocks of the particular disk. Several times I was unable to completely read the filesystem from cds, I/O error 2 or more blocks beore its end no matter what I did. Often it helps to use dd skip= to only read the last 10 filesystem blocks, and it works. Reading all filesystem blocks from the beginning, or from a suitably large distance from the end - I/O error. Sometimes the problem goes away when turning DMA off for the cd/dvdrom drive, but that is not an acceptable way of running it. I really doubt it's hardwaredependent, as I have seen it on 3 totally different machines now. Kernels 2.4.19, 2.4.20. It doesn't help that read problems on a cd/dvd can cause the IDE bus, if not the system, to lock up for some time. Appending 2MB of zeroes to the disk image file before burning makes it disappear reliably. I keep on wasting CDs because I forget to append that dummy data. The issue could be explained with the kernel always reading whole chunks, and that the chunk size was increased somewhere around 2.4.19 with the effect that cdrecord -pad (writing an extra 15 blocks = 30kb) is no longer sufficient to ensure the last chunk is readable. This is speculation however. This state of affairs is not really acceptable. Does anyone know what the problem is caused by, and what can/should be done about it? This is caused by reading past the end of written data. You can either (a) get the size of the ISO filesystem with cdrecord or isoinfo, and then use dd to read only what's valid, or complain to the creator of the CD. There's an option which fixes this, from memory -dao. -- E. Robert Bogusta It seemed like a good idea at the time
Re: linux kernel error reading end of cd/dvd
On Tue 7 October 2003 00:06, Volker Kuhlmann wrote: Esteemed gurus, if anyone is able to shed some more light on this kernel problem I'd appreciate it. It's been going on for years. snip This state of affairs is not really acceptable. Does anyone know what the problem is caused by, and what can/should be done about it? Why are you mailing cdwrite? If it's a kernel bug, you should send a bug report to linux-kernel I'd say. Posting it here is just going to get you another Linus is stupid remark from Jörg, and probably not much of a resolution. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
