Re: CLOSE SESSION failed with SK=5h/INVALID FIELD IN CDB: not harmless?
Hi, The reason to use O_DIRECT is to avoid impact on the performance of other processes in the system, rather than to improve speed. The odd point is that mmap() versus calloc() influences SG_IO write speed. The read performance from disk was sufficient in all the tests. (fifo well filled, drive buffer oscillating between 0 % to 90 %.) growisofs uses SG_IO flag SG_FLAG_DIRECT_IO but disabling it did not influence its writing speed on my USB bus. To disable O_DIRECT on reading showed minimal but reproducible slowdown. To replace mmap() by calloc() reduced growisofs to the speed of xorriso-0.4.4. That's 10x rather than 11x. cdrskin-0.7.2 used a fifo which involved a pipe(2). Very bad for SG_IO throughput. 7x DVD speed only. The pipe itself delivers 200x (two hundred). With 64 kB write chunks the pipe does not do much harm any more. I gave it up, nevertheless. With 64 kB chunks, mmap() and no pipe xorriso achieves 15x meanwhile. But my drive could 16x. G. My USB bus is in some way hampered with SG_IO. The handling of input influences this quite surprisingly. xorriso is reproducibly faster than cdrskin although both use the same fifo object now, and the same burn thread. The only difference is the application thread which runs a lazy wait loop that only watches the other two threads. This all happens while the CPU is idle enough to slow down to 1000 MHz. It could do 3000 if only there was work for it. Others have similar odd behavior. In one case changing the cable connection from eSATA to USB slowed down the same drive at the same computer from 20x DVD to 14x. But there are also weak SATA drives. No clear pattern to recognize. 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: 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. The reason to use O_DIRECT is to avoid impact on the performance of other processes in the system, rather than to improve speed. By doing io directly to user buffers data in system buffers used by most programs is no overwritten. On an empty system O_DIRECT is slightly slower than buffered io, unless asyncronous multiple buffers are used. That's too complex for most people, and the slowdown is in the 10% range, so burner buffers stay full. 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. You can manually allocate a large buffer and then use bit operators to force the address to be page aligned. Again, most user would rather use mmap() which does that for you. 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. Again, there's a reason for that, the max USB packet size is set to 64 by default, performance can be improved by setting to the max allowed in the kernel, which was 256 the last time I looked. This makes a big difference with some disks and tapes as well. /sys/bus/usb/devices/usbX/bMaxPacketSize0 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. -- Bill Davidsen david...@tmr.com We can't solve today's problems by using the same thinking we used in creating them. - Einstein
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
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
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
CLOSE SESSION failed with SK=5h/INVALID FIELD IN CDB: not harmless?
So I decided I wanted to back up my Windows drive, which is NTFS. Since there are very big files there, very deep directories, crazy filenames, etc. I figure UDF is the way to go. The total size was 37GB. I've got a Blu-Ray burner and so I figure I'll buy a BD-R DL disc and do it. Since I didn't want a very expensive coaster I figured I'll master the UDF filesystem first, then burn it. I use mkudffs: mkudffs -r 0x0201 --vid=Old C --media-type=hd --utf8 /video/oldc_backup.udf 20971520 Then I mount this filesystem, and copy all of the files into the filesystem. Unmount the filesystem, now I'm ready to go. Now I run: growisofs -Z /dev/sr1=/video/oldc_backup.udf This runs for a long time, so I return later and find at the end of the output: 42919985152/42949672960 (99.9%) @0.7x, remaining 0:09 RBU 88.5% UBU 98.3% 42930864128/42949672960 (100.0%) @0.7x, remaining 0:06 RBU 56.1% UBU 98.3% 42941349888/42949672960 (100.0%) @0.7x, remaining 0:02 RBU 24.8% UBU 98.3% builtin_dd: 20971520*2KB out @ average 0.7x4390KBps /dev/sr1: flushing cache /dev/sr1: closing track /dev/sr1: closing session :-[ CLOSE SESSION failed with SK=5h/INVALID FIELD IN CDB]: Input/output error So now I try to mount the disc. Well, this is where things really go weird. Mount works ok: smally$ sudo mount -t udf -o ro /dev/sr1 /mnt smally$ echo $? 0 However, there doesn't seem to be anything there: smally$ ls -a /mnt . smally$ Gack! Could there be something wrong with the file image? It would seem not, because I can mount the UDF image just fine: smally$ sudo mount -t udf -o loop,ro /video/oldc_backup.udf /mnt smally$ ls /mnt ADOBEAPPfavorite.way PMig.Log AUTOEXEC.BATGarmin Program Files bdb-4.2.52 I386 Python23 bin Inetpub Python24 Boost inferno.log Python25 boot.iniIO.SYS RECYCLER BOOTSECT.DOSj2sdk1.4.1_02svn-win32-1.0.2 Config.Msi LogiSetup.logsvn-win32-1.1.2 CONFIG.SYS lost+found SWIG-1.3.21 [...] So I figure I'll find out what is on the media: smally$ sudo dvd+rw-mediainfo /dev/sr1 INQUIRY:[HL-DT-ST][BD-RE GGW-H20N ][XJ03] GET [CURRENT] CONFIGURATION: Mounted Media: 41h, BD-R SRM+POW Media ID: MEI/T01 Current Write Speed: 2.0x4495=8991KB/s Write Speed #0:2.0x4495=8991KB/s GET [CURRENT] PERFORMANCE: Write Performance: 2.0x4495=8991KB/s...@[0 - 12088319] 2.0x4495=8991KB/s...@[12088320 - 24307711] Speed Descriptor#0:02/24307711 r...@2.0x4495=9158kb/s w...@2.0x4495=8991kb/s BD SPARE AREA INFORMATION: Spare Area:65088/65536=99.3% free POW RESOURCES INFORMATION: Remaining Replacements:16843296 Remaining Map Entries: 0 Remaining Updates: 0 READ DISC INFORMATION: Disc status: appendable Number of Sessions:1 State of Last Session: incomplete Next Track: 1 Number of Tracks: 2 READ TRACK INFORMATION[#1]: Track State: partial incremental Track Start Address: 0*2KB Free Blocks: 0*2KB Track Size:20971680*2KB READ TRACK INFORMATION[#2]: Track State: invisible incremental Track Start Address: 20971680*2KB Next Writable Address: 20971680*2KB Free Blocks: 3336032*2KB Track Size:3336032*2KB FABRICATED TOC: Track#1 : 1...@0 Track#AA : 1...@24307712 Multi-session Info:#...@0 READ CAPACITY: 24307712*2048=49782194176 smally$ Looking at the track size it is in fact just a bit bigger than the udf image file. I fired up an interactive python session and opened up /dev/sr1 to see if I could seek around and read stuff, which I could. So could anyone help me understand what's going on? If there's some way to fix the written session that would be great. Or at least I'd like to figure out what is happening so I can avoid making any further $40 coasters. I'm using dvd+rw-tools 7.1-4 (ubuntu version) in ubuntu version 9.10. Kernel is: smally$ uname -a Linux smally 2.6.30 #1 SMP Sun Nov 1 18:56:42 SGT 2009 i686 GNU/Linux built locally from git tag for 2.6.30. Thanks in advance for any help. -- 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, BD-R DL disc mkudffs -r 0x0201 --vid=Old C --media-type=hd --utf8 /video/oldc_backup.udf 20971520 growisofs -Z /dev/sr1=/video/oldc_backup.udf builtin_dd: 20971520*2KB out @ average 0.7x4390KBps Looks like 2x BD speed with Defect Management enabled. This makes really long run times. But well, i would not dare to run a BD-R DL without Defect Management. It is just too big and too expensive to risk entire failure with a single bad spot. /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. 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. Said that, i want to mention that ISO 9660 is well able to host files larger than 4 GB and that current Linux can read such big files out of ISO images correctly. (Older Linux cannot.) My program xorriso produces such images and/or burns them to media. Given the price of BD-R DL and the fact that i never burned such a media, i would advise that you eventually make two BD-RE or BD-R rather than one BD-R DL. xorriso would be able to read the ISO filesystem independently of the Linux mount facility. So in case of problems, one would have more chance to find out what's wrong, and in case of Linux bugs one would be able to retrieve files from a sane ISO image. 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
