On Tue, Dec 10, 2002 at 09:05:58AM +0100, Ivan Popov wrote:
> Well, it depends on what we are looking for.
> 
> There are several diferent possible targets:
> 
>  - to be able to "export" existing data without a copy operation.
> Then we could postulate that the files must *not* be written through local
> fs _anymore_, but via a Coda client instead.

Yes, but people who still think 'NFS' will be even more tempted to
ignore that requirement, and probably either not read, or get confused
by instructions that say 'do not modify any files in the exported fs'.

> Well, it might be even useful to be able to export "local fs data"
> readonly, freezing them and pretending they are a readonly volume with a
> "per-volume" acl?
> 
>  - to be able to go past Coda acls
> Then it *may* be OK to sacrifice consistency.
> 
>  - to be able to go past network layer for massive operations (?)
> Then a client built into the server may offer the functionality (and the
> "ignore acls" one too)
> 
> Not that I suggest such projects, just thinking aloud.

If we had a way to promote a restored backup volume to a RW replicated
volume, and a way to convert Coda volume dumps to tar files and back, or
even have a 'tar' compatible format for the dumps. Then it would be
possible to tar up a directory tree, restore this dump as a RO backup
volume and twiddle it to a full RW replica. Add some additional replicas
and resolve...

Needed, tar<->voldump conversion tool, and a volutil command to change a
RO backup volume into a RW replica.

Result, an administrator can manipulate backup dumps with tar, perform a
quick restore of a lost volume, and move a pre-existing tree into the
Coda namespace without going over the network through a Coda client.

Jan