Re: CLOSE SESSION failed with SK=5h/INVALID FIELD IN CDB: not harmless?
Thomas Schmitt wrote: 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. Is it possible that this is caused by a relocated block, and for some reason the read is returning the bad block in stead of the relocation? In other words, did this mount somehow tell the device to ignore relocation? Might this be fixed with only a mount option (which I certainly didn't see)? 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. -- E. Robert Bogusta It seemed like a good idea at the time -- 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, Jens Jorgensen: Could it be that there was a defect and things were relocated? me : It should be transparent to the reader in any case. ... So this could be a failure of the firmware to correctly perform Defect Management. Rob Bogus: Is it possible that this is caused by a relocated block, and for some reason the read is returning the bad block in stead of the relocation? In other words, did this mount somehow tell the device to ignore relocation? It would be a severe firmware bug or failure of the media to properly record the correction mapping of physical records. I am not really convinced of such a failure yet. Might this be fixed with only a mount option (which I certainly didn't see)? One possibly can disable the effect of Defect Management by the Streaming Bit of SCSI command 28h READ(12). At least i read MMC-5 6.16.2.6 that way: If the Streaming bit is set to one, linear replacements shall not be performed. One would have to search in the kernel whether command 28h is used and whether bit 7 in byte 10 of the command can be set. But i would be astounished if that was the default with BD mounting resp. with the involved device driver. Also it does not explain why the zeroed block at address 8 MB causes a mountable empty UDF filesystem with no error messages in the kernel log. Jens: Then I mount this filesystem, and copy all of the files into the filesystem. Unmount the filesystem, now I'm ready to go. Is there any way how after umounting of the filesystem the content is still not up to date for subsequent reading of the file ? The image file got opened by growisofs via open64(O_DIRECT|O_RDONLY). 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
Mutual Benefits.
My Name is SGT Grag Morris. I have a business proposal that will be of great mutual benefits to both of us if you are interested please email me via my personal email.(sgt_grag_morr...@admin.in.thmailto:sgt_grag_morr...@admin.in.th) Regards, Grag Morris This communication is intended for the use of the recipient to which it is addressed, and may contain confidential, personal, and or privileged information. Please contact us immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on it. Any communication received in error, or subsequent reply, should be deleted or destroyed. -- 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: Is there any way how after umounting of the filesystem the content is still not up to date for subsequent reading of the file ? The image file got opened by growisofs via open64(O_DIRECT|O_RDONLY). Jens Jorgensen: Well there's a scary thought. I guess I would hope that opening with O_DIRECT would maybe cause a flush of dirty pages for this file? It is only a shot in the dark. One would have to test whether e.g. command sync or umounting and remounting the hosting filesystem would prepare the image file for flawless copying to media. With other image types there was never such an effect. But a mounted UDF random access filesystem might have its own i/o peculiarities. O_DIRECT itself is still quite obscure to me. The opinion on LKML is mainly against using it. We have people here on this list who oppose that opinion. I had to explore the i/o behavior of growisofs because on some hampered busses on Linux it was faster with writing than libburn. Using O_DIRECT on reading had only a slightly accelerating effect on writing. But it turned out that the main advantage of growisofs is in buffer allocation via mmap() which seems necessary with using O_DIRECT. Such side effects are ill, of course. The CPU is mainly idle. So something in the Linux i/o is stumbeling over its own feet. This happens quite often with USB busses but there are also SATA and IDE connections which do not transmit full 16x or 20x DVD speed. The best trick with such busses is to write 64 KB chunks rather than the usual 32 KB. This normally beats O_DIRECT reading significantly. So i decided to use mmap() buffer, to offer 64 KB chunks optionally at run time and O_DIRECT optionally at compile time. 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
