hi
this is a follow up to my original posting on automount configuration.
the original summary is included below. one of my questions concerned
a limit on the number of automount entries. there is a bug in sun os
4.1.x that limits the total number of nfs mounts to 256:
Bug Id: 1258373
Category: kernel
Subcategory: nfs
State: integrated
Synopsis: /etc/mtab can overflow causing pwd, getwd() to fail 4.1.3_U1
A complete description, together with examples and a code fix
is given in bug number 1043098.
Sun's suggested work around is to use indirect maps or to reboot.
cathy
my original question concerned the use of indirect maps. everyone who
replied said go ahead and use them. here are the original questions
and my summarized response.
> i have a couple of questions concerning automount map configuration
> that i have been unable to answer from the o'reilly book.
>
> we have about 200 sun os workstations. each workstation exports 1 or
> more filesystems, and each needs to access all file systems exported
> by the other workstations. this is all done with a single, direct map,
> /etc/auto.direct, and the fstab file. essentially, each desktop
> workstation acts as a server > to all other workstations. the concept
> of a centralized nfs server is not an option here.
>
none of the following is an option at the moment either: using NIS to
distribute maps, creating the equivalent to the NIS /net map, or
upgrading to Solaris.
>
> 1. i was told that there is a 256 limit in the number of combined entries
> in the fstab and the auto.direct files.
> a. how/where can i confirm that?
> b. if the limit does exist, what are the consequences of exceeding the
> limit?
>
i have learned that Tatung has something from Sun confirming this limit.
i am waiting for the details from them as i do not have Sun tech support.
one symptom is the wrong file system is mounted although the map is correct
and no user-created links are involved in cd'ing to the file system.
no one added anything to this section. the only minus brought up was the
users' perception. if users are accustomed to seeing all the mount points,
they may not like the fact that the indirect maps do not show the mount
points unless a mount has been made.
>
> 2. i have recommended revising the automount configuration to use a
> combination of direct and indirect maps. management has asked me to
> describe the functional differences between the two map types, summarize
> the pros and cons of each, discuss the performance impact, and to
> identify any potential problems. this must be done briefly, and at a
> rather high level, because the engineering director (very high up) who
> will make the decision to approve this recommendation is not a sys admin.
> i have summarized the following information from the o'reilly book. can
> you suggest anything else to include?
>
>existing files affected:
> /etc/auto.master
> /etc/auto.direct
> /etc/fstab
> /etc/mtab
>
>a new file will be created, /etc/auto.<host>, for each workstation exporting
>more than 1 file system. this is an arbitrary criteria to decide what
indirect
>maps to create.
>
>indirect map:
>1. reduces the number of NFS mount requests
>2. reduces the size of /etc/mtab
>3. changes are immediately available.
>4. emulates a directory.
>5. directory can not contain a mixture of "normal" mount points and
> automount mount points
>6. autoumounter mounts the top (parent) level directory.
> subdirectories are mounted only on request.
>7. the automounter displays only currently-mounted file systems
>
>
>direct map
>1. file is an extension of /etc/fstab
>2. each entry is an individual directory entry and treated as a separate
> mount request
>3. automounter must be restarted to see changes
>4. directory can contain a mixture of normal mount points and automount
> mount points
>
>
>3. is anyone aware of problems using indirect maps? the only thing i can
>think of immediately is if there exist scripts that depend on the results
>of commands such as ls.
>
no one mentioned any problems
i'd like to thank the following people who responded:
Gustavo Chaves <gustavo@cpqd.com.br>
Evan Brown <evan@unixguru.com>
Jonathan Detert <jcdetert@cam.ra.rockwell.com>
Kelly Fergason <klfergason@amoco.com>
"V. Q. Hoang" <vqh@dwrock.dw.lucent.com>
STEFAN LADAGE <rootsl@mlugeos8.geologie.uni-halle.de>
Bob Reitinger <bobr@solarsys.com>
Gary Smith <gsmith@lvmail1.dseg.ti.com>
Tom Vayda <vayda_tom@jpmorgan.com>
Birger Wathne <birger@sdata.no>
cathy
-- Cathy L. Smith Dallas Semiconductor (972)371-6720 e-mail: csmith@dalsemi.com
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:41 CDT