[NTLUG:Discuss] A UNIX/Linux Staple: The Automounter -- WAS: Rebuilding (G)libc from an SRPM

[Bryan J. Smith]

On Fri, 2004-09-24 at 14:52, George Lass wrote:
> Bryan,
> Sounds like automount might be a better solution for me
> than a "hard" NFS mount.  I am taking this discussion
> private for now because I have some very specific questions
> that might not be of interest to anyone else,

I don't see why not?  I'd be curious how many people don't know
about the automounter?  It's a staple of standard UNIX/Linux capability.

Unlike Windows, which was designed for single user, near-full access to
the system, UNIX is multiuser, limited access.  As such, since users
cannot execute operations such as mounting remote filesystems, things
like the automounter are necessary.  It lets the sysadmin define what
mounts are accessible by users, and they are mounted only when needed.
And they are umounted after a period of inactivity.

> so if you've got a few minutes here they are.  If you don't have time,
> just put me on ignore and I won't be offended......
> (All of this "assumes" that I've converted my system to automount)

No real "conversion."  The automounter is built into the kernel -- since
it is an extension of the virtual filesystem (VFS) subsystem.  You
merely start a user-space service to manage the configuration (including
passing NIS/LDAP automounter maps).

You just take entries out of /etc/fstab, and put them in /etc/auto.*
files.  Start the user-space daemon and you're go!

> 1) once my system boots up, and my application then tries to write
> to the former NFS file, will the application process "suspend"
> until the file has been "mounted"?

It's no different than normal NFS operations.  NFS is stateful, so yes. 
The application "hangs" until it can write to the filesystem.  That
assumes you are using the default of "hard" mounts.  I also use the
"bg" to background mounts when they cannot be made, so the application
does not crap out.  If you like you can use the "intr" so applications
can interrupt any access to a NFS mount.

Again, these are the same for NFS regardless of use of the automounter.

The _only_ difference is that automounter _only_ mounts filesystems
(NFS, etc...) _when_ they are accessed, and umounts them automatically
when they are not.  You can even use it for floppies so it pseudo acts
like Windows (attempts to mount when you access /mnt/floppy,
automatically umounts/flushes after a short timeout -- like 5 seconds).

> 2) if the former NFS server is down when an attempt is made to
> automount the file, does the application trying to write it
> get an error return to the write call?

Again, no different than NFS operations.

NFS is stateful by default ("hard" mount).  So the program will wait
("hang") until the mount is available.  If no other program is accessing
the NFS mount, then your system works as normal.

If you want NFS to try to act stateless, like SMB, you can use a "soft"
mount.  But that typically breaks a lot of UNIX programs.  NFS is very
different than SMB -- because it is mounted like it is a local
filesystem -- inodes and all.

Alternatively, you _can_ mount NFS with "intr" -- which allows a program
to interrupt the operation.  It's up to the program to handle this
properly.

> 3) will each attempt to write to the "down'ed" server  cause the
> same delay or is automount smart enough to know that the server
> is down, and give an error return immediately?

Again, it all depends.  This is 100% NFS, and 0% automounter.

The automounter doesn't change any behavior of the underlying filesystem
mount.  It merely only mounts the filesystems if and when they are
accessed (e.g., cd /net/oviedo/apps) -- and then umounts them when a
timeout of no access has passed.

As far as everything else, those are normal NFS considerations.

-- 
Bryan J. Smith                                  b.j.smith at ieee.org 
------------------------------------------------------------------ 
"Communities don't have rights. Only individuals in the community
 have rights. ... That idea of community rights is firmly rooted
 in the 'Communist Manifesto.'" -- Michael Badnarik