The easy way to see underneath NFS mount points on Linux
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
NFS mount that you want to be able to access underneath. You can
/cs (which is most likely on the root filesystem) to,
/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).
/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.