Re: reiser4 plugins

[David Masover <ninja@slaphack.com>]

Pierre Etchemaïté wrote:
> Le Fri, 01 Jul 2005 04:08:20 -0500, David Masover <ninja@slaphack.com> a écrit :
> 
> Hi all,
> 
> 
>>Metafs also avoids having to patch tar.  It's assumed that legacy backup 
>>systems can always avoid metafs and still catch almost everything 
>>important, and certainly everything they already do catch.  With a 
>>hybrid or an entirely new backup system, we could catch everything, 
>>including any new ACL-like animals that people invent.
> 
> 
> As an administrator, a way to perfectly save and restore the content of
> file systems is a requirement. Crashes do happen, so do migration to new
> disk subsystems, system cloning, etc, etc.

I would suggest a plugin which produces a dump of the active FS.  It's 
how XFS seems to do it, after all, only you don't need the commandline tool.

> If restoration can be done with the standard tools you find on any live
> rescue CD, it's even better.

Any good XFS-enabled CD will have xfsdump.  Similarly, any good 
Reiser4-enabled CD will have whatever we feel like putting there.

Can ACLs currently be backed up with any other tool than some sort of dump?

> All what's probably needed is some readable-writable non-confusing
> (fully POSIX compliant) "view" that's guaranteed to contain all existing
> "raw" data and metadata).

The danger here is that things beyond POSIX must either be encoded into 
the file somehow.  If we add a thumbnail property to a certain type of 
file, and the file format itself doesn't allow for any extra data, we 
can either choose to have a separate view entirely for backup so that 
the "backup" view (which forces the metadata into the file anyway) is 
separate, or we can choose to accept that existing backup tools will 
catch existing attributes that they were programmed to expect, and all 
new stuff can be handled by some sort of dump.

I say "some sort of dump" because a separate backup view, because it 
makes some files unusable except for transport, is effectively a dump, 
only shown as a tree, instead of a single file.  But as long as we're 
doing that, we may as well provide an actual dump plugin so that one can 
do "gzip /metas/some/where/.../dump > /mnt/some/backup/medium".  It'd be 
more efficient than tar for that sort of thing.

Both are useful, though -- the tree is better for rsync backups, if 
you're either using /meta on the other end or are planning to only 
restore to a /meta enabled system.  I think we should do both ways.