Re: Status of mount.nfs

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

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

Steve Dickson wrote:
> Chuck Lever wrote:
>> Steve Dickson wrote:
>>> Chuck Lever wrote:
>>>> I was looking at this yesterday.  The stock timeout for TCP connects 
>>>> on Linux is 75 seconds.  The version of getport() used in the mount 
>>>> command might control the TCP connect timeout by using a 
>>>> non-blocking connect() with a select().  The select() then times out 
>>>> if the connection doesn't complete.
>>>>
>>>> But I'm wondering if we really want to continue using TCP for 
>>>> GETPORT calls.  Solaris mount appears to use only UDP for GETPORT, 
>>>> for example.
>>
>>> As as long as the GETPORTs don't use privilege ports I don't think its
>>> a problem...
>>
>> Not sure what you mean.  Yesterday you said the TCP connect timeout 
>> *was* a problem.  I've recommended two ways to address it.
> TCP timeouts are a problem if you can't control them... But
> point taken... UPD is probably the best way to query a
> portmapper or rpcbinder to get the needed info...

OK, I have a patch that shortens the TCP connect timeout for mount.nfs. 
  Will post a follow-up; please take a look.

>> The ephemeral port space is limited too, don't forget.  It's simply a 
>> somewhat larger space than the privileged port space.  If a large 
>> network application (say, a web server) is running on the system, that 
>> space can shrink fairly rapidly, and we're in nearly the same boat as 
>> with privileged ports.  Using a TCP connection from an ephemeral port 
>> only mitigates the port space problem, it doesn't really correct it 
>> entirely.
> Only mitigates the problem for a short time and you'll always run
> out of privileged port before running out of non-privileged but
> again... point taken... eliminating the problem is probably
> the answer...

Yes, and you've suggested a mount connection cache to help with this... 
that might be something reasonable to try in the kernel mount 
implementation at some point.

>> We say "firewall!" a lot, but I would like to see typical use cases 
>> for mounting through a firewall so I understand what kind of 
>> implementation we're aiming for (and maybe even what kind of test 
>> cases to build!).  Do our users really expect to mount NFS shares 
>> through any firewall with "-o defaults" ?
> Yes! Mostly on the server side... meaning people wanted to set the
> port the daemons listen on (via the initscripts) so clients can
> access the server through a firewall... Is this a common setup?
> No. But there are people that want a firewall between the
> server and client..

I'm not suggesting that we don't support mounting through a firewall. 
I'm wondering, though, how people expect it to work.  Is it acceptable 
to require a few extra mount options on clients to mount successfully 
through a firewall, or should a mount with no options whatsoever always 
work in this case?

And, does anyone have real and precise test cases to make sure we don't 
break mounting through a firewall when changes are made to the mount 
infrastructure?

> Also I can only assume the reason for the
> 'mountport=" option was to work better with firewalls...
> but that is only speculation...

I agree that the mount{prog,vers,port}= options are very likely for 
mounting through firewalls.

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