Hi, B.M. wrote: > If you want you can have a look at my script, I attached it to this mail...
Will do. (There must be some rational explanation ...) > "Filesystem full" is not handled at all. Typically if this happens it's > quite late i.e. most folders are already backuped and I do the following: > - remove the last lz-file, I never checked if it is corrupted > - burn the image No cryptsetup luksClose /dev/mapper/BDbackup between remove and burn ? ----------------------------------------------------------------------- I wrote: > > But growisofs formats it [BD-R] by default to 11,826,176 = 23098 MiB = > > 23,652,352 KiB. > I didn't know that growisofs gives away a few bytes... Do you know why > that's the case? Andy Polyakov decided to format BD-R by default. Possibly because he used an operating system (IIRC, Solaris) which did not expect that BD-R can be used for multi-session. So its mount program followed the volume descriptors starting at block 16 rather than at 16 blocks after the start of the youngest session. Whatever, growisofs by default wants to update the volume descriptors at block 16 of the BD-R and for this uses BD-R Pseudo-Overwrite formatting. This special feature uses the Defect Management to replace old written blocks by newly written blocks. Formatted BD-R cause the drive to perform Defect Management when writing. This means half write speed at best, heavy clonking with smaller write quality problems, and often miserable failure on media which work well unformatted. > Never heard about xorriso before It makes ISO 9660 filesystems and burns them to optical media. I am its developer. > - from my understanding I could use it instead of growisofs, but with > larger images? Be invited. :)) Image burning is handled by its cdrecord emulation mode. growisofs -dvd-compat -Z /dev/dvd=$IMGFILE; eject translates to xorriso -as cdrecord -v dev=/dev/dvd -eject $IMGFILE But xorriso (in particular: libburn) cannot write more bytes to a BD-R than growisofs with option -use-the-force-luke=spare=none can do. It's just a matter of program defaults, in this case. (There are other cases where think to have outperformed growisofs.) > > -use-the-force-luke=spare=... > I didn't use these options. That's why i riddle why your burns do not fail in the end. What do you get from a run of dvd+rw-mediainfo /dev/dvd or xorriso -outdev /dev/dvd -toc -list_formats with the burnt DB-R medium in /dev/dvd ? > General question: > Do you think I should completely change my script such that it creates lz- > files, encrypts each of them and then writes them on an unencrypted disc? We should first find out why your procedure produces a bad encrypted image when you do your manual overflow handling. In the case of no overflow it looks perfectly ok. The result has some advantages over a home-made encryption of file content or the whole filesystem. (I am still looking for a stream facility which produces encryption which can later be put on a block device and decrypted by a /dev/mapper device. Your way of creating a big image has the disadvantage of needing extra disk space. Cool would be to write directly to the BD-R. But it is a block device only for reading, not when it gets written.) I have a backup use case where i define an encryption filter and apply it to data file content. The filter makes use of an external encryption program which can operate on data streams. (In this case it is self-made from some published encryption algorithm. But any stream capable encryption program which can read the key from a file should do.) It is for multi-session. So the /dev/mapper approach will meet more problems. I doubt that dm-crypt handles growing devices. Have a nice day :) Thomas