[NCLUG] autofs behaviour

[Michael Coffman]

FYI - A quick test on Ubuntu 7.04 Yields running autofs 4.1.4-13build1
yields:

test1:
Fri Jul 11 15:57:35 MDT 2008
stat: cannot stat `/net/farmall/mnt/grid/test': No such file or directory
Fri Jul 11 16:03:25 MDT 2008

test2:
ri Jul 11 16:04:02 MDT 2008
stat: cannot stat `/net/farmall/mnt/grid/test': No such file or directory
Fri Jul 11 16:09:40 MDT 2008


On Fri, 11 Jul 2008, Bob Proulx wrote:

> 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
> _______________________________________________
> NCLUG mailing list       NCLUG at nclug.org
>
> To unsubscribe, subscribe, or modify
> your settings, go to:
> http://www.nclug.org/mailman/listinfo/nclug
>

-- 
-MichaelC