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

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

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


From: Tom Lord
Subject: Re: [Gnu-arch-users] a global-scale txnal distributed filesystem
Date: Wed, 16 Jun 2004 09:52:17 -0700 (PDT)

    > From: Andrew Suffield <address@hidden>

    > > 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 only reason to pick NFS is for convenience of implementation.  I
don't know of any other portable way to write a user-space filesystem.

Any other way to do a created-on-demand filesystem with the ability
to remap paths name would work as well.



    > > 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.

A global-scale FS has to:

1. Efficiently serve up parts of the file system.

2. Handle writes coherently.

3. Have weird semantics and performance characteristics compared to a
   regular FS, because there's no escaping that.

4. Provide "volume management" -- units of administration for
   parts of the filesystem and procedures for handling them.

My claim is that arch provides a well-suited transport and transaction
discipline for a global FS and that arch's client-side behavior is
adaptable as a kind of "weird semantics" that makes a lot of sense for
a global fs.  The arch namespace is well-suited for volume management.

Arch is basically isomorphic to a global fs just because of what it
can do.   I'm just pointing out that wiring it up to actually behave
as a global fs is a modest-sized project.

(It's not original of me to notice the need for revision control in a
wide-area filesystem (especially one supporting detached operation).
I think I first read about the abstract idea in some Coda paper or
other. )

-t






reply via email to

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