Re: CLOSE SESSION failed with SK=5h/INVALID FIELD IN CDB: not harmless?
Thomas Schmitt wrote: > Hi, > >> /dev/sr1: flushing cache >> /dev/sr1: closing track >> /dev/sr1: closing session >> :-[ CLOSE SESSION failed with SK=5h/INVALID FIELD IN CDB]: Input/output >> > > Such a message is rarely harmless. > The drive wrote everything but failed > to finish properly. > Well, that's what I thought, but Andy Polyakov commented here: http://www.mail-archive.com/cdwrite@other.debian.org/msg12106.html that it was "harmless" though I'm not sure if his comment applies in this instance. >> Mount works ok: >> However, there doesn't seem to be anything there: >> smally$ ls -a /mnt >> . >> > > So the file tree was not read properly. > No chance to verify any data this way. > > I see two possible reasons of failure here: > - MMC which rules the writing of data to the > media. > - UDF which rules the reading of file tree > and the access to file contents. > > To check the correctness of the MMC writing > process, compare the whole media content with > your image file > dd if=/dev/sr1 bs=2048 count=20971520 | \ > diff - /video/oldc_backup.udf > > If this verifies correctly, then UDF mount > is to blame. Possibly it does not find its > superblock. > For help with UDF checking you will probably > have to look at some other mailing list. > I should have run the command above already. I've done it now and I see: smally$ sudo cmp /dev/sr1 /video/oldc_backup.udf ; echo $? /dev/sr1 /video/oldc_backup.udf differ: byte 8585217, line 20010 (my command seemed simpler :-) and as effective) So again I fired up python so I could easily seek around in the disk and udf image and read the block at 8585216 (cmp's reported offsets are origin-1, how annoying eh?). When I read the block from /dev/sr0 what I get back is all-zeroes. The corresponding block on the udf image is full of non-zero data. The preceding 2048 byte block on both media are full of non-zero data. Now that I'm on it, I noticed that 8585216 % 64Ki == 0, so this block is indeed at the start of a Blu-ray block (wikipedia says that BD blocks are 64KiB). Exploring further, I noticed that the next 2048-byte block following 8585216 on /dev/sr1 is non-zero. In fact, looking at it I can see that it is the program header of a windows exe. So it is in fact the logical start of a file. Strange no? Could it be coincidence? Noting that in the mediainfo we see: BD SPARE AREA INFORMATION: Spare Area:65088/65536=99.3% free Could it be that there was a defect and things were relocated? I don't really know how the spare area is used. BTW Thomas thanks for the info about xorisso! -- Jens B. Jorgensen j...@ultraemail.net -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org
Re: CLOSE SESSION failed with SK=5h/INVALID FIELD IN CDB: not harmless?
Hi, me: > > Such a message is rarely harmless. Jens: > Well, that's what I thought, but Andy Polyakov commented here: > http://www.mail-archive.com/cdwrite@other.debian.org/msg12106.html Oh indeed. Now i remember. I stepped into that puddle previously. So for now we count it as harmless. It is quite out of suspicion anyway. See below. > smally$ sudo cmp /dev/sr1 /video/oldc_backup.udf ; echo $? > /dev/sr1 /video/oldc_backup.udf differ: byte 8585217, line 20010 > (my command seemed simpler :-) and as effective) I wanted to truncate /dev/sr1 to the exact size just in case all bytes before match the original and trailing trash would cause false alert. > When I read the block from /dev/sr0 what I get back is all-zeroes. The > corresponding block on the udf image is full of non-zero data. > the next 2048-byte block following 8585216 on /dev/sr1 is non-zero. Ouchers. That looks much like a failure of transport or drive. It happens far before any Close Session failure could spoil it directly, and it is hard to imagine how such a final problem should leave 8 MB unaltered and spoil a single block of 2048 bytes. If possible try to find out whether there are more differing blocks in the image. It is a bit astounding that a first altered block at that address disturbed the UDF tree without any error message. Did you check your kernel logs already ? > Spare Area:65088/65536=99.3% free > Could it be that there was a defect and things were relocated? I don't > really know how the spare area is used. Actually i never saw it doing any good. It should be transparent to the reader in any case. If the drive hands out logical block 4192 then this should be the corrected data which belong to that address. Any physical address change should be hidden from the reader. It seems the Defect Management had reason to exchange some physical blocks. Of course it is suspicious if the media shows altered blocks afterwards. Normally at least the error detection precautions should have indicated a failure. So this could be a failure of the firmware to correctly perform Defect Management. On BD-RE i normally disable it in favor of triple speed and own MD5 checkreading. I have a BD burner and a BD reader drive so that with bulk backups i reach nearly triple throughput by simultaneaously writing and reading. Nevertheless it may also be a failure of transport. Error detection and verifying happens only after the data reached the drive. Well, it would be expensive to make lots of experiments and to compare the outcome. But currently i see not much other opportunity to gain wisdom. My own experience with BD-R and BD-RE tells me that they are quite reliable. At least compared with early DVDs. So if you need that backup then first try single layer media. It should be not too cumbersome to split 37 GB onto 22.5 GB media. (I could provide my splitting backup program scdbackup, though.) Any problem with the bus should show up with BD-RE as much as with BD-R or BD-R DL. > BTW Thomas thanks for the info about xorisso! Google says "Did you mean: xorriso". That makes me proud. It's now famous enough to be a proposal in the spelling check. In the beginning, google proposed "sorriso" instead. xorriso = X/Open on Rock Ridge enhanced ISO 9660. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org
Re: CLOSE SESSION failed with SK=5h/INVALID FIELD IN CDB: not harmless?
Thomas Schmitt wrote: >> When I read the block from /dev/sr0 what I get back is all-zeroes. The >> corresponding block on the udf image is full of non-zero data. >> the next 2048-byte block following 8585216 on /dev/sr1 is non-zero. >> > > Ouchers. > That looks much like a failure of transport or > drive. > It happens far before any Close Session failure > could spoil it directly, and it is hard to > imagine how such a final problem should leave > 8 MB unaltered and spoil a single block of 2048 > bytes. > If possible try to find out whether there are > more differing blocks in the image. > > It is a bit astounding that a first altered > block at that address disturbed the UDF tree > without any error message. > Did you check your kernel logs already ? > Sorry, I should have mentioned that. Yes, indeed I did check the kernel logs and they were clean! This is the only thing in there: [1379091.856282] UDF-fs INFO UDF: Mounting volume 'Old C', timestamp 2009/11/24 22:02 (11e0) So it certainly sees /some/ of the UDF info. Gack! I looked to see if I could find any messages that may have occurred during writing also but no such luck, there are none to be found. FWIW the drive is connected via USB: [1215397.604019] usb 1-2: new high speed USB device using ehci_hcd and address 5 [1215397.737008] usb 1-2: configuration #1 chosen from 1 choice [1215397.737626] scsi8 : SCSI emulation for USB Mass Storage devices [1215397.737706] usb-storage: device found at 5 [1215397.737709] usb-storage: waiting for device to settle before scanning [1215402.736214] usb-storage: device scan complete [1215404.170839] scsi 8:0:0:0: CD-ROMHL-DT-ST BD-RE GGW-H20N XJ03 PQ: 0 ANSI: 0 [1215404.190820] sr1: scsi3-mmc drive: 40x/40x writer dvd-ram cd/rw xa/form2 cdda tray [1215404.191254] sr 8:0:0:0: Attached scsi CD-ROM sr1 [1215404.192384] sr 8:0:0:0: Attached scsi generic sg4 type 5 > Well, it would be expensive to make lots of > experiments and to compare the outcome. > But currently i see not much other opportunity > to gain wisdom. > Certainly! > My own experience with BD-R and BD-RE tells me > that they are quite reliable. At least compared > with early DVDs. > So if you need that backup then first try > single layer media. It should be not too > cumbersome to split 37 GB onto 22.5 GB media. > (I could provide my splitting backup program > scdbackup, though.) > > Any problem with the bus should show up with > BD-RE as much as with BD-R or BD-R DL. > > I have one BD-RE media right now also so I'll give that a try, just to see if I can get some other mistakes. I'll certainly be upset if it's the drive--I've used it hardly at all. It seems that this drive (Buffalo) is an LG OEM and LG has new firmware revisions but Buffalo is not releasing any updates. Bogus! -- Jens B. Jorgensen j...@ultraemail.net -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org
Re: CLOSE SESSION failed with SK=5h/INVALID FIELD IN CDB: not harmless?
Hi, > So it certainly sees /some/ of the UDF info. Gack! It would be quite some strange incident if a zeroed block at a more or less random address would make this all a valid empty UDF filesystem. I am not sure whether the empty mount directory is really caused by the altered block(s). Maybe there is more than one problem at work here. > FWIW the drive is connected via USB: This is sometimes a reason for poor write performance. But 0.7x effective speed is normal for "2x" BD media if Defect Management is enabled. USB is not generally known to alter data during transmission. So for now i would rather suspect the drive's firmware. If other BD media show silent alterations too, then make tests with an USB memory stick on the same USB socket. (Again: It would be interesting to learn whether there are more zeroed blocks on the media.) Have a nice day :) Thomas -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org
