Re: [Mondo-devel] Re: crypto; incremental backups

[Hugo R. <hu...@bt...>]

On Saturday 23 February 2002 5:16 am, Bryan J. Smith wrote:
> No, I'm talking about mastering "on-the-fly".  From my understanding,
> this is procedure Mondo uses:
>
>   1.  archive (to temp area)
>   2.  master (to .iso)
>   3.  burn (from .iso)
>
> What the -C option does is combine 2 & 3 so you burn data as it is
> mastered (and doesn't make the intermedia .iso file).  But you still do
> #1 separately.

Sorry, I didn't explain properly. :) -C will stream straight to CD. No 
archiving to temp area. It all goes straight to CD (except for 10-15MB of 
scratch space, which can go in RAM).

> As far as "streaming compression" -- that's an issue with afio itself.
> It calls the compression program as a system/fork call on the complete
> file (which may require more than one pass, see the afio docs for more
> info).  A more efficient/faster mechanism would be to call
> libz/libbz2/liblzo directly in its C code.
[.....]
> The newer POSIX pax archiver (replacement for cpio/tar) handles ACL/EAs
> in a way that makes the format not backward compatible with older
> cpio/tar versions.  The Solaris "double file" approach does, and I like
> it.

Pax? Hmm. I'll have to look into that. Well, Mondo and Mindi exist.. You 
could call the new project Mende, Mundu or Manda. You have my blessing. ;)

It almost sounds as if your new program would be a drop-in replacement for 
afio. That would be _very_ cool, IMO. Afio is one of the best archive engines 
around (again, IMO). I chose it over tar, cpio and star because it was the 
only engine which backed up and restored files properly under VFAT, ext2, 
ReiserFS, etc. without monkeying with sparse files or truncating tiny .ini 
files. We could take afio, rip its guts out (lovely image) and replace them 
with some of cdrecord's code, or perhaps some library calls to lzo / bzip2 
(or even crypto *eg*). Fun.

Afio becomes Bsio!

-Hugo