[OpenAFS] Questions about OpenAFS "reality"

[Russ Allbery]

Leroy Tennison <leroy_tennison@prodigy.net> writes:

> A recent post stated that they had about 7000 users in a single cell,
> I'm wondering what a realistic maximum is (assume 'average' end user
> file activity - nothing extraordinary).

I don't see any reason why there would ever be any maximum.  I suppose at
some point you have as many VLDB servers as you can add, or you maximize
the number of replicas for root.cell, but I expect OpenAFS could easily
handle hundreds of thousands of users.  And you can always just split the
cell into multiple cells.

> I saw in the archives a refernce to 45k and a statement that UMich had
> 100,000.

Stanford's statistics as of December 1st:

Number of users using more than....

    1MB space         22,764 (53.7%)
    10MB space        17,203 (40.6%)
    100MB space        6,729 (15.9%)

Number of users modifying files more recently than....

    One week ago       5,905 (13.9%)
    One month ago     12,120 (28.6%)
    Six months ago    23,631 (55.7%)
    One year ago      27,905 (65.8%)
    Ever              32,663 (77.0%)

Since everyone gets an AFS home directory, we have some set of people who
have them and never use them, for a total of about 45,000 registered
users.

> How does AFS compare in administrative burden compared to the common PC
> NOSes (NetWare and AD)?  Is it more intensive, less or about the same
> for a given type of user population?  A related question is how
> "sensitive" is it, do you have to be overly careful in order for things
> to work correctly?

My personal experience is that AFS is extremely robust and generally less
work for any other file system of comparable size provided that you're
dealing with a user population large enough to have AFS's location
independence and administrative tools become truly useful.  If you've
outgrown a few large NFS servers, AFS is probably going to be as
inexpensive or more so than any other network file system you'd end up
running.

The one caveat to that is that ACLs require a bit of user training and
some help desk activity that a more "native" file system for a particular
platform may not require.

> How stable and trouble free is the Windows client?  (I saw a statement
> that the Windows server was considered experimental and not being
> maintained).

The current Windows client is great.

> Is there a Linux GUI for day-to-day administration?

No.

Personally, I admit to not understanding what people see in GUIs for this
sort of thing; AFS has an even more valuable feature in that it's
scriptable, and for large sites you don't want anyone sitting in front of
any sort of UI and doing things manually.  But I do understand that not
everyone thinks at a level of scalability that I tend to.

> What is the status of server-side byte-range locking?  If this isn't a
> near-term reality what alternatives do people use (SQL server is
> obviously a possibility, are there other alternatives for "MS Access"
> style databases and other byte-range locking needs)?

We generally recommend against putting databases in AFS and have for some
time.  Byte-range locking for Windows is available and is sufficient to
have Word and similar applications do the right thing, but I'm not sure
I'd want to trust an active database to the AFS locking model.

> What are people doing for printing, particularly Windows printing?

As others have mentioned, AFS is only a file system and doesn't attempt to
solve these sorts of needs.  At Stanford, we also have an AD forest that
we use to provide other Windows services.

> What about workstation customization (consistent look and feel from
> workstation to workstation, workstation restrictions, etc.)?  What are
> the alternatives there?

AFS is just a file system.  What you do with the file system is up to you.
You can distribute or automate the distribution of such things via AFS, or
you can just use AFS as a file system, but AFS does not, itself, control
things like this.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>