gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Tom Lord
Subject: [Gnu-arch-users] a global-scale txnal distributed filesystem
Date: Tue, 15 Jun 2004 19:53:14 -0700 (PDT)



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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]