[OpenAFS-devel] openafs cell and contrib area?

[Default]

> Actually, yes.  AFS clients are useless without pointing them at an
> AFS Cell.  I believe that to be truly successful, we need to have a
> 'default' AFS Cell that can be the 'default' ThisCell in OpenAFS
> distributions.  Obviously, people at large sites that are currently
> using AFS would want to point their clients at their own cell.
> However, it would be nice if OpenAFS were _useful_ out-of-the-box
> without human intervention, in ALL cases.
> 
> If we travel down this road, we would need a distributed primary cell
> such that someone in Somalia wouldn't have to have packets travel all
> the way to Pittsburgh just to start AFS ;)

The default cell is root.afs, and a time source.  AFSDB support or other dynamic configuration would obviate the need.  

Even so, a distributed default cell needn't have distributed 
administration. 

And even then, the CM presently doesn't know how to choose a "best" VL server or root.afs server without trying them first -- the subnet mask proximity guesses just aren't going to help your Somali friend.   So a few packets are likely to travel to Pittsburgh -- splitting up the administration isn't going to help with this problem.

Even so, it's hardly the end of the world to make a half-dozen RX RPCs from Somalia to Pittsburgh every time you boot a client-only instance of OpenAFS.  Would it?  It doesn't take much hardware to handle 200-300 calls/sec.  

Booting a CM involves (IIRC) 2 VLDB RPCs (getvolumebyname(root.afs) and getvolumebyid(nnn), though the latter is redundant, it's just an implementation artifact) plus 2 FS RPCs (getattr and readdir).  So one dinky beatup old server could handle 50 clients rebooting every second.  Given average uptimes around, say, a week, that's 86400*7*50 client-only instances of OpenAFS.  We should be so lucky.  (yeah, there's time, and there's another stat and readlink needed to traverse each AFS cell mountpoint, but OTOH, 200 calls per second is a pretty slow server).