[OpenAFS] OpenAFS speed - some benchmarks

[Derrick J Brashear]

On Wed, 25 Jun 2003, Russ Allbery wrote:

> Derek Atkins <warlord@MIT.EDU> writes:
>
> > So, if it were possible to give each fileserver its own Server Key, one
> > that authenticated it to the cell but did not provide any real power
> > over other servers (or the cell in general), would that make you happy?
>
> Yes, very.  And I know there was previous discussion of that, and I was
> sort of indirectly hinting at my support for that discussion.  :)

A code drop would also make a good hint :-P

> > Granted, that opens up a whole can of worms in terms of authenticating
> > various operations like volume creation, backup, cloning and
> > replication, etc...  It also doesn't help add new users to the cell.
>
> Yes.  But that's okay.  We can provide tools to departments to take care
> of all that stuff (well, backup may be interesting, but I'm sure we can
> work something out).  That's not a problem, as long as they can maintain
> the physical hardware of the file server on their own personal disk.

Well, unless some sort of proxy is worked out, it actually makes moving
data between servers simply not possible. It also makes things harder on
the client: fetching keys for a new server in-band when you first talk to
it is sort of suckful, because now you need the client's TGT and not a
service key.

I'm not saying "not doable"; I'm just saying "much pain".

> It's not the setup of the AFS cell so much (although that's certainly an
> issue) as it is the issues of cross-realm authentication.  I know that
> some other schools do this routinely, but I think it would be a pretty
> high learning curve for a lot of our users.

Worst case: add
system("aklog realm");
system("aklog realm2");
system("aklog realm3");

etc in your login program. There are cleaner ways but this conveys the
point.