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 00 00 00 00 00 Sense Key: 0x5 Illegal Request, Segment 0 Sense Code: 0x64 Qual 0x00 (illegal mode for this track) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 2.967s timeout 40s readcd: Input/output error. Cannot read source disk readcd: Retrying from sector 349524. .............................................~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~ readcd: Input/output error. Error on sector 349568 not corrected. Total of 1 errors. readcd: Input/output error. read_g1: scsi sendcmd: no error CDB: 28 00 00 05 55 80 00 00 01 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 64 00 00 00 00 00 Sense Key: 0x5 Illegal Request, Segment 0 Sense Code: 0x64 Qual 0x00 (illegal mode for this track) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 1.440s timeout 40s Time total: 520.137sec Read 699048.00 kB at 1344.0 kB/sec. ------------------------------------------------------------------------ Elapsed time (wallclock): 0:08:40 (if shell supports $SECONDS) readcd has produced a file which is 349524 blocks long, 28 blocks short of 349552. It says "end: 349569", which is 2 blocks more than the additional 15 blocks of cdrecord -pad. When I limited speed to 16x it died at the same block 349524. readcd finishes with "Error on sector 349568", well no surprise there, it's past the end of 349552+15. It fails to write out the data of block 349524 to 349567 before exiting, this is a bug. I ejected the CD, re-inserted it and tried dd: dd bs=2k count=349552 if=/dev/cdrom of=somedisk-dd.iso ======================================================================== 349552+0 records in 349552+0 records out ------------------------------------------------------------------------ Elapsed time (wallclock): 0:04:29 (if shell supports $SECONDS) Well that much for readcd being better suited than dd! The output file created by dd is correct (verified by md5 sum). Of course, the very same dd operation failed no matter how often I tried a week ago after I burnt the disk. I hate this... > 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 also that the disk is only half full, so the "errors at edge" doesn't apply. Of course there might still be a real disk error there. When I see these funnies, they mostly are within a few blocks of the end of the filesystem, and always within a few hundred blocks of it. I have never observed any of this nonsense on any disk which I've appended generously with zeroes. I can't accept that media errors are the root cause of this. 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]