[OpenAFS] CellServDB

Derrick Brashear shadow@gmail.com
Fri, 18 Jun 2010 14:26:15 -0400

On Fri, Jun 18, 2010 at 2:18 PM, Mattias Pantzare <pantzer@ludd.ltu.se> wro=
> On Fri, Jun 18, 2010 at 20:03, Phillip Moore <w.phillip.moore@gmail.com> =
>> This is a *classic* case of blaming the wrong software product for a
>> problem.
>> It's not the CellServDB that's not user friendly, it's the software prod=
>> making stupid, incorrect assumptions about the filesystem.
> In this case it is both the software that is stupid and the
> filesystem. The software is not the only problem with the way things
> are now.
>> Would you accuse DNS of being broken it some brain-dead software product
>> wasn't "user friendly" just because it enumerated the entire root and .c=
>> zones? =A0 I admit that not as trivial to do by accident as ls -al */*, =
>> the point is that what's broken here is that software product, NOT DNS, =
>> AFS, or it's CellServDB file.
>> I would argue that any software product that makes an assumption like th=
>> will never be user friendly in an environment with distributed filesyste=
>> =A0If you were using an automounter of some kind with NFS, you might hav=
e a
>> similar issue, although AFS certainly compounds the problem by giving yo=
>> access to remote cells over the Internet.
> /net for NFS works just like AFS does when the CellServeDB is empty.
> Sites appear when someone tries to access them. Very user friendly
> when you are dealing with big number of sites.

dynroot with an empty CellServDB works like this, *as long as* the
cell has AFSDB (or in 1.5, SRV) records.

we could (and possibly should) make things behave as if CellServDB is
empty, with a full cellservdb, so an override of DNS is possible but
/afs is not "just populated".


> If AFS would suddenly get popular and everybody started to add their
> sites to CellServeDB you would have a problem just by listing /afs.