Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #240269

Re: write only storage.

Show all headers | View raw

Thank you very much! It might be a little while before I get time to
experiment properly with this but I've saved this email for a free
weekend.

Tim.


On Wed, 22 Sep 2021, Thomas Schmitt wrote:

> Hi,
>
> Tim Woodall wrote:
>> If I wrote one session per day that would be c 30 sessions per disc.
>
> This should be doable on any BD-R capable drive.
>
>
>> I'd also need to find a drive
>> where I can verify what has been written without it ejecting the disk
>> first (or at least be able to reload the disk automatically).
>
> That's not a matter of the drive but of the Linux kernel which shows
> few love towards DVD and BD media. (I have a patch for a new ioctl()
> which would simulate newly loading of a disc without the need for
> moving the drive tray. But the kernel shows few love for userland
> programmers, too.)
>
> But xorriso uses libburn which performs SCSI transactions directly with
> the drive (via ioctl SG_IO). So it assesses the medium status on its own
> and is able to read freshly written data without drive tray dance.
>
>
>> I will need to do some experimenting as I don't have any
>> experience of writing multi-session disks.
>
> You may practice with a plain data file instead of optical media, by
> replacing in the following example the command
>
>  -dev /dev/sr0
>
> by e.g.
>
>  -dev "$HOME"/xorriso_test.iso
>
>
> Detailed explanation of the example from man xorriso
> "Incremental backup of a few directory trees" :
>
>  $ xorriso \
>
> The first command tells xorriso to abort only if there is no hope for any
> success. (Default is to abort if a substantial part of the job cannot be
> performed.)
>
>   -abort_on FATAL \
>
> The following enables recording of MD5 for data files and the whole session,
> recording of ACL (getfacl(1)) and of extended file attributes (getfattr(1)).
>
>   -for_backup \
>
> By the next command xorriso gets asserted that device numbers of disk
> filesystems and the inode numbers of files in the filesystems remain stable
> between xorriso runs, unless files get replaced. This assertion speeds up
> the comparison of disk filesystem and ISO 9660 filesystem. (Slower would
> be comparing the disk files with MD5s of ISO 9660 files, or comparing the
> files directly by reading both contents.)
>
>   -disk_dev_ino on \
>
> The next command makes sure that only blank media or written media with
> a matching ISO 9660 volume id (lsblk FSLABEL) are accepted. This shall
> keep you from inserting the wrong medium and thus causing an unduely
> big new session. If the volume id of a written medium does not match,
> then it emits a FATAL event which will abort the xorriso run:
>
>   -assert_volid 'PROJECTS_MAIL_*' FATAL \
>
> Next choose the drive. If it already contains an ISO 9660 session it gets
> loaded as base of the file tree comparison and as base of the upcomming
> new session:
>
>   -dev /dev/sr0 \
>
> Choose a volume id which matches above -assert_volid:
>
>   -volid PROJECTS_MAIL_"$(date '+%Y_%m_%d_%H%M%S')" \
>
> Exclude files which end by .o or .swp:
>
>   -not_leaf '*.o' -not_leaf '*.swp' \
>
> Check for differences between file tree /home/thomas/projects on hard disk
> and ISO 9660 file tree /projects on the backup medium. Any file which
> changed, appeared or disappeared since the last backup session will be
> properly represented in the overall directory tree of the upcomming new
> session.
> Unchanged files will appear in the new overall tree too. Their data will
> not get newly written but rather be represented by data which was already
> recorded by a previous session:
>
>   -update_r /home/thomas/projects /projects \
>
> Same for another pair of disk and ISO 9660 file trees. You may add as many
> such commands as you need to describe your backup. Each of them gets a
> pair of paths as parameter:
>
>   -update_r /home/thomas/personal_mail /personal_mail \
>
> The next command causes the new session to be written to medium:
>
>   -commit \
>
> After writing is complete, print the new medium state including the list of
> sessions:
>
>   -toc \
>
> Now comes the checkreading by help of the recorded MD5s for superblock,
> directory tree, and file data area of the newly written session:
>
>  -check_md5 FAILURE -- \
>
> And finally, if the program did not find reason to abort and if the
> drive has a tray motor, eject the tray:
>
>  -eject all
>
>
> Recorded ACL and xattr are not repesented by the Linux kernel when the
> ISO gets mounted. But xorriso can extract files including those features
> by help of its own commands. The man page has an example
>  "Restore directory trees from a particular ISO session to disk"
>
>  $ xorriso -for_backup \
>    -load volid 'PROJECTS_MAIL_2008_06_19*' \
>    -indev /dev/sr0 \
>    -osirrox on:auto_chmod_on \
>    -chmod u+rwx / -- \
>    -extract /projects /home/thomas/restored/projects \
>    -extract /personal_mail /home/thomas/restored/personal_mail \
>    -rollback_end
>
>
> Have a nice day :)
>
> Thomas
>
>

Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

write only storage. Tim Woodall <debianuser@woodall.me.uk> - 2021-09-21 18:10 +0200
  Re: write only storage. Toni Mas Soler <antomassol@protonmail.com> - 2021-09-21 18:30 +0200
    Re: write only storage. "Andrew M.A. Cater" <amacater@einval.com> - 2021-09-21 19:10 +0200
      Re: write only storage. Tim Woodall <debianuser@woodall.me.uk> - 2021-09-21 19:40 +0200
        Re: write only storage. "Thomas Schmitt" <scdbackup@gmx.net> - 2021-09-21 20:50 +0200
        Re: write only storage. Michael Stone <mstone@debian.org> - 2021-09-21 22:10 +0200
        Re: write only storage. Stefan Monnier <monnier@iro.umontreal.ca> - 2021-10-01 17:10 +0200
      Unclosed DVD-R or BD-R sessions ? was: Re: write only storage. "Thomas Schmitt" <scdbackup@gmx.net> - 2021-09-21 20:50 +0200
    Re: write only storage. Michael Stone <mstone@debian.org> - 2021-09-21 19:10 +0200
  Write *once* storage (was Re: write only storage) Steve McIntyre <steve@einval.com> - 2021-09-21 19:30 +0200
    Re: Write *once* storage (was Re: write only storage) "James H. H. Lampert" <jamesl@touchtonecorp.com> - 2021-09-21 19:40 +0200
    Re: Write *once* storage (was Re: write only storage) Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2021-09-22 01:30 +0200
  Re: write only storage. Marco Möller <talby@debianlists.mobilxpress.net> - 2021-09-21 19:30 +0200
    Re: write only storage. Tim Woodall <debianuser@woodall.me.uk> - 2021-09-21 19:50 +0200
    Re: write only storage. Linux-Fan <Ma_Sys.ma@web.de> - 2021-09-21 21:50 +0200
    Re: write only storage. Marco Möller <talby@debianlists.mobilxpress.net> - 2021-09-22 18:20 +0200
  Re: write only storage. David Christensen <dpchrist@holgerdanske.com> - 2021-09-22 06:20 +0200
    Re: write only storage. Tim Woodall <debianuser@woodall.me.uk> - 2021-09-22 10:10 +0200
      Re: write only storage. "Thomas Schmitt" <scdbackup@gmx.net> - 2021-09-22 12:30 +0200
        Re: write only storage. Tim Woodall <debianuser@woodall.me.uk> - 2021-09-22 16:40 +0200
      Re: write only storage. David Christensen <dpchrist@holgerdanske.com> - 2021-09-23 01:00 +0200

csiph-web