Re: mount.nfs: chk_mountpoint()

[Peter Staubach <staubach@redhat.com>]

Chuck Lever wrote:
> Peter Staubach wrote:
>> Chuck Lever wrote:
>>> Hi all-
>>>
>>> The recent addition of the chk_mountpoint() function in 
>>> utils/mount/mount.c in nfs-utils commit 3b55934b has broken a 
>>> particular behavior of background mounts.
>>>
>>> nfs(5) states that, if the "bg" option is specified, "A missing 
>>> mount point is treated as a timeout, to allow for nested NFS mounts."
>>>
>>> If I try mounting an NFS share onto a non-existent directory while 
>>> using the "bg" option, I now get an immediate failure:
>>>
>>>   mount.nfs: mount point /mnt/nothere does not exist
>>>
>>> instead of the mount backgrounding itself to wait for /mnt/nothere 
>>> to show up.  This is because chk_mountpoint() is causing the mount 
>>> request to fail immediately.
>>>
>>> Is the documented bg retry behavior still desirable? 
>>
>> Isn't this what autofs is for?  To be able to handle hierarchies
>> of mounts?
>
> I think the purpose of this feature is to allow a sysadmin to specify 
> a set of mount points in /etc/fstab, some possibly nested.  "mount -a 
> -tnfs" should work no matter what order the mounts in /etc/fstab are 
> specified.
>
> After all, some servers may be unresponsive when the client boots -- 
> the mounting order is nondeterministic; it can't be depended on, in 
> any event.
>
> We also don't know if the automounter itself depends on this feature.

Autofs depending upon this feature would be a large mistake.
IMHO, of course.  :-)

I don't think that it does.

But your explanation makes sense, although we should be moving
people away from static mounts in fstab and towards dynamic
mounting via autofs.  Ian and Jeff have made autofs much, much
better in recent times.  Improving autofs further to make it
only mount file systems which are actually referenced would make
it even better.

How do we find out whether we need to continue supporting this
semantic or whether we can do away with it?  Clearly, if it was
busted, then not many people were depending upon it because
there didn't seem to be any hue and cry about it not working.

    Thanx...

       ps

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs