Being out-smarted by AufoFS

Hi All:

I've just started to work with the autofs/automount facility in a
RedHat Linux environment (specifically RHEL 3). It's a really neat
concept but I've encountered a situation where I believe it is
behaving in a fashion that is smarter than I would otherwise like. As
such, is there a way to force autofs/automount to mount a file-system
using NFS instead of a local mount even if the file-system in question
can be accessed locally in addition to via NFS on a given server?

Without doubt, more details are needed. I have a server that has a
locally mounted file-system that is also advertised as an NFS share.
While processes on this server could access the file-system in question
via the local mount point, suffice it to say I have reason to prefer
that processes on this server access the file-system via a NFS mount
point. And while I can accomplish this using standard NFS mount
mechanisms (i.e. the mount command, /etc/fstab, etc.), there are
advantages with me attempting to do this the via the autofs/automount
facility. To that end, the initial configuration and testing of the
autofs/automount facility was reasonably straight-forward and
successful. Unfortunately though (well ... from my perspective at
least), it appears the autofs/automount facility is smart enough to
recognize that it can access the file-system via local means in
addition to via NFS and given the choice, I'm guessing that
autofs/automount will choose the local access mechanisms rather than
the networked NFS (i.e. more processing intensive) route. Can this
choice be circumvented?

To illustrate the situation, "/usr4" is a file-system that the
server, named "lk_rmsvip", has mounted locally and also advertises
as an NFS share. If another server is configured to automount this NFS
share as "/shares/usr4" and indeed the automount occurs, the output
from a mount command run on that other server is as follows:

[root@rac2pub images]# mount
/dev/cciss/c0d0p2 on / type ext3 (rw)
none on /proc type proc (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
usbdevfs on /proc/bus/usb type usbdevfs (rw)
/dev/cciss/c0d0p1 on /boot type ext3 (rw)
none on /dev/shm type tmpfs (rw)
/dev/cciss/c0d0p6 on /usr1 type ext3 (rw)
/dev/cciss/c0d0p5 on /usr2 type ext3 (rw)
/dev/cciss/c0d4p1 on /usr4 type ext3 (rw)
automount(pid12229) on /shares type autofs
(rw,fd=4,pgrp=12229,minproto=2,maxproto=4)
lk_rmsvip:/usr4 on /shares/usr4 type nfs (rw,soft,addr=10.0.0.1)

The above output is what I was expecting and shows me that the NFS
share "lk_rmsvip:/usr4" has been mounted via NFS beneath
"/shares/usr4" (i.e. see the last line of output).

If, however, the server "lk_rmsvip" which is the advertiser of the
"/usr4" NFS share is also configured to automount this same NFS
share, a mount command run on this server shows different results after
the automount occurs:

/dev/cciss/c0d0p2 on / type ext3 (rw)
none on /proc type proc (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
usbdevfs on /proc/bus/usb type usbdevfs (rw)
/dev/cciss/c0d0p1 on /boot type ext3 (rw)
none on /dev/shm type tmpfs (rw)
/dev/cciss/c0d0p6 on /usr1 type ext3 (rw)
/dev/cciss/c0d0p5 on /usr2 type ext3 (rw)
/dev/cciss/c0d4p1 on /usr4 type ext3 (rw)
automount(pid12229) on /shares type autofs
(rw,fd=4,pgrp=12229,minproto=2,maxproto=4)
/usr4 on /shares/usr4 type none (rw,bind)

In this case, it would appear that which has been made available
beneath "/shares/usr4" has not been mounted using NFS but via some
other, presumably local, means. While for performance/load reasons, I
can understand why autofs/automount would seek to do this, I have
reasons for preferring to force an NFS mount in this case. Is there a
way to do this?

If it helps, the content of "/etc/auto.master" file on both servers
used in the test is:

#
# $Id: auto.master,v 1.3 2003/09/29 08:22:35 raven Exp $
#
# Sample auto.master file
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# For details of the format look at autofs(5).
#/misc /etc/auto.misc --timeout=60
#/misc /etc/auto.misc
#/net /etc/auto.net
/shares /etc/auto.shares

while the content of the "/etc/auto.shares" map file on the same
servers is:

usr4 -fstype=nfs,rw,soft lk_rmsvip:/usr4

Thanks in advance for any insight that you might be able to offer.

Steve Underwood

(E-Mail Removed) wrote:
> [...] is there a way to force autofs/automount to mount a file-system
> using NFS instead of a local mount even if the file-system in question
> can be accessed locally in addition to via NFS on a given server?

> If it helps, the content of "/etc/auto.master" file on both servers
> used in the test is:
> #/misc /etc/auto.misc --timeout=60
> #/misc /etc/auto.misc
> #/net /etc/auto.net
> /shares /etc/auto.shares

> while the content of the "/etc/auto.shares" map file on the same
> servers is:
> usr4 -fstype=nfs,rw,soft lk_rmsvip:/usr4

It seems to me that you might be better off using the built-in features
of /etc/auto.net?

Personally I have auto.master containing this line:
/var/autofs /etc/auto.net --timeout=300

and then I symlink the expected directories back to /net, so that
they (the links) are always visible.

In your case, I think you could include /etc/auto.net in /etc/auto.master
and then set up your configuration on each system as follows:

mkdir /shares && cd /shares # Or wherever
ln -s /var/autofs/lk_rmsvip/usr4 .

Oh, you'll probably want to edit the options declaration in the
(executable) file /etc/auto.net. The default on my debian system is:

opts="-fstype=nfs,hard,intr,nodev,nosuid,nonstrict,async"

which may be a little sharper than you appear to want.

Chris

Thanks Chris:

Your input is much appreciated. I shied away from using the
"/etc/auto.net" mapping program because its workings were not
immediately apparent to me ... like I said ... I'm a bit of a newbie
to this autofs/automount stuff. Never-the-less, based on your
comments, I configured my autofs/automount facility as you suggested
and now have an appreciation for features of "/etc/auto.net". Many
thanks for the clarification.

Unfortunately, however, even with the autofs/automount facility
configured to use the "/etc/auto.net" mapping program, I'm
encountering the same issue; namely that it appears NFS is not being
used to automount the file-system in question if that file-system is
already locally hard-mounted on the server where the automount is being
performed. To illustrate, the output of a mount command on a server
that has automounted the file-system in question and does not have the
same file-system hard-mounted locally is:

/dev/cciss/c0d0p2 on / type ext3 (rw)
none on /proc type proc (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
usbdevfs on /proc/bus/usb type usbdevfs (rw)
/dev/cciss/c0d0p1 on /boot type ext3 (rw)
none on /dev/shm type tmpfs (rw)
/dev/cciss/c0d0p5 on /usr2 type ext3 (rw)
/dev/cciss/c0d0p6 on /usr1 type ext3 (rw)
automount(pid14871) on /var/autofs type autofs
(rw,fd=4,pgrp=14871,minproto=2,maxproto=4)
lk_rmsvip:/usr4 on /var/autofs/lk_rmsvip/usr4 type nfs
(rw,nosuid,nodev,hard,intr,addr=10.0.0.1)

The last line of this output indicates to me that NFS has been used in
the automounting of the "usr4" file-system being served up by the
"lk_rmsvip" server.

But if automount is used to mount this file-system on the same server
("lk_rmsvip") that already has the same file-system locally
hard-mounted, the output of a mount command on that server is as
follows:

/dev/cciss/c0d0p2 on / type ext3 (rw)
none on /proc type proc (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
usbdevfs on /proc/bus/usb type usbdevfs (rw)
/dev/cciss/c0d0p1 on /boot type ext3 (rw)
none on /dev/shm type tmpfs (rw)
/dev/cciss/c0d0p6 on /usr1 type ext3 (rw)
/dev/cciss/c0d0p5 on /usr2 type ext3 (rw)
/dev/cciss/c0d4p1 on /usr4 type ext3 (rw)
automount(pid21044) on /var/autofs type autofs
(rw,fd=4,pgrp=21044,minproto=2,maxproto=4)
/usr4 on /var/autofs/lk_rmsvip/usr4 type none (rw,bind)

In this case, you can see the local hard-mount of the "/usr4" file
system (mounted from the device node "/dev/cciss/c0d4p1") while the
last line of the output shows the automount of the same file-system but
I believe it demonstrates that automount used some sort of local mount
mechanism instead of a NFS mount. For my purposes, I would have
preferred a NFS mount to be used in this case. Is there a way to force
a NFS mount in this case?

The reason that I'm pursuing this line of investigation is that what
I've been referring to as the "lk_rmsvip" server is not really a
server at all. It is instead a virtual-service for a fail-over cluster
model that encapsulates an IP address, the "/usr4" file-system and
the NFS advertisement for the "/usr4" file-system. And as such,
this virtual-service can be migrated from one server to another and
this is why I want processes to access this file-system via NFS
mechanisms. In doing so, other than a brief delay in servicing file
I/O requests, processes accessing the file-system are virtually
unaffected by a migration of the virtual-service from one server to
another.

Again, many thanks for your input and if you or others have any further
insights to offer, they'd be much appreciated.

Thanks.

Steve Underwood

(E-Mail Removed) wrote:
> Unfortunately, however, even with the autofs/automount facility
> configured to use the "/etc/auto.net" mapping program, I'm
> encountering the same issue; namely that it appears NFS is not being
> used to automount the file-system in question if that file-system is
> already locally hard-mounted on the server where the automount is being
> performed.

Hmm. It's definitely not an NFS issue:

# mount -t nfs -o rw localhost:/var/tmp /mnt
# mount | grep mnt
localhost:/var/tmp on /mnt type nfs (rw,addr=127.0.0.1)

So anyway, I took a (quick) look at the source, and it appears that the
automounter is specifically using this shortcut, if possible.

The bottom line is that I don't think you're going to be able to get the
automounter to use NFS if it reckons it's easier to use a local mount.
Unless you modify the source (modules/mount_nfs.c, function mount_mount(),
where it calls get_best_mount() try setting the last parameter to be 1
instead of 0).

Chris

Thanks again Chris ... Based on the behavior I was observing with the
automounter, I had suspected the presence of those built-in "smarts"
and I really appreciate your effort in confirming this.

At this point the ball is firmly in my court. I need to evaluate
whether "dumbing-down" the automounter using the ideas you've provided
is an avenue I wish to pursue or if I want to spend a little more time
investigating another way of getting this file-system dynamically
mounted via NFS.

Many thanks for all your insight Chris.

Steve