From: Steve Dickson <SteveD@redhat.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH] nfs(5): Document remount behavior (take 3)
Date: Mon, 01 Nov 2010 08:12:00 -0400 [thread overview]
Message-ID: <4CCEAE90.70309@RedHat.com> (raw)
In-Reply-To: <20101029163746.5646.31637.stgit-RytpoXr2tKZ9HhUboXbp9zCvJB+x5qRC@public.gmane.org>
On 10/29/2010 12:40 PM, 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>
Committed...
steved.
> ---
>
> Take 3:
>
> o Actually commit the patch before trying to e-mail it
>
> o Remove all mention of /etc/mtab
>
> o Refocus umount discussion on umount requirements rather
> than remount behavior
>
> utils/mount/nfs.man | 54 ++++++++++++++++++++++++++++++++++++---------------
> 1 files changed, 38 insertions(+), 16 deletions(-)
>
> diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man
> index 1b86768..be91a25 100644
> --- a/utils/mount/nfs.man
> +++ b/utils/mount/nfs.man
> @@ -1523,32 +1523,54 @@ 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 mount points that use NFS versions 2 or 3, the NFS umount subcommand
> +depends on knowing the original set of mount options used to perform the
> +MNT operation.
> +These options are stored on disk by the NFS mount subcommand,
> +and can be erased by a remount.
> .P
> +To ensure that the saved mount options are not erased during a remount,
> +specify either the local mount directory, or the server hostname and
> +export pathname, but not both, during a remount. 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 saved on disk for the NFS server mounted at /mnt.
> +.SH FILES
> +.TP 1.5i
> +.I /etc/fstab
> +file system table
> +.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
>
prev parent reply other threads:[~2010-11-01 12:12 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-29 16:40 [PATCH] nfs(5): Document remount behavior (take 3) Chuck Lever
[not found] ` <20101029163746.5646.31637.stgit-RytpoXr2tKZ9HhUboXbp9zCvJB+x5qRC@public.gmane.org>
2010-11-01 12:12 ` Steve Dickson [this message]
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=4CCEAE90.70309@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.