[NCLUG] autofs behaviour

[Bob Proulx]

Michael Coffman wrote:
>   date;while [[ -r /net/hostname/test ]]; do :; done; date
> 
> command output:
>   Fri Jul 11 09:02:46 MDT 2008
>   Fri Jul 11 09:03:59 MDT 2008
> command output run 2:
>   Fri Jul 11 09:11:42 MDT 2008
>   Fri Jul 11 09:12:45 MDT 2008

In my mind that looks like an autofs bug.  Having used autofs
extensively I don't recall seeing that type of behavior before.
Certainly autofs has annoying buggy behavior but I don't recall this
as being one of them.  The stat through /net/ should refresh the
unmount timers and prevent the unmount attempt.  Obviously it isn't
for your test case but I think it should.

I should create a test case and run it but for the moment am just
going to work the discussion based upon my poor memory.

> I believe that after the timeout, autofs tries to unmount file systems and 
> if they are busy, resets the timeout counter and remounts any unmounted 
> mount points if it is a host map.

Agreed.  For those cases where mount points are busy.  But your stat
above should be exercising the path down from /net/ and therefore
passing through the autofs layer with every loop.  However the shell
may be optimizing this out.  If it is bypassing the /net/ tree and
doing some optimization it may trick things.  It would be interesting
to try the same test again with an external command that can't avoid
the top down dir tree walk.

  date; while stat /net/hostname/test >/dev/null ; do :; done; date

It would be interesting to know if that behaves the same or
different.  Because it would take any possible path optimization out
of the test case.

It would be interesting to see by tcpdump and wireshark/ethereal that
the nfs getattr calls are proceeding as expected.

> But in general, I would think that I should never lose read access to the
> file.  Shouldn't autofs just remount it if it has been unmounted?

I think so, yes.

Autofs 'host' maps are notorious for dropping single mount points from
the set of all mount points on the host.  Is this a single mount point
on a host or is this one of a dozen mount points on a host?  At some
point (in the future still?) autofs starts to get smarter about mount
points and will handle them individually instead of as a group.  That
will be a good thing and should help with the dropped host mapped
mount point problem.

> BTW: am-utils (amd) does not behave this way.  I am guessing this
>      has to do with the fact that it runs in user space.

The 'amd' daemon has a different operating structure.  Every access to
/net/ forks a new amd daemon to handle the request and if I recall
correctly every mount point is individually handled.  This means that
if a single mount point is blocked for some reason the amd can
continue with other children on other mount points.  But it also means
that amd is slower than autofs since it uses heavy forked processes
for every top down dir tree access.  Plus a broken network mount point
can stack up amd processes all blocked waiting for that network mount
to respond.  In severe cases you can run the machine out of process
slots.  So while amd v. autofs debates continue it is really just a
different set of issues.  Depending on the problem one or the other
will be the better choice but neither are best all around.

Bob