inconsistencies in nfs(5)
Subsystems (2)
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...
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
-------------------------------------------------------------------------
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Chuck Lever <[email protected]> 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.
Signature · 13 lines
Dick Streefland //// Altium BV [email protected] (@ @) 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 - [email protected] https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 18 lines · [email protected] wrote:
Chuck Lever <[email protected]> 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:(quoted diff) +11
-0+ /* + * 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; + }
Quoted 2 lines
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?
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
-------------------------------------------------------------------------
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Chuck Lever <[email protected]> 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.
Signature · 13 lines
Dick Streefland //// Altium BV [email protected] (@ @) 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 - [email protected] https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 5 lines · [email protected] wrote:
Chuck Lever <[email protected]> wrote:
| This is still inutils/mount/nfsmount.c.It is not in util-linux-ng-2.13-rc2 anymore, which is in Debian sid.
Quoted 7 lines
| 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.
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
-------------------------------------------------------------------------
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 5 lines · [email protected] wrote:
Chuck Lever <[email protected]> wrote:
| This is still inutils/mount/nfsmount.c.It is not in util-linux-ng-2.13-rc2 anymore, which is in Debian sid.
Quoted 7 lines
| 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?
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
-------------------------------------------------------------------------
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs