Re: RFC: devmapping cutouts?

[Thomas Schmitt]

Hi,

Ivan Shmakov wrote:
> It’s easy to transform the output above into a table
> suitable for passing to the # dmsetup create command

That's intentional with the output of inquiring commands. It shall be
parseable by not too complicated programs.


> b. extending this simple ‘bunch of files with filenames
> being offsets’ convention in such a way as to allow for
> incremental backups of filesystem (or other large dataset,
> where it might make sense) snapshots.

This should be addressable by multi-session:
- Load the old ISO by -dev.
- Make a new partitioning into zero-byte and non-zero-byte intervals.
- Compare it with the old partitioning to identify old non-zero-byte
  intervals which are entirely contained in a new interval and did
  not change their content from old to new. Only those can be kept.
- Evaluate whether splitting the new interval would save enough content
  bytes to justify the possible one or two remaining new sub-intervals.
- When it is decided that an old interval shall not survive, delete it
  by -rm.
- Insert by -cut_out the new intervals which remain or were created
  while keeping old intervals.
- Execute -commit or end the xorriso run.

If you follow the -split_size naming protocol then command -extract
could later re-assemble the image on disk. Depending on the -osirrox
setting even with sparse file effectivity ... i hope. (Test it.)

Consider to run xorriso in dialog mode as consumer of commands which it
reads from its stdin, which is your program's pipe.
Have a look at xorriso-tcltk to see what is possible with such a xorriso
minion. (Right mouse button pops up the help text of each GUI element.
The Help button to the upper right gives an overview.)

Since Tcl or i are too dumb to weave proper pipe connections, i wrote
xorriso command -launch_frontend. xorriso-tcltk connects to xorriso by
starting it and letting it launch another instance of xorriso-tcltk
which is then properly connected. The first instance waits and ends when
xorriso ends.


> a. locating the 0-filled
> ranges in the source, as well as balancing the amount of
> data /not/ stored vs. the number of files / ranges needed;

Here ends my experience. I cowardly leave it to the users to adjust their
sparse file desires when restoring files to disk. See -osirrox sparse=...


Have a nice day :)

Thomas