Derek Atkins wrote:
>David Thompson <[EMAIL PROTECTED]> writes:
>
>> RO/RW mappings should be explicit, not based on names of mount points.  
>> Standards between sites vary too much.
>
>Oh?  How many sites _don't_ use the convention of:
>       /afs/<cell>     <- RO mountpoint
>       /afs/.<cell>    <- RW mountpoint
>
>Are there other programatical conventions?  If you don't use the
>above convention at your site, what do you do?
>
>Keep in mind that with AFSDB support we need a programatical way to
>reach both the RO and RW copy of root.cell.  Note that this is a
>client matter, not a system matter.  I have no objection to
>programming a set of different client-side conventions and allowing
>the client administrator to choose which convention to use.

finding a cell's db servers has nothing to do with dynamically creating mount 
points for cells.  They are totally separate mechanisms.

While I use the <.cs.wisc.edu> convention locally, I am strongly against 
having the dynamic root.afs mechanism creating RW mount points for every cell 
it knows about.  Not all OSs supress .* files in listings, and the stat() 
calls take a long time, yada, yada, yada...

If you need a RW mount point into some cell, create it permanently somewhere 
below /afs/<your-cell>.  I'm not against a mechanism for specifying a RW mount 
point explicitly in a config file.  I just don't want them automagically for 
every cell in /afs.  There are lots of ways to solve this (like creating a 
single RW mount point in the dynamic /afs '/afs/.afs').  Automagically 
creating .cell mount points for everything isn't the one I want.

--
Dave Thompson  <[EMAIL PROTECTED]>

Associate Researcher                    Department of Computer Science
University of Wisconsin-Madison         http://www.cs.wisc.edu/~thomas
1210 West Dayton Street                 Phone:    (608)-262-1017
Madison, WI 53706-1685                  Fax:      (608)-262-6626
--




_______________________________________________
OpenAFS-devel mailing list
[EMAIL PROTECTED]
https://lists.openafs.org/mailman/listinfo/openafs-devel

Reply via email to