Why people put NFS mounts in subdirectories

February 4, 2011

One of the little pieces of Unix wisdom is that you should put NFS mounts (well, their mount points) in their own subdirectory. You don't mount NFS filesystems directly in /, you don't mount them in a directory with local subdirectories that you care about, and ideally you don't mix filesystems from different servers in the same subdirectory.

(In other words, an ideal mount point is, say, '/nfs/<server>/<fs>'.)

What is behind this is a combination of Unix directory traversal and that if you stat() or otherwise attempt to touch a NFS mount point from a server that isn't responding, your program hangs. In a classical Unix system a surprising number of programs walk directories and stat() at least some of what they find, even programs you might not think of like pwd. Some of them walk up the filesystem hierarchy, or at least wind up looking at the root directory.

(Even if an NFS server is responding it might be rather slow.)

It's unavoidable that programs that really want to deal with filesystems from an unavailable NFS server will have problems. But we would like unrelated processes to not be hampered by a hung NFS server; if your process or session doesn't care about the unavailable filesystems and would be unaffected if they weren't mounted at all, it shouldn't hang. Which means that any directory traversal that you do needs to be kept away from such NFS mounts, so that you don't wind up stalling yourself because you stat()'ed a directory entry for an NFS mount that you don't care about.

Segregating NFS mount points from regular directories and then further segregating them by their server minimizes the chances that you'll trip over an unrelated NFS filesystem during this sort of directory traversal.

(And putting NFS mounts directly in / means that any program that looks at the root directory and stat()'s things in it might hang or be delayed due to any of the NFS servers having problems.)

As a pragmatic matter, some of this is no longer applicable on many modern Unix systems. So this is probably on its way to sliding into a Unix superstition (or at least a sysadmin one).

Sidebar: how classic pwd works

The classic version of pwd has a simple algorithm:

  • stat . and remember its identity
  • read through .., stat'ing every entry until we find the one for .; we now know the name of the current directory
  • go up one directory and repeat the process
  • stop when we hit a directory where .. points to itself, because that means we've hit the root directory and we should be done

I call this pwd's algorithm, but it also appeared as getcwd() and was used by anything that needed to know the current directory, such as 'df .'.

Modern systems make getcwd() into a system call because they can; they keep enough extra information in kernel memory to return the information immediately.


Comments on this page:

From 207.172.69.99 at 2011-02-04 07:56:58:

More to the point, the data directories you are using should not be at the top of the mountpoint.

Let's say you have /nfs/server/fs1/, and you are writing files /nfs/server/fs1/data{1..30}.

If fs1 isn't mounted, the mountpoint directory still exists, and the files will be written to whatever is there -- very likely your root filesystem.

If, instead, you write to /nfs/server/fs1/datadir/data{1..30}, datadir will not exist when the filesystem is not mounted and you will get an error, which will hopefully lead to a correction of the problem.

This extends to all sorts of mounts, not just NFS. If you think the mount is potentially flaky, and you would rather get an error than fill your root, this is the way to go.

(Conversely, if you think that getting the data written is more important than where it gets written, you can leave the extra dir layer out, but you will need to monitor the mounts more carefully.)

-dsr-

By cks at 2011-02-04 12:25:38:

My personal feeling is that you need a very odd NFS environment for this to be much of an issue. You need to be doing the writing as root in order to write in to the unmounted directory and for this to work when the NFS mount is there you need your NFS mounts either to allow root through with full permissions or to be more or less world-writeable.

Written on 04 February 2011.
« The real lesson of XHTML
A side note on Google Chrome and the future of HTML »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Feb 4 01:25:10 2011
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.