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


_______________________________________________
autofs mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/autofs

Reply via email to