On Fri, Jun 18, 2010 at 2:18 PM, Mattias Pantzare <[email protected]> wrote: > On Fri, Jun 18, 2010 at 20:03, Phillip Moore <[email protected]> > wrote: >> 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 product >> 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 .com >> zones? I admit that not as trivial to do by accident as ls -al */*, but >> the point is that what's broken here is that software product, NOT DNS, or >> AFS, or it's CellServDB file. > >> I would argue that any software product that makes an assumption like this >> will never be user friendly in an environment with distributed filesystems. >> If you were using an automounter of some kind with NFS, you might have a >> similar issue, although AFS certainly compounds the problem by giving you >> 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". Comments? > If AFS would suddenly get popular and everybody started to add their > sites to CellServeDB you would have a problem just by listing /afs. -- Derrick _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
