Re: mount.nfs: chk_mountpoint()

[Chuck Lever <chuck.lever@oracle.com>]

[-- Attachment #1: Type: text/plain, Size: 1973 bytes --]

Peter Staubach wrote:
> Chuck Lever wrote:
>> Peter Staubach wrote:
>>> 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.
>>
>> I'm in great favor of autoconfiguration.  Anything that will make NFS 
>> "just work" is goodness, in my book.
>>
> 
> Is this an argument for or against autofs or these changes?

Making autofs a reliable and useful facility is a good thing.  Kudos to 
Ian and Jeff for their effort.

> The "bg" option was a hack added to speed up system booting.

I don't disagree with that assessment.

> A much better solution to the problem was autofs because it
> delayed the mounting until the file system was actually needed.

Whether or not it is a kludge, I don't think we have enough information 
about who is using it for what to blithely remove it without fanfare or 
documentation.

What alarms me more, though, is that we don't have any unit tests that 
caught this change before it went into the git repo.  This change, in 
itself, may not be terribly harmful.  But think of a minor and 
unintended change that might go in without notice, and break a lot of 
environments.

> The "bg" option can lead to applications not working correctly
> because the file system may or may not be mounted when they
> need it to be there and there is no automatic synchronization
> to block them until it is.  Autofs supplies this synchronization,
> thus once again, making it a vastly superior solution.

Some people find such enforced "synchronization" to be painful and 
annoying.  They would prefer a solution where the application is free to 
take its own recourse rather than hang indefinitely.

I think it is valid to want to have either type of behavior.

[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 290 bytes --]

begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
url:http://oss.oracle.com/~cel
version:2.1
end:vcard


[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs