The easy way to see underneath NFS mount points on Linux

October 21, 2021

One of the little and generally obscure problems of running NFS clients is that every so often you could wind up in a situation where you wanted to peek at what was on the underlying filesystem beneath an NFS mount, and you wanted to do this without the disruption of actually unmounting the NFS filesystem to expose what was below it. Sometimes this was because you thought a program might have written things to the directory hierarchy before the NFS mount had been made (and those writes were now invisible). Sometimes this was because you wanted to put copies of some vital things from the NFS mount into the underlying filesystem so they'd still be available if the NFS mount was delayed for some reason.

Traditionally people used various reasonably clever but somewhat awkward approaches to do this. Today I realized that for some time, Linux has provided a straightforward option for this in the form of bind mounts. Bind mounts make (part of) one filesystem appear at another, additional mount point and so can be used as a stronger form of symlinks (which is what I use them for). However, bind mounts also have the property that they don't 'see' things mounted on top of the original filesystem; instead they see only the filesystem that you're bind mounting.

Suppose that you put all your NFS mounts in subdirectories and have a /cs/site NFS mount that you want to be able to access underneath. You can bind mount /cs (which is most likely on the root filesystem) to, say, /var/local/cs, and then /var/local/cs/site is the part of the root filesystem that's underneath the /cs/site NFS mount. You can read and write it exactly as you would any other part of the root filesystem (and so can copy things from /cs/site to it). If the /cs/site NFS mount isn't there for some reason, your local versions can be used instead.

(You can't automatically use the local versions if the NFS mount is there but the NFS server isn't responding, only if you haven't been able to make the NFS mount. There may be complex Linux filesystem arrangements that would let that work, but I haven't looked into them.)

Whether it is a good idea to have local copies of critical bits of, say, your central administrative filesystem, is another question (even if you arrange to keep them up to date). On the one hand, maybe it's crucial to be able to do some things from that filesystem during boot or if the NFS mount isn't available yet. On the other hand, it adds a potential point of confusion to diagnosing problems. Rather than files that are either there or not there, now you have a filesystem that magically looks different (or potentially different) depending on when you look at it.

(I've seen extra copies of files and filesystems cause problems before.)


Comments on this page:

From 193.219.181.219 at 2021-10-22 09:17:02:

(You can't automatically use the local versions if the NFS mount is there but the NFS server isn't responding, only if you haven't been able to make the NFS mount. There may be complex Linux filesystem arrangements that would let that work, but I haven't looked into them.)

I wonder if fscache (i.e. the fsc option + cachefilesd in userspace + maybe also softreval?) would help with that. I'm not sure whether it was meant to support offline operation like AFS, or only to speed up online access.

(It's also being rebuilt from ground up in current linux-git, so the behavior might change.)

Written on 21 October 2021.
« In the beginning, there was no way to expand C's stack size
Python 2's status in various Linux distributions (October 2021 edition) »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Thu Oct 21 23:30:32 2021
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.