Hello Thomas, On Sat, 2025-01-18 at 09:42 +0100, Thomas Schmitt wrote: > > Hi, > > > > Bob McGowan wrote: > > > > I've been trying to figure out how to use my BD disc writer to > > > > create > > > > backups of files. > > > > I do this by Rock Ridge enhanced ISO 9660 on BD-R and BD-RE media, > > following this example from the man page of xorriso: > > > > xorriso \ > > -abort_on FATAL \ > > -for_backup -disk_dev_ino on \ > > -assert_volid 'PROJECTS_MAIL_*' FATAL \ > > -dev /dev/sr0 \ > > -volid PROJECTS_MAIL_"$(date '+%Y_%m_%d_%H%M%S')" \ > > -not_leaf '*.o' -not_leaf '*.swp' \ > > -update_r /home/thomas/projects /projects \ > > -update_r /home/thomas/personal_mail /personal_mail \ > > -commit -toc -check_md5 FAILURE -- -eject all > > > > To be used several times on the same medium, whenever an update > > of > > the > > two disk trees to the medium is desired. Begin with a blank > > medium > > and > > update it until the run fails gracefully due to lack of remaining > > space > > on the old one. > > > > This makes sense if the full backup leaves substantial > > remaining > > capacity on media and if the expected changes are much smaller > > than > > the > > full backup. To apply zisofs compression to those data files > > which > > get > > newly copied from the local filesystem, insert these > > commands > > immediately before -commit : > > -hardlinks perform_update \ > > -find / -type f -pending_data -exec set_filter --zisofs -- \ > > > > > > > > What I first found were instructions to create an empty file of > > > > the > > > > propper size, 'mkudffs file', loop mount it, copy files to it, > > > > unmount > > > > and burn to the BD disc. > > > > To my experience, UDF offers no practical advantages over ISO 9660 > > when > > you plan to read the backup by GNU/Linux. Some other free operating > > systems have problems iin ISO 9660 filesystems with files of size 4 > > GiB or > > larger. MS-Windows will show the dull ISO 9660 names if you do not > > give > > xorriso command > > -joliet on > > before the xorriso command -commit. > > > > You could use the program genisoimage with its option -udf together > > with a burn program like growisofs, cdrecord, or xorrecord. This > > produces > > an older version of UDF suitable for DVD video but not for Blu-ray > > video. > > > > growisofs on Debian uses genisoimage by default. Its man page > > proposes: > > > > growisofs -Z /dev/dvd -R -J /some/files > > > > You would add genisoimage option -udf. > > > > The other burn programs can take their data strem from a pipe fed > > by > > genisoimage. Like: > > > > genisoimage -R -J -udf /some/files \ > > | xorrecord -v dev=/dev/sr0 -waiti -eject - > > > > Multi-session with genisoimage -udf is known to be problematic (or > > impossible). Your apporach with mkudffs might be capable of taking > > file > > changes on BD-RE media when they are mounted with rw-premissions. > > (If you can get it mounted, that is.) > > > > > > > > Further searching found that the recommended way to access UDF > > > > filesystems on optical media is to use "packet writing". > > > > This old statement applies to writing, not to reading. Further it > > is > > mostly about writing of CD media and some DVD media types. BD media > > can > > get written by several write types which all resemble CD packet > > writing. > > > > But in your case of mkudffs operating on a filesystem image file > > there > > is no special medium involved. This approach assumes that you > > prepare > > a mountable image file and flatly copy it to a medium by whatever > > write type is suitable. > > > > > > > > For the life of me I cannot figure out how to make this work. > > > > None > > > > of > > > > the suggestions I've found work with my setup. > > > > Did you eject your BD and reload it before mounting it for looking > > at > > its content ? > > The Linux kernel offers no way to tell it to re-assess a freshly > > written > > /dev/sr device. You have to force re-assessment by physically > > reloading > > the medium. > > > > If this in-out dance does not help, try to mount your UDF > > filesystem > > image > > file before copying it to a BD: > > > > sudo mkdir /mnr/udf > > sudo mount /my/udf_image_file /mnt/udf > > > > If this works, then you know that your way of writing to BD is > > flawed. > > In this case, describe it here in more detail. > > If mount already fails with the UDF image file, then your mkudffs > > run > > is > > flawed. In this case, describe exactly how you do it. > > > > > > > > It may be that my BD drive is too old but before going the > > > > route of > > > > changing it out, I'd like to know if there's something I've > > > > missed > > > > in > > > > the general process. > > > > Try a simple xorriso run. Assuming that your drive is at /dev/sr0: > > > > disk_dir="...path.to.some.directory..." > > iso_dir="...name.for.the.directory.on.the.BD.medium..." > > > > xorriso -outdev /dev/sr0 -blank as_needed \ > > -for_backup \ > > -map "$disk_dir" "$iso_dir" \ > > -commit -toc -check_md5 FAILURE -- -eject all > > > > This will copy the tree under "$disk_dir" onto the BD medium and > > then > > perform a check-read run to verify readbility and matching MD5 > > checksum > > of the overall ISO 9660 filesystem. > > No UDF involved, of course. > > > > If your BD burner has a tray motor, then the tray is supposed to > > come > > out of the drive when the checksum matchies. In case of mismatch it > > will > > stay in and you will have to eject it manually. > > If the xorriso run states in the end: > > > > Ok, session data match recorded md5. > > > > then the medium should be mountable. > > If the drive is bad, then the checksum will hardly match. > > > > > > > > The DB burner is an LG and is quite old, as in maybe 15 years. > > > > My oldest one is a LG GGW-H20L from 2008. It survived the demise of > > two > > USB boxes and now lives in its third home. > > It cannot burn modern BD-R media or format modern BD-RE. But it > > works > > with BD-RE formatted by a LG BH16NS40 from 2013. It fails to write > > BD-RE > > which were formatted by a newer ASUS BW-16D1HT. In this case the > > burn > > run > > reports errors. > > > > > > Have a nice day :) > > > > Thomas > >
Wow, thanks for your detailed reply. It has taken me a while to dig through it all. Now I need to go and actually try the ideas out and see what happens. One question, what I would like to see is a duplicated directory/file hierachy on the destination. I have lists of file names in groups just short of 25G, but I can't find an easy way to send the file names to any of the programs and have them maintain the hierarchy. They just dump all the files in the root of the destination. I did manage this for a few files with 'xorriso -update_r' option used once per file name and with the full destination path and file name listed: xorriso -update_r /home/me/topdir/file /topdir/file ... But doing this for thousands of files doesn't seem like it is a manageable or robust solution. Any suggestions? Thanks, Bob
