Re: mount.nfs: chk_mountpoint()

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

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

Peter Staubach wrote:
> Frank van Maarseveen wrote:
>> On Thu, Aug 23, 2007 at 04:12:30PM -0400, Peter Staubach wrote:
>>  
>>> I would guess that not so many people are using the "bg" option,
>>> period.  Many of Linux's customers are ex-Sun customers and they
>>> were educated to use autofs and to move away from and stay away
>>> from static mounts via fstab or vfstab.
>>>
>>> The "bg" option was a hack added to speed up system booting.
>>>     
>>
>> No, it is indispensable to recover properly from a power outage:
>> servers tend to boot slower than clients. Also, it is not unusual to
>> have some minor network/server problems after an outage causing the
>> mount to fail.
>>
>> Without the bg option a temporary power outage may render all client
>> systems unusable.
> 
> And a better solution to this problem is still to use autofs.
> 
> That said, what use are the clients _until_ the servers are up?
> The applications on them can't run correctly because the file
> systems that they depend upon may or may not be there yet.  With
> autofs, you would have a chance of getting the synchronization
> right.
> 
> You also get all sorts of benefits such as decreased resource
> usage (by not having inactive file systems mounted), reduced
> hangs (by not having inactive file systems from servers which
> go down still mounted), in addition to the situation described
> above and other benefits as well.
> 
> I do recognize that we can't get rid of the bg option, but I
> would request that people using it consider different alternatives
> to solving their problems.

For the record, one downside to using automounter is the mount storm 
that is caused when a distributed application starts up on multiple 
clients requiring many NFS mount points on each client.  This is one 
reason some sites choose not to use automounter.  "bg"s retry behavior, 
though a kludge, is somewhat more friendly.

 From my experience, generally mountd (on most any server 
implementation) has been a scalability problem in these scenarios.  It 
can't handle more than a few requests per second.

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