Dear Transarc Support,
For the last year, we have been trying to determine the best strategy
for managing mount points and keeping our list of available mount points
in our automount NIS maps to the magical 255 limit. I'm sure you are all
very aware of the automount limitation (which applies to amd as well) of
255 mount points on a client workstation.
We are looking for a ideas to solve this problem and were wondering if
this sort of limitation can be overcome by deploying AFS. We have a very
small implementation of AFS on a couple of IBM RS/6000 workstations and
would be looking to deploy AFS on all our 165 Sun workstations.
Our current solution is to use amd and to get status on the mount points
with amd's amq command.
Where we deploy Sun's automount, we have set up direct mapping schemas.
With 565 available mount points in our WAN/LAN, the automount NIS maps
are taking up a lot of time to manage.
Sadly, lot's of the old implementation of automount exists where the
/etc/rc.local script runs;
automount /net -hosts -rw,intr
The majority (94%) of our workstations are Suns running Soloris 1.1.X
Approximately 20% of our workstations experience automount problems
within 10 working days. Sometimes multiple reboots do not accomplish
the task of sorting out the automount problems we experience when
clusters of workstations are having the problem simultaneously.
(I call this procedure of constantly rebooting workstations and servers,
"The Local Area Network Dance of Agonizing Death Festivities". You
have to be there, I guess...)
In instances where a network file serving machine can not serve the
client requesting the mount point, we have discovered that amd does not
completely recover, but it most certainly does not have as negative an
impact on the workstation as when running automount.
The real problem seems to be imbedded deeply in NFS itself.
Stealing observations from a colleague here, he noticed something very
interesting in /etc/mtab;
"Solaris 1.1.X allocates device id's for mount points with the top byte
specific to the filesystem type (0x82 for nfs) and the bottom byte used
to identify the particular mount.
"This means that there can only be 256 mount points of any one type at any
one time. Once you have 255 mounted, all subsequent mount points get the
same device id (0x82ff) and it's that ambiguity that's confusing getwd()
[which in turn confuses both pwd and df]."
We have considered purchasing several copies of Online:DiskSuite to
help reduce the actual number of mount points. By installing this
application on each workstation where they export several disk partitions,
we would create a logical partition out of the several disk partitions and
export only the logical partition. On a per node basis, pricing has been
prohibitive for us at this time.
After several support calls to Sun, it is my opinion that there is
absolutely no reason why SunSoft would want to change/increase the
capacity of the number of mount points that automount can handle.
With AFS, I was under the impression that the mount points would be
configured more logically under our cell site, not unlike Sun's
Online:DiskSuite application.
Is there some light that Transarc can shed on this subject where AFS
would/might help us resolve this mount problem?
Mike Barnett [EMAIL PROTECTED]
Zycad Corporation
47100 Bayside Parkway 510/623-4453 FAX 510/623-4550
Fremont, Ca. 94538 Systems Administration Department
