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: [EMAIL PROTECTED] http://www.math.ucla.edu/~jimc (q.v. for PGP key) _______________________________________________ autofs mailing list [email protected] http://linux.kernel.org/mailman/listinfo/autofs
