[OpenAFS] Re: "hard mounts"

[Phil.Moore@msdw.com]

>>>>> "Phil" == Phil Moore <Phil.Moore@msdw.com> writes:
>>>>> "Russ" == Russ Allbery <rra@stanford.edu> writes:

Phil> This is one area where NFS has leap frogged AFS in a big way.  MP fast
Phil> client and server NFS implementations are commonly available, and the
Phil> RW performance blows AFS away.

Phil> AFS' fortes are RO redundancy, WAN performance, and administration,
Phil> but NOT RW performance.

Russ> Wholeheartedly seconded.  It's really depressing to see how
Russ> little work we can get out of MP systems for stuff we'd really
Russ> like to throw MP systems at, such as bunches of remote users
Russ> logging on to read Pine.  The system practically may as well not
Russ> have more than one processor when lots of AFS writes are going
Russ> on.

Its actually even worse than not just keeping up with NFS, too.

With an MP-safe, but not MP-fast, AFS client one would hope that
performance remains flat as the load on the machine rises.  Namely,
one would hope that AFS locking semantics would result in the same
through put for 1 process reading/writing to AFS as you would for 20
of them.  Each of your 20 processes would get 1/20th of the available
throughput.

This is pretty much what we've seen on Solaris clients, using the
Transarc AFS code (I have to confess that we haven't touched OpenAFS
yet here, but I am trying to fix that ;-).  ON IRIX, however, the
performance degrades significantly, due to lock contention it appears
(and it would seem intuitively obvious that's the underlying problem).

For years, I kept telling Transarc what I still beleive today: that
single biggest strategic shortcoming of AFS is the lack of an MP-fast
client.

Some very interesting work was done on a DFS client re-write that used
raw partitions, similar to swap, to manage the cache, thus taking the
UFS code out of the path entirely, by no longer using a /afscache
filesystem.  The "original plan" was to prove the concept in DFS, and
then port that code to AFS.

Obviously that never happened, but the opportunity still remains.

Eventually, we (the OpenAFS community) need to do what Transarc/IBM
failed to do: architect an MP fast OpenAFS client.