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

[Bug Goo]

Created as bug 154

On Wed Jun 16 02:49:34 2004, Tom Lord wrote:
> 
> (Resend for the bug-goo record.   Sorry about the duplicate.
>  Yes, I could probably figure out how to accomplish the same
>  goal without the duplicate post but I didn't.)
> 
> 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.
> 
> 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.
> 
> 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).
> 
> Perhaps within our lifetime, the current professional discipline of
> "RDBMS table design" will be replaced with "txnal filesystem
> mount-point design": a superset of its antecedent, functionality-wise.
> 
> -t
> 
> 
> 
> _______________________________________________
> Gnu-arch-users mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnu-arch-users
> 
> GNU arch home page:
> http://savannah.gnu.org/projects/gnu-arch/
>