From: Steve Dickson <SteveD@redhat.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH 6/6] nfs(5): Document remount behavior
Date: Thu, 28 Oct 2010 14:02:16 -0400 [thread overview]
Message-ID: <4CC9BAA8.5000509@RedHat.com> (raw)
In-Reply-To: <20101026155847.19184.44036.stgit@matisse.1015granger.net>
Chuck,
I'm a bit concern about this patch....
I'm asking myself who is going care how remounts update
/etc/mtab and what mode is used. I just thinking that type of info
adds a lot verbiage that nobody really care about. Plus why are
we documenting something (/etc/mtab) that will be going
away as soon as humanly possible?
Basically I'm saying the entire "Unmounting after a remount"
section is not needed. Only the 3 paragraphs in "THE REMOUNT OPTION"
section are needed IMHO...
I'm also thinking we need to add the/etc/nfsmount.conf FILES section,
but I guess I can do that later...
steved.
On 10/26/2010 11:58 AM, Chuck Lever wrote:
> It appears that, for a long while, NFS "remount" mounts have
> completely wiped the existing mount options in /etc/mtab for a given
> mount point. This is a problem for umount.nfs, since it reads its
> options out of /etc/mtab to find out how to do the unmount.
>
> The mount(8) command provides the NFS mount subcommand with the mount
> options to perform the remount. There are four cases to consider:
>
> 1. Both the device and mount directory are specified on the
> command line, and the target mount point is in /etc/fstab
>
> 2. Only one of the device and mount directory is specified on
> the command line, and the target mount point is in
> /etc/fstab
>
> 3. Both the device and mount directory are specified on the
> command line, and the target mount point is not in /etc/fstab
>
> 4. Only one of the device and mount directory is specified on
> the command line, and the target mount point is not in
> /etc/fstab
>
> Currently only case 4 works correctly. In that case, mount(8)
> provides the correct set of mount options to the mount.nfs
> subcommand and it can update /etc/mtab correctly.
>
> Cases 1 and 3 replace all mount options in /etc/mtab with the options
> provided on the command line during a remount. Case 2 replaces the
> mount options in /etc/mtab with a mix of options from /etc/fstab and
> /etc/mtab.
>
> Cases 1 and 3 are historical behavior. Basically this is a formal
> interface to allow administrators to replace the mount options in
> /etc/mtab completely, instead of merging in new ones. The present
> patch documents that behavior in nfs(5), and provides best practice
> for remounting NFS mount points.
>
> There are near-term plans to address case 2 by fixing mount(8)
> (provided by utils-linux-ng in most distributions).
>
> This is a partial fix for:
>
> https://bugzilla.linux-nfs.org/show_bug.cgi?id=188
>
> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
> ---
>
> utils/mount/nfs.man | 92 ++++++++++++++++++++++++++++++++++++++++++---------
> 1 files changed, 76 insertions(+), 16 deletions(-)
>
> diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man
> index 1b86768..a357000 100644
> --- a/utils/mount/nfs.man
> +++ b/utils/mount/nfs.man
> @@ -1523,32 +1523,92 @@ of Access Control Lists that are semantically richer than POSIX ACLs.
> NFS version 4 ACLs are not fully compatible with POSIX ACLs; as such,
> some translation between the two is required
> in an environment that mixes POSIX ACLs and NFS version 4.
> -.SH FILES
> -.TP 1.5i
> -.I /etc/fstab
> -file system table
> -.SH BUGS
> -The generic
> -.B remount
> -option is not fully supported.
> -Generic options, such as
> -.BR rw " and " ro
> -can be modified using the
> -.B remount
> -option,
> -but NFS-specific options are not all supported.
> +.SH "THE REMOUNT OPTION"
> +Generic mount options such as
> +.BR rw " and " sync
> +can be modified on NFS mount points using the
> +.BR remount
> +option.
> +See
> +.BR mount (8)
> +for more information on generic mount options.
> +.P
> +With few exceptions, NFS-specific options
> +are not able to be modified during a remount.
> The underlying transport or NFS version
> cannot be changed by a remount, for example.
> +.P
> Performing a remount on an NFS file system mounted with the
> .B noac
> option may have unintended consequences.
> The
> .B noac
> -option is a mixture of a generic option,
> +option is a combination of the generic option
> .BR sync ,
> -and an NFS-specific option
> +and the NFS-specific option
> .BR actimeo=0 .
> +.SS "Unmounting after a remount"
> +For NFS versions 2 and 3, the NFS umount subcommand
> +depends on
> +.I /etc/mtab
> +to contain the mount options needed to send an UMNT request
> +to the server.
> +The NFS mount subcommand stores these mount options in
> +.I /etc/mtab
> +after a successful mount operation is complete.
> +A remount can alter these stored mount options, however.
> .P
> +When it comes to what is written back to
> +.I /etc/mtab
> +during a remount, the
> +.BR mount (8)
> +command has two different modes of operation.
> +One mode
> +.I merges
> +the command line mount options with the mount
> +options already in
> +.IR /etc/mtab ,
> +and the other
> +.I replaces
> +the mount options in
> +.I /etc/mtab
> +with the command line mount options.
> +.P
> +To
> +.I replace
> +the mount options that are in
> +.IR /etc/mtab ,
> +specify both the server hostname and export path, and the
> +local mount directory during a remount.
> +To
> +.I merge
> +the mount options on the command line with
> +the options already in
> +.IR /etc/mtab ,
> +specify either the local mount directory, or the server
> +hostname and export pathname, but not both. For example,
> +.P
> +.NF
> +.TA 2.5i
> + mount -o remount,ro /mnt
> +.FI
> +.P
> +merges the mount option
> +.B ro
> +with the mount options already in
> +.I /etc/mtab
> +for the NFS server mounted at /mnt.
> +Merging is almost always the desired outcome, as it preserves the
> +ability of the client to contact the server when it comes time
> +to send an UMNT request.
> +.SH FILES
> +.TP 1.5i
> +.I /etc/fstab
> +file system table
> +.TP 1.5i
> +.I /etc/mtab
> +table of mounted file systems
> +.SH BUGS
> Before 2.4.7, the Linux NFS client did not support NFS over TCP.
> .P
> Before 2.4.20, the Linux NFS client used a heuristic
>
next prev parent reply other threads:[~2010-10-28 18:02 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-26 15:57 [PATCH 0/6] More fix-ups for nfs-utils-1.2.4 Chuck Lever
2010-10-26 15:57 ` [PATCH 1/6] nfs-utils: Remove all uses of AI_ADDRCONFIG Chuck Lever
2010-10-26 15:58 ` [PATCH 2/6] mount: Fix compiler warning in nfs_parse_retry_option() Chuck Lever
2010-10-26 15:58 ` [PATCH 3/6] mount.nfs: Fix memory leak in nfs_sys_mount() Chuck Lever
2010-10-26 15:58 ` [PATCH 4/6] mount.nfs: mnt_freq and mnt_pass are always zero Chuck Lever
2010-10-26 15:58 ` [PATCH 5/6] nfs(5): Grammar and style fixes Chuck Lever
2010-10-26 15:58 ` [PATCH 6/6] nfs(5): Document remount behavior Chuck Lever
2010-10-28 18:02 ` Steve Dickson [this message]
2010-10-28 18:58 ` Chuck Lever
2010-10-28 19:55 ` Steve Dickson
[not found] ` <20101026155216.19184.36979.stgit-RytpoXr2tKZ9HhUboXbp9zCvJB+x5qRC@public.gmane.org>
2010-10-28 15:32 ` [PATCH 0/6] More fix-ups for nfs-utils-1.2.4 Steve Dickson
[not found] ` <4CC997A8.6060803-AfCzQyP5zfLQT0dZR+AlfA@public.gmane.org>
2010-10-28 15:39 ` Chuck Lever
2010-11-01 12:13 ` Steve Dickson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CC9BAA8.5000509@RedHat.com \
--to=steved@redhat.com \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).