Hi, i wrote: > > No > > cryptsetup luksClose /dev/mapper/BDbackup > > between remove and burn ?
B.M. wrote: > To be honest, I cannot say for sure, so maybe yes. But: what would be the > implication? The fs inside is already unmounted, is cryptsetup luksClose > modifying anything within the image? Good questions. Make some experiments. :)) At least the manual intervention is a good suspect because it occurs exactly when you get undecryptable images. I see in your script: umount /mnt/BDbackup cryptsetup luksClose /dev/mapper/BDbackup losetup -d $IMGLOOP # # Step 5: Burn to BD-R # and would expect that the three lines are there for a reason. Do i understand correctly that the overflow happens in line 173 with the tar run ? tar cf - -C "`dirname "$line"`" "`basename "$line"`" | plzip > "$zipfilename1" If so: What happens next ? Does the script abort without cleaning up ? (I.e. no unmounting, closing, and de-looping by the script ?) > > dvd+rw-mediainfo /dev/dvd > INQUIRY: [PIONEER ][BD-RW BDR-209D][1.30] That's the killer of Verbatim BD-RE. (If you buy BD-RE, then take any other brand, which will probably be made by Ritek.) It's also a super fast BD-R burner and super loud with 10x speed. If you ever use it with unformatted BD-R by growisofs -use-the-force-luke=spare=none ... then consider to curb its speed by e.g. -speed=6 > Mounted Media: 41h, BD-R SRM+POW So it is a BD-R in the default formatting state of growisofs. > Speed Descriptor#0: 00/12088319 R@12.0x4495=53940KB/s The speed descriptor says that it is valid from block 0 to 12088319. That would be the size of 23610 MiB achieved by growisofs option -use-the-force-luke=spare=min I have no idea from growisofs source code in https://sources.debian.org/src/dvd%2Brw-tools/7.1-14/growisofs_mmc.cpp/#L713 why it has chosen this size. I'd expect it came to line 738 i = 8; // grab default descriptor and not to the lines under 721 if (spare == 0) // locate descriptor with maximum capacity But it explains why your burn runs succeeded. (Looking at the patches confuses me even more. One by me is present twice: https://sources.debian.org/src/dvd%2Brw-tools/7.1-14/debian/patches/10-blue-ray-bug713016.patch/ https://sources.debian.org/src/dvd%2Brw-tools/7.1-14/debian/patches/fix_burning_bd-r_discs.patch/ and one other aims to prevent the SRM+POW formatting which you get https://sources.debian.org/src/dvd%2Brw-tools/7.1-14/debian/patches/ignore_pseudo_overwrite.patch/ ) > READ TRACK INFORMATION[#1]: > Track State: partial incremental > Track Start Address: 0*2KB > Free Blocks: 0*2KB > Track Size: 12032000*2KB That's the 24064000K of your image file. All seems well, as far as the BD-R is concerned. > READ TRACK INFORMATION[#2]: > ... > Next Writable Address: 12032000*2KB > Free Blocks: 56320*2KB There would still be 100 MB free for another session. (But don't mess with good backups which are not intended as multi-session.) > I went for the image file solution, which > - while not being "pretty" - should at least work and I'm not disk space > limited (at least as far as the size of a BD is concerned). With BD-RE media and the patience for <= 4.5 MB/s write speed you could install /dev/mapper/BDbackup directly on /dev/dvd, mount and populate it like the encrypted image, umount, execute sync(1), cryptsetup luksClose, and another sync just to be sure. The BD-RE has to be already formatted. Default size by growisofs' companion: dvd+rw-format /dev/dvd (To request other sizes you'll have to study https://sources.debian.org/src/dvd%2Brw-tools/7.1-14/dvd%2Brw-format.cpp/#L258 from where i guess that option -spare=min brings 23610 MiB.) With xorriso i would do: xorriso -outdev /dev/dvd -format by_size_23610m Afterwards the Linux kernel should be able to handle it without the need for a burn program. But also without the neat streaming of image writing and without the opportunity to get full 2x speed (9 MiB/s) by disabling Defect management. Have a nice day :) Thomas