Re: autofs Digest, Vol 43, Issue 12

Re: autofs Digest, Vol 43, Issue 12

[Risto Bell]

 > My system defaults to tcp nfs v3 if no options are specified.

How does one achieve/config that (Solaris like) in autofs4?
Likewise achieving the NETAPP recommended TCP options timeo=600,retrans=2

If you have mix of servers, some only supporting UDP, but wish
to prefer TCPv3 whereever it's available and UDP only if no choice...

I use scripts programs (like auto.net), that do rpcinfo
to test if the server supports TCP and add the options. But even
emulating NIS look-ups, overall result (scripts) are considerably
slower.

Re: autofs Digest, Vol 43, Issue 12

[Peter Staubach]

Risto Bell wrote:
>  > My system defaults to tcp nfs v3 if no options are specified.
>
> How does one achieve/config that (Solaris like) in autofs4?
> Likewise achieving the NETAPP recommended TCP options timeo=600,retrans=2
>
> If you have mix of servers, some only supporting UDP, but wish
> to prefer TCPv3 whereever it's available and UDP only if no choice...
>
> I use scripts programs (like auto.net), that do rpcinfo
> to test if the server supports TCP and add the options. But even
> emulating NIS look-ups, overall result (scripts) are considerably
> slower.

Perhaps I am missing something, but the default NFS Version 3 over TCP.
If that is not available, then the client falls back to NFS Version 3
over UDP, NFS Version 2 over TCP, and then NFS Version 2 over UDP,
in that order.

As far as I can tell, it should not be necessary to specify any mount
options controlling the NFS protocol version or transport choice, unless
you specifically want it to be a single combination and not allow it to
fall back.

All that extra support is just overhead if the mount command is already
doing the right thing.

    Thanx...

       ps

autofs-4.1.3-150: Spooky ghosting benefit?: Less HUP's to refresh NIS maps

[Risto Bell]

Using autofs-4.1.3-150 on RedHat Enterprise 3 Update 6 with maps
in NIS. Servers primarily are: NETAPP, RHEL3-U6, or dwindling RH7.3.
Our NFS clients tend to lead NFS servers in OS upgrades. Also keep
RH automount timeout default of 60sec.

man automount:
   "The daemon also responds to a HUP signal which triggers an
update of maps for which ghosting is implemented (currently
FILE and NIS maps)."

Traditionally our linux NSF clients have troubles when NIS maps are
edited, and (without NIS map edit) when remote partitions are resized.
Requiring HUP of all clients (and if the mount was in use, the HUP
doesn't work on that daemon, the client as a CPU-server is in trouble,
needing careful manual killing of applications and/or reboot).
(Autofs I'll agree can't cause active mount failures on resize).

This was so especially without ghosting on. (Can say man page
technically doesn't say ghosting must be turned-on, only available
as theoretical option on that type of map; though easily mis-readable
to imply ghosting must be turned on).

However, reports from the field are that with ghosting enabled, the
need for HUP-ing clients is very much less. So much so that this is
viewed as the *dominant* benefit of ghosting. Compared to showing the
appearance of the dirs before mounted (which was not enough to trigger
us to enabled ghosting), this greater reliability from ghosting leading
to much fewer reboots and downtime: justifies distributing an update.

I'm thankful for this side-effect of course. Man page is silent about it.
Can anyone confirm this side-effect was observed or expected, or suggest
other reasons for it?