Re: NFS client permanent mount points under /mnt?

[Brett Lymn <blymn%internode.on.net@localhost>]

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"