Re: [Gnu-arch-users] a global-scale txnal distributed filesystem

[Andrew Suffield]

On Tue, Jun 15, 2004 at 07:53:14PM -0700, Tom Lord wrote:
> Here's an idea:
> 
> a) grab a users-space NFS server and modify it
>    so that it can do namespace translation within
>    a local namespace.   In particular, it should
>    be able to server, for read-only purposes,
>    a revision library entry, relative to the root
>    of the revision.
> 
> b) configure an automounter so that 
> 
>       /arch/$REVSION/
> 
>    is served by the NFS server, with the necessary
>    library revisions being created upon demand.
>    You'll need a daemon to watch interesting archives
>    and create empty /arch/$REVISION dirs after each
>    commit for the automounter to use.
> 
> 
> Now you have most of a transactional, global-scale filesystem.   
> Anyone can perform an isolated read-transaction by looking
> for their data in the latest /arch/$REVISION.

So far this is feasible.

> Of course, write transactions are more awkward -- one needs a working
> directory for those.  Hence:
> 
> c) configure the automounter so that any directory that exists
>    named:
> 
>       /arch/+write-txns/$VERSION.$UID
> 
>    is a created-on-demand working directory for the indicated 
>    revision with access permissions as embedded in $UID.
> 
>    A `commit' in such a directory can do a few different
>    things, depending on the intention.   It can replace
>    the mountpoint with a mount to the (then constant)
>    revlib revision.   It can keep the mountpoint as is
>    and allow it to be used for further write txns.
> 
> Now you have (the bare minimums of, with many elaborations in easy
> reach) the essense of a bandwidth-and-latency-efficient globally
> distributed filesystem supporting arbitrarilly large filesystem
> transactions with ACID properties, a wealth of replication options and
> transaction semantics options, a richness of access control options
> (think of tossing some pqms into the mix) .....  basically, "solved".
> 
> There's a gazillion little details and elaborations on the general
> idea sketched above but I haven't been able to think of any that
> aren't trivial.

Authentication and authorisation. With NFS, the answer is basically
"don't"; it not only fails to even attempt to solve the problem, but
makes it several times harder. You could only really use this in
trusted environments.

NFSv4 would be viable for this, but NFSv4 itself is not yet viable,
and has little in common with earlier NFS versions - it's a
not-completely-stupid network filesystem, which means it's nowhere
near as simple.

> The above would have some latency properties that are worse than AFS
> in a few situations but, by in large, would romp all over AFS' world
> in performance-otherwise and in features (like transactions).

AFS isn't hard to beat; NFSv4 should do it easily. It's just that
nobody has yet. And the single performance strength of AFS
(callback-driven caching) is irrelevant in the write-once world of
arch.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

signature.asc
Description: Digital signature