Re: Using dar for archives to optical discs

On 20/06/2023 21:44, John Goerzen wrote:
> Hi Petr,
> 
> On Tue, Jun 20 2023, Petr Skoda wrote:
> 

[...]

> 
>> But what I want to suggest to solve is the housekeeping of the dynamically on-the fly created slices.
> 
> I would also like to see this.  It would help in my use case of
> variably-sized external drives.

I'm not sure what you mean by "dynamically on-the fly create slices"... 
Doesn't dar itself, from your filesystem, dynamically creates slices 
on-the fly of the size you asked for?

> 
>> I will have a bunch of tapes but there is no easy way to recognize which one is of given slice and even that it contains
>> a dar backup.

Yes, this information is stored in filenames on disks. Tape do not have 
a filesystem to hold that info, I agree. But if your hundred tapes or 
more are not identified by a label (sticker), wouldn't it be very 
painful to insert this tape or this tape just to know that it contains a 
dar backup and which slice number it is?

Wouldn't numbering/labeling your tapes be a better solution?

>> I know Denis has a good explanation why it is not possible currenly and namely for dar_split (as the system does not
>> know where it is - it is just a stream of data)
> 
> If dar itself could sense ENOSPC when writing,

I would rather prefer dar to stay agnostic to the underlying media as 
much as possible. It has proved its value when slices were used to span 
a backup over CDs, then DVDs 20 years ago. At no time dar has had to 
bother about burning CD-R or CD-RW or DVD-R or DVD-RW... but -E and -F 
option was left for the user to run anything that would do that. Today 
both options can still be used to send/fetch slices to/from the cloud 
for example.

> and note the conclusion
> of that slice for the catalog, that would be very nice. > This would imply the catalog having a slice array/table, from each 
slice to its
> starting offset.

The catalog grows in memory and does not stores the slice number or 
number(s) file is located in, which may be changed afterward by dar_xform.

But it could be possible after each slice (possible but not simple seen 
the current modular implementation), to dump the current status of the 
catalogue in a separated file (same file format as an isolated 
catalogue). Though it would have all content treated so far, not only 
the last slice.

> 
[...]