On Dec 4, 2008, at 8:35 PM, Dave Eckhardt wrote:
At some distant point in the past (last century, actually)
I was drawn to AFS because of the features, but left in
horror because of the complexity.
The goal was adding an enterprise-scale distributed file
system to an existing operating system (Unix), where
"enterprise-scale" meant 5,000 users (the first prototype
supported 400 users on 120 workstations in 1984; this
evening CMU's AFS cell hosts 30,821 user volumes, roughly
half a gigabyte each; there are cells with more users and
cells with more bits.
Fair enough. But what's the adoption overall? You see,
as with any enterprise application there's a very delicate
balance to be had -- err on the side of oversimplification
and you can't deliver, err on the side of complexity and
you loose to the solutions which are "good enough".
I guess it doesn't really matter if your environment is
being managed by a good IT -- you just reap the benefits.
But as a tinkerer, I wouldn't call AFS malleable.
A 747 isn't as malleable as an ultralight. If you can
figure out how to carry several hundred people across an
ocean in something as easy to build and maintain as an
ultralight, people will most definitely take notice. And
such a thing could be the case for distributed file systems.
See, that's the problem with complex systems -- they try
too hard to solve a problem with a set of requirements that
change faster than the implementations can adapt.
I see a lot of that in C++ (how many times was the latest
standard delayed?, how long did it take compiler vendors
to get template template parameters right? etc.) and other
things which were meant to be "enterprise grade".
To some extent, the popularity of NFS (is there any NAS box
that talks AFS?) and Linux is one big testament to the
power of "good enough" or "worse is better".
Designing "enterprise grade" things is very hard work.
Implementing them is even harder. The good news
is that it pays well. The bad news is that you have to
be really brave to withstand the fear of being obsolete
by changing requirements.
P.S. Here's some rationale behind the horrific complexity:
http://www.cs.cmu.edu/~satya/docdir/p35-satyanarayanan.pdf
Interesting paper! Thanks for providing a pointer to it.
Thanks,
Roman.
