inconsistencies in nfs(5)

inconsistencies in nfs(5)

[Chuck Lever]

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

Trying to get a handle on how individual mount options behave, I'm 
rewriting nfs(5).  Jeff Layton pointed out a few inconsistencies and 
I've found a few more.  I'd like to resolve these:

+  The default "intr" behavior for nfs and nfs4 is not the same. 
According to the code, for nfs the default is "nointr" and for nfs4 the 
default is "intr".  Is this the desired behavior?

+  "nocto" and "noac" are listed as valid nfs4 mount options.  I believe 
"nocto" can't be supported by the NFSv4 protocol because an OPEN on the 
wire is always necessary.  Is "noac" supported for nfs4 file systems?

+  Is the "noacl" option still supported in 2.6.latest?  What exactly 
does it do, and what are the consequences of using it?

+  The description for the "bg" option claims "After a mount operation 
is backgrounded, all subsequent mounts on the same NFS server will be 
backgrounded immediately, without first attempting the mount."  I don't 
think there's logic to do that in either the legacy mount command or in 
mount.nfs.  Should this text be removed from the man page?

Likely more to come...

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

Re: inconsistencies in nfs(5)

[rnews]

Chuck Lever <chuck.lever@oracle.com> wrote:
| +  The description for the "bg" option claims "After a mount operation 
| is backgrounded, all subsequent mounts on the same NFS server will be 
| backgrounded immediately, without first attempting the mount."  I don't 
| think there's logic to do that in either the legacy mount command or in 
| mount.nfs.  Should this text be removed from the man page?

I added that text in 1997, in a patch that was included in mount-2.7g.
It referred to the following fragment in nfsmount.c:

+       /*
+        * If the previous mount operation on the same host was
+        * backgrounded, and the "bg" for this mount is also set,
+        * give up immediately, to avoid the initial timeout.
+        */
+       if (bg && !running_bg &&
+           prev_bg_host && strcmp(hostname, prev_bg_host) == 0) {
+               if (retry > 0)
+                       retval = EX_BG;
+               return retval;
+       }

This code got removed somewhere after util-linux-2.12p, but I don't
know the details.

-- 
Dick Streefland                      ////                      Altium BV
dick.streefland@altium.nl           (@ @)          http://www.altium.com
--------------------------------oOO--(_)--OOo---------------------------


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

Re: inconsistencies in nfs(5)

[Chuck Lever]

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

rnews@tasking.nl wrote:
> Chuck Lever <chuck.lever@oracle.com> wrote:
> | +  The description for the "bg" option claims "After a mount operation 
> | is backgrounded, all subsequent mounts on the same NFS server will be 
> | backgrounded immediately, without first attempting the mount."  I don't 
> | think there's logic to do that in either the legacy mount command or in 
> | mount.nfs.  Should this text be removed from the man page?
> 
> I added that text in 1997, in a patch that was included in mount-2.7g.
> It referred to the following fragment in nfsmount.c:
> 
> +       /*
> +        * If the previous mount operation on the same host was
> +        * backgrounded, and the "bg" for this mount is also set,
> +        * give up immediately, to avoid the initial timeout.
> +        */
> +       if (bg && !running_bg &&
> +           prev_bg_host && strcmp(hostname, prev_bg_host) == 0) {
> +               if (retry > 0)
> +                       retval = EX_BG;
> +               return retval;
> +       }
> 
> This code got removed somewhere after util-linux-2.12p, but I don't
> know the details.

This is still in utils/mount/nfsmount.c.

I'm not sure how this can affect other mount commands running 
concurrently on the same client.  The man page implies that if one mount 
command has backgrounded against a server, subsequent mount commands 
against the same server will just go right into the background.  But 
prev_bg_host is unique in each instance of the mount command.

Can you help me understand what you intended?  Do you have a test case?

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

Re: inconsistencies in nfs(5)

[rnews]

Chuck Lever <chuck.lever@oracle.com> wrote:
| This is still in utils/mount/nfsmount.c.

It is not in util-linux-ng-2.13-rc2 anymore, which is in Debian sid.

| I'm not sure how this can affect other mount commands running 
| concurrently on the same client.  The man page implies that if one mount 
| command has backgrounded against a server, subsequent mount commands 
| against the same server will just go right into the background.  But 
| prev_bg_host is unique in each instance of the mount command.
| 
| Can you help me understand what you intended?  Do you have a test case?

Phew, I wrote that 10 years ago! But I think that when you do a
"mount -atnfs", multiple mounts will be handled by the same mount
instance. The code helps when there are multiple NFS mounts from the
same host in fstab, and the server is down when you boot the client.

-- 
Dick Streefland                      ////                      Altium BV
dick.streefland@altium.nl           (@ @)          http://www.altium.com
--------------------------------oOO--(_)--OOo---------------------------


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

Re: inconsistencies in nfs(5)

[Chuck Lever]

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

rnews@tasking.nl wrote:
> Chuck Lever <chuck.lever@oracle.com> wrote:
> | This is still in utils/mount/nfsmount.c.
> 
> It is not in util-linux-ng-2.13-rc2 anymore, which is in Debian sid.
> 
> | I'm not sure how this can affect other mount commands running 
> | concurrently on the same client.  The man page implies that if one mount 
> | command has backgrounded against a server, subsequent mount commands 
> | against the same server will just go right into the background.  But 
> | prev_bg_host is unique in each instance of the mount command.
> | 
> | Can you help me understand what you intended?  Do you have a test case?
> 
> Phew, I wrote that 10 years ago! But I think that when you do a
> "mount -atnfs", multiple mounts will be handled by the same mount
> instance. The code helps when there are multiple NFS mounts from the
> same host in fstab, and the server is down when you boot the client.

OK, that makes sense.  I will try to clarify the sense of nfs(5) to 
reflect this 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

Re: inconsistencies in nfs(5)

[Chuck Lever]

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

rnews@tasking.nl wrote:
> Chuck Lever <chuck.lever@oracle.com> wrote:
> | This is still in utils/mount/nfsmount.c.
> 
> It is not in util-linux-ng-2.13-rc2 anymore, which is in Debian sid.
> 
> | I'm not sure how this can affect other mount commands running 
> | concurrently on the same client.  The man page implies that if one mount 
> | command has backgrounded against a server, subsequent mount commands 
> | against the same server will just go right into the background.  But 
> | prev_bg_host is unique in each instance of the mount command.
> | 
> | Can you help me understand what you intended?  Do you have a test case?
> 
> Phew, I wrote that 10 years ago! But I think that when you do a
> "mount -atnfs", multiple mounts will be handled by the same mount
> instance. The code helps when there are multiple NFS mounts from the
> same host in fstab, and the server is down when you boot the client.

OK, looking at this again...

I haven't actually tested this, but I think that "mount -a" will invoke 
the mount.nfs helper repeatedly for each individual NFS mount request. 
I don't see any support for a "-a" option in mount.nfs; it seems to be 
designed specifically for handling individual NFS mount requests, and 
not for "mount all items in /etc/fstab with this fstype."

Thus I don't think this feature you describe can work any more, and it 
argues perhaps for shortening the bg timeout in mount.nfs.  Comments?

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