How exactly does timeout work?

How exactly does timeout work?

[Paul Smith]

I've looked around but I couldn't find an answer to this question.
There are a lot of offhand comments saying the filesystem will be
unmounted after timeout seconds, but that's not very precise.

If, for example, I set --timeout=60, does that mean the FS will unmount
60 seconds after it was last accessed?

Or, does it mean that every 60 seconds automount will wake up and see if
anyone is using the filesystem, and if not unmount it?

-- 
-----------------------------------------------------------------------------
 Paul D. Smith <psmith@netezza.com>                       http://netezza.com
 "Please remain calm--I may be mad, but I am a professional."--Mad Scientist
-----------------------------------------------------------------------------
      These are my opinions--Netezza takes no responsibility for them.

Re: How exactly does timeout work?

[Jeff Moyer]

==> On Mon, 09 Apr 2007 11:45:54 -0400, Paul Smith <psmith@netezza.com> said:

Paul> I've looked around but I couldn't find an answer to this
Paul> question.  There are a lot of offhand comments saying the
Paul> filesystem will be unmounted after timeout seconds, but that's
Paul> not very precise.

Paul> If, for example, I set --timeout=60, does that mean the FS will
Paul> unmount 60 seconds after it was last accessed?

Paul> Or, does it mean that every 60 seconds automount will wake up
Paul> and see if anyone is using the filesystem, and if not unmount
Paul> it?

If you set the timeout to 60 seconds, the automount daemon will wake
up approximately every 15 seconds (4 times per timeout, see
CHECK_RATIO in the daemon) and ask the kernel if it is okay to expire
the mount.

-Jeff

Re: How exactly does timeout work?

[Jeff Moyer]

==> On Mon, 09 Apr 2007 12:14:18 -0400, Jeff Moyer <jmoyer@redhat.com> said:

==> On Mon, 09 Apr 2007 11:45:54 -0400, Paul Smith <psmith@netezza.com> said:
Jeff> Paul> I've looked around but I couldn't find an answer to this
Jeff> Paul> question.  There are a lot of offhand comments saying the
Jeff> Paul> filesystem will be unmounted after timeout seconds, but
Jeff> that's Paul> not very precise.

Jeff> Paul> If, for example, I set --timeout=60, does that mean the FS
Jeff> will Paul> unmount 60 seconds after it was last accessed?

Jeff> Paul> Or, does it mean that every 60 seconds automount will wake
Jeff> up Paul> and see if anyone is using the filesystem, and if not
Jeff> unmount Paul> it?

Jeff> If you set the timeout to 60 seconds, the automount daemon will
Jeff> wake up approximately every 15 seconds (4 times per timeout, see
Jeff> CHECK_RATIO in the daemon) and ask the kernel if it is okay to
Jeff> expire the mount.

I guess I should further qualify this.  Asking the kernel means
issuing an ioctl.  The kernel then checks the access time for the
mount point and, if it is > timeout seconds ago, it will try to expire
the mount (by calling out to the daemon).

-Jeff

Re: How exactly does timeout work?

[Paul Smith]

On Mon, 2007-04-09 at 12:44 -0400, Jeff Moyer wrote:
> Jeff> If you set the timeout to 60 seconds, the automount daemon will
> Jeff> wake up approximately every 15 seconds (4 times per timeout, see
> Jeff> CHECK_RATIO in the daemon) and ask the kernel if it is okay to
> Jeff> expire the mount.
> 
> I guess I should further qualify this.  Asking the kernel means
> issuing an ioctl.  The kernel then checks the access time for the
> mount point and, if it is > timeout seconds ago, it will try to expire
> the mount (by calling out to the daemon).

Perfect; that's what I was looking for.  So, CHECK_RATIO is a constant
regardless of the size of the timeout?  So if I make my timeout 10 hours
it will check every 2.5 hours (unless I change the constant in the
daemon code)?

-- 
-----------------------------------------------------------------------------
 Paul D. Smith <psmith@netezza.com>                       http://netezza.com
 "Please remain calm--I may be mad, but I am a professional."--Mad Scientist
-----------------------------------------------------------------------------
      These are my opinions--Netezza takes no responsibility for them.

Re: How exactly does timeout work?

[Jeff Moyer]

==> On Mon, 09 Apr 2007 12:48:35 -0400, Paul Smith <psmith@netezza.com> said:

Paul> On Mon, 2007-04-09 at 12:44 -0400, Jeff Moyer wrote: > Jeff> If
Paul> you set the timeout to 60 seconds, the automount daemon will >
Paul> Jeff> wake up approximately every 15 seconds (4 times per
Paul> timeout, see > Jeff> CHECK_RATIO in the daemon) and ask the
Paul> kernel if it is okay to > Jeff> expire the mount.
Paul> > 
Paul> > I guess I should further qualify this.  Asking the kernel
Paul> means > issuing an ioctl.  The kernel then checks the access
Paul> time for the > mount point and, if it is > timeout seconds ago,
Paul> it will try to expire > the mount (by calling out to the
Paul> daemon).

Paul> Perfect; that's what I was looking for.  So, CHECK_RATIO is a
Paul> constant regardless of the size of the timeout?  So if I make my
Paul> timeout 10 hours it will check every 2.5 hours (unless I change
Paul> the constant in the daemon code)?

That is correct.

-Jeff

Re: How exactly does timeout work?

[Paul Smith]

On Mon, 2007-04-09 at 12:57 -0400, Jeff Moyer wrote:
> That is correct.

OK, good.  Might be worth a sentence or two in the man page for
automount... on the other hand I wasn't able to find anyone else asking
this question before so maybe no one else cares that much :).

-- 
-----------------------------------------------------------------------------
 Paul D. Smith <psmith@netezza.com>                       http://netezza.com
 "Please remain calm--I may be mad, but I am a professional."--Mad Scientist
-----------------------------------------------------------------------------
      These are my opinions--Netezza takes no responsibility for them.

Re: How exactly does timeout work?

[Jeff Moyer]

==> On Mon, 09 Apr 2007 13:14:30 -0400, Paul Smith <psmith@netezza.com> said:

Paul> On Mon, 2007-04-09 at 12:57 -0400, Jeff Moyer wrote: > That is
Paul> correct.

Paul> OK, good.  Might be worth a sentence or two in the man page for
Paul> automount... on the other hand I wasn't able to find anyone else
Paul> asking this question before so maybe no one else cares that much
Paul> :).

I'm not sure that the internals are really worth discussing in the man
page, but perhaps others disagree.  We'll see what Ian thinks.

-Jeff

Re: How exactly does timeout work?

[Paul Smith]

On Mon, 2007-04-09 at 13:21 -0400, Jeff Moyer wrote:
> I'm not sure that the internals are really worth discussing in the man
> page

I agree with you to some extent, and I don't think the underlying method
(using an ioctl, etc.) should be documented there, but I think the
details of this algorithm can make a difference to how you decide set
the timeout value, especially for larger timeouts.  It's not even really
clear (from my reading of the man page) that the timeout is "time from
the last access of the filesystem", as opposed to "how often we check to
see if anyone is using it".  At the least it seems like that should be
made clear, even if the other details (how often the daemon checks for
example) are not spelled out.  Maybe the text:

-t, --timeout
        Set the minimum timeout, in seconds, until directories are
        unmounted.  The default is 5 minutes.  Setting the timeout to
        zero disables unmounts completely.

could be rewritten as:

-t, --timeout
        Set the minimum timeout, in seconds, from the last access of the
        directory until it is unmounted.  The default is 5 minutes.
        Setting the timeout to zero disables unmounts completely.

An extra sentence could also be added: "Access times are checked
periodically, so the actual timeout will be greater than this value.
The longer the timeout, the less frequently the access times are
checked." or something.

> We'll see what Ian thinks.

OK, cheers!

-- 
-----------------------------------------------------------------------------
 Paul D. Smith <psmith@netezza.com>                       http://netezza.com
 "Please remain calm--I may be mad, but I am a professional."--Mad Scientist
-----------------------------------------------------------------------------
      These are my opinions--Netezza takes no responsibility for them.

Re: How exactly does timeout work?

[Ian Kent]

On Mon, 2007-04-09 at 13:36 -0400, Paul Smith wrote:
> On Mon, 2007-04-09 at 13:21 -0400, Jeff Moyer wrote:
> > I'm not sure that the internals are really worth discussing in the man
> > page
> 
> I agree with you to some extent, and I don't think the underlying method
> (using an ioctl, etc.) should be documented there, but I think the
> details of this algorithm can make a difference to how you decide set
> the timeout value, especially for larger timeouts.  It's not even really
> clear (from my reading of the man page) that the timeout is "time from
> the last access of the filesystem", as opposed to "how often we check to
> see if anyone is using it".  At the least it seems like that should be
> made clear, even if the other details (how often the daemon checks for
> example) are not spelled out.  Maybe the text:
> 
> -t, --timeout
>         Set the minimum timeout, in seconds, until directories are
>         unmounted.  The default is 5 minutes.  Setting the timeout to
>         zero disables unmounts completely.
> 
> could be rewritten as:
> 
> -t, --timeout
>         Set the minimum timeout, in seconds, from the last access of the
>         directory until it is unmounted.  The default is 5 minutes.
>         Setting the timeout to zero disables unmounts completely.
> 
> An extra sentence could also be added: "Access times are checked
> periodically, so the actual timeout will be greater than this value.
> The longer the timeout, the less frequently the access times are
> checked." or something.
> 
> > We'll see what Ian thinks.

The wording may need to be a bit different.

Problem is the definition of "busy" which changed in the kernel module
during the version 5 development.

To avoid confusion let me say first that the "autofs4" kernel module
supports "autofs" protocols 3, 4 and 5. So the module name and package
versions can be a source of confusion. The protocol version essentially
determines the information contained in the packet used to communicate
between the module and userspace and not the way in which the expiration
is calculated.

The inode access times aren't (and never were) used to determine
timeout. So the words "Access times" might end up being be misleading.

An expire check is done 4 times a per timeout interval as Jeff pointed
out. There a is small displacement (a proportion of timeout interval)
added to the initial check to try to prevent mounts all being checked at
the same time which can cause expire umounts to happen a little after
the timeout.

For the check itself the kernel module updates a last_used variable for
each mount.

Prior to version 5 update this was updated for any access. So "busy"
could be loosely defined as "any access".

Following the version 5 update it is only updated if the mount is really
busy. This means only if at least one process working directory or any
open file is within the filesystem at the time of an expire check. So
the umount will be triggered timeout seconds after the last working
directory is changed to somewhere outside the filesystem and any open
files have been closed.

I don't want to go into the details of why this was done other than to
say it was required for the direct mount implementation and was done
across the board for consistency and simplicity in the kernel module.

The version 5 update has been in kernel for quite a while now and
doesn't seem to has caused problems.

So I'm not sure what wording should be used in the man page and maybe
it's not such a big deal but there is a difference between kernel
versions.

Sorry for the rant and I hope I haven't completely confused the issue.

Ian

Re: How exactly does timeout work?

[Jim Carter]

On Tue, 10 Apr 2007, Ian Kent wrote:

> The inode access times aren't (and never were) used to determine
> timeout. So the words "Access times" might end up being be misleading.
> ...
> Prior to version 5 update this was updated for any access. So "busy"
> could be loosely defined as "any access".
> 
> Following the version 5 update it is only updated if the mount is really
> busy. This means only if at least one process working directory or any
> open file is within the filesystem at the time of an expire check...

So if my mail monitor stats my mailbox, on an otherwise unused automounted 
filesystem, every few seconds, the filesystem would be eligible to be 
unmounted but would be remounted a few seconds later.  And similarly if the 
KDE or Gnome desktop used the same strategy on remote directories, we hope 
not too many of them.  A lot of sysops complain about this behavior.

The "right" way to handle the issue is if the application uses FAM to 
detect changes, not the stupid polling.  But if network FAM is enabled and 
you set a watch on the mailbox, and the filesystem is then unmounted, will 
local FAM maintain the net connection to FAM on the the residence host?  
I have no idea, and in any case this is not a relevant issue for autofs.

Or alternatively the application could fork a process that would cwd to the 
containing directory, preventing unmounting.  That's a lot of overhead 
particularly for a desktop with lots of folders.  

You want to encourage unmounting, particularly with NFSv4 which has its 
own unmounting paradigm, because if the server is rebooted you'll end up 
with a stale NFS filehandle on all mounted filesystems, which in my 
experience does not self-heal reliably.

James F. Carter          Voice 310 825 2897    FAX 310 206 6673
UCLA-Mathnet;  6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA  90095-1555
Email: jimc@math.ucla.edu    http://www.math.ucla.edu/~jimc (q.v. for PGP key)

Re: How exactly does timeout work?

[Ian Kent]

On Tue, 2007-04-10 at 11:06 -0700, Jim Carter wrote:
> On Tue, 10 Apr 2007, Ian Kent wrote:
> 
> > The inode access times aren't (and never were) used to determine
> > timeout. So the words "Access times" might end up being be misleading.
> > ...
> > Prior to version 5 update this was updated for any access. So "busy"
> > could be loosely defined as "any access".
> > 
> > Following the version 5 update it is only updated if the mount is really
> > busy. This means only if at least one process working directory or any
> > open file is within the filesystem at the time of an expire check...
> 
> So if my mail monitor stats my mailbox, on an otherwise unused automounted 
> filesystem, every few seconds, the filesystem would be eligible to be 
> unmounted but would be remounted a few seconds later.  And similarly if the 
> KDE or Gnome desktop used the same strategy on remote directories, we hope 
> not too many of them.  A lot of sysops complain about this behavior.

Agreeded but I had to do something.
Having direct mount functionality that works was a very high priority.

> 
> The "right" way to handle the issue is if the application uses FAM to 
> detect changes, not the stupid polling.  But if network FAM is enabled and 
> you set a watch on the mailbox, and the filesystem is then unmounted, will 
> local FAM maintain the net connection to FAM on the the residence host?  
> I have no idea, and in any case this is not a relevant issue for autofs.

Don't think that autofs would fit the use of FAM particularly well.
But I'll investigate that and see.

> 
> Or alternatively the application could fork a process that would cwd to the 
> containing directory, preventing unmounting.  That's a lot of overhead 
> particularly for a desktop with lots of folders.  

autofs doesn't have enough information available to it to sensibly use
this approach.

> 
> You want to encourage unmounting, particularly with NFSv4 which has its 
> own unmounting paradigm, because if the server is rebooted you'll end up 
> with a stale NFS filehandle on all mounted filesystems, which in my 
> experience does not self-heal reliably.

Yep, so I'm half way there.

Ian