"J. Lewis Muir" <[email protected]> writes: > Thank you for your reply! That makes sense. I guess my problem is > that I'm not sure where some of these remote file systems "fit." In > one case, I have a web app that needs read access to the log file of a > server process running on another machine. The web app runs under nginx > and resides at > > /var/www/<fqdn>/<web-app> > > I'm struggling to come up with a good idea for where the remote file > system that contains the server log file should be mounted. One idea > for the NFS mount point I had was > > /var/www/<fqdn>/<web-app>/internal/remote-server-logs > > but I wasn't super thrilled about that because it would reside under > the web-app's root, hence my wondering about a more generic mount point > location.
I would avoid that. Advice from starting to use NFS in the late 80s: Names are arbitrary. You are merely trying to avoid confusing programs that make assumptions, and confusing/offending humans that make assumptions. Still, those are both important. /mnt is for random use, when you have some unexpected drive and want to use it. People who know tradition would be very surprised at /mnt/nfs/host. So do not use /mnt. The automounter (amd) is a beast that some like and some do not. The notion of /net/foo as controlled by amd means to me that you should not use /net NFS access can hang when the remote host is down. This is a mess no matter what (soft/hard). Therefore you want to avoid a program that is not trying to access NFS from hanging. Therefore you do not want to mount the system alice in /alice, because then "ls -l /" will call stat on alice:/ over NFS. To avoid unintended stat calls, I would mount foo.example.com:/ as /nfs/foo.example.com I see your point about things deep in the hierarchy, but it's far saner to mount the system or part of it, and symlink in. If you had the disk from the system and mounted it, that's what you'd do.
