Re: NFS client permanent mount points under /mnt?
On Sun, Jul 28, 2019 at 04:55:15PM +0930, Brett Lymn wrote: |On Thu, Jul 25, 2019 at 08:02:34PM -0400, Greg Troxel wrote: |> /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. | |agreed, don't use /mnt, unfortunately linux does. I have shot myself in |the foot many a time when doing a rescue, mount something on /mnt and |then the rescue collapses because they built a mount tree under /mnt |that I just covered up... gah Solaris typically mounts the system being installed/rescued under /a for this exact reason ... |> 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. | |I don't agree with this - creating sym links can lead to a bunch of |dangling sym links all over your file system, they can be hard to track |down so messy to clean up. Much better to mount the fs where it is |supposed to be in the first place. Also, to be nit-picky there is a |performance impact from a sym link, the link is read every time it is |traversed so you double your reads on a path traversal for every sym |link. I second this - I once inherited a site ($JOB-3) where (for some non-obvious reasons) our Irix fleet depended upon a symlink hanging off the NFS share from a central Linux box that pointed back to their own local filesystem(!!) ... that was a fun one to sort out when we had a hiccup with our main fileserver as they all just ... stopped ... since then I've been a fan of mounting a filesystem somewhere out of the way and then null/bind mounting where I actually need the content ... makes things nice and explicit and easily discoverable ... this was back in the day before LVM and ZFS with their pool-based model, so really the only option to managing free space was sometimes to migrate data between large filesystems and altering the relevant mounts ... the users were none the wiser once that had completed ... and the nice thing was that I couldn't unmount whilst anyone was using it, whereas with a symlink you might not notice that it's changed that said, sometimes unexpected mount ordering can ruin your day, especially when there's something like ZFS in the mix, which does its mounts outside of the usual 'mount -a' scope ... yes, one can flag particular filesystems as 'mountpoint=legacy' which means they get mounted from /etc/fstab, but that's ... hacky (and ZFS needs to be explicitly enabled for bind mounts under Linux anyway) Regards, Malcolm -- Malcolm Herbert m...@mjch.net
Re: NFS client permanent mount points under /mnt?
On Thu, Jul 25, 2019 at 08:02:34PM -0400, Greg Troxel wrote: > > I would avoid that. Advice from starting to use NFS in the late 80s: > ... only a few years behind you. > >/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. > agreed, don't use /mnt, unfortunately linux does. I have shot myself in the foot many a time when doing a rescue, mount something on /mnt and then the rescue collapses because they built a mount tree under /mnt that I just covered up... gah > >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. > If you mount with the intr option you can at least inerrupt the process. This is not deault because of the fear of losing data written by the process. > >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. > I don't agree with this - creating sym links can lead to a bunch of dangling sym links all over your file system, they can be hard to track down so messy to clean up. Much better to mount the fs where it is supposed to be in the first place. Also, to be nit-picky there is a performance impact from a sym link, the link is read every time it is traversed so you double your reads on a path traversal for every sym link. -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"
Re: NFS client permanent mount points under /mnt?
"J. Lewis Muir" 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// > > 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///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.
Re: NFS client permanent mount points under /mnt?
On 07/25, Johnny Billquist wrote: > For your question, the answer is essentially "where it fits". > > If you, for example have the netbsd source tree available over NFS, the > reasonable place to mount it would be under /usr/src > If you have user home directories over NFS, /home might be a good place. > > It does not make sense to have a generic universal mount point for all > different file systems you might want to mount. NFS or otherwise. Are you > also mounting all disk file systems under some specific point in your file > system? 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// 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///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. Regards, Lewis
Re: NFS client permanent mount points under /mnt?
For your question, the answer is essentially "where it fits". If you, for example have the netbsd source tree available over NFS, the reasonable place to mount it would be under /usr/src If you have user home directories over NFS, /home might be a good place. It does not make sense to have a generic universal mount point for all different file systems you might want to mount. NFS or otherwise. Are you also mounting all disk file systems under some specific point in your file system? /mnt is indeed a mount point I use for random system work when I just need some convenient mount point for temporary messing around. Since I almost never use the automounter, I don't know where I'd place such stuff, but /net sounds as good as anything. I wonder if I might have seen /auto used for that in the past. Johnny On 2019-07-25 22:50, J. Lewis Muir wrote: Hi, all! I'm wondering, what's the best location for a client machine to permanently mount NFS remote file systems? I was thinking /mnt/ or maybe (but I'm less convinced that encoding the type of the remote file system in the path is a good idea): /mnt/nfs/ However, in hier(7) https://netbsd.gw.com/cgi-bin/man-cgi?hier++NetBSD-current it says /mnt/ Empty directory commonly used by system administrators as a temporary mount point. The phrase "as a temporary mount point" sounds to me like /mnt is intended to remain empty and only be used by a system administrator as a mount point when they need to temporarily mount a file system manually and then presumably unmount it when no longer needed. I would like an appropriate (i.e., best practice) location where I can permanently mount remote file systems. Where should these go? Or is hier(7) just saying what /mnt is commonly used for, and if I used it for something else, that would be considered fine? I could even create an empty /mnt/tmp, for example, to ensure that there still is a good place for a system administrator to temporarily mount a file system if needed. Also in hier(7) is /net/ automounted NFS shares; see auto_master(5) That's clearly a good place, but it means using the automounter. I was hoping to not use the automounter, but perhaps I could if that's really the best thing to do. I haven't looked into the automounter, so maybe it's easy to do, but in one case, I'm needing to have a parent directory that contains the mount-point subdirectory because I need to ensure that the permissions are set to 0550 on the parent directory to prevent read access by other users on the client machine to any files in the mounted remote tree that have their other-read bit set. Thanks! Lewis -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
NFS client permanent mount points under /mnt?
Hi, all! I'm wondering, what's the best location for a client machine to permanently mount NFS remote file systems? I was thinking /mnt/ or maybe (but I'm less convinced that encoding the type of the remote file system in the path is a good idea): /mnt/nfs/ However, in hier(7) https://netbsd.gw.com/cgi-bin/man-cgi?hier++NetBSD-current it says /mnt/ Empty directory commonly used by system administrators as a temporary mount point. The phrase "as a temporary mount point" sounds to me like /mnt is intended to remain empty and only be used by a system administrator as a mount point when they need to temporarily mount a file system manually and then presumably unmount it when no longer needed. I would like an appropriate (i.e., best practice) location where I can permanently mount remote file systems. Where should these go? Or is hier(7) just saying what /mnt is commonly used for, and if I used it for something else, that would be considered fine? I could even create an empty /mnt/tmp, for example, to ensure that there still is a good place for a system administrator to temporarily mount a file system if needed. Also in hier(7) is /net/ automounted NFS shares; see auto_master(5) That's clearly a good place, but it means using the automounter. I was hoping to not use the automounter, but perhaps I could if that's really the best thing to do. I haven't looked into the automounter, so maybe it's easy to do, but in one case, I'm needing to have a parent directory that contains the mount-point subdirectory because I need to ensure that the permissions are set to 0550 on the parent directory to prevent read access by other users on the client machine to any files in the mounted remote tree that have their other-read bit set. Thanks! Lewis
