public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <Trond.Myklebust@netapp.com>
To: chucklever@gmail.com
Cc: Carsten Aulbert
	<carsten.aulbert-l1a6w7hxd2yELgA04lAiVw@public.gmane.org>,
	linux-nfs@vger.kernel.org,
	Henning Fehrmann
	<henning.fehrmann-l1a6w7hxd2yELgA04lAiVw@public.gmane.org>,
	Steffen Grunewald
	<steffen.grunewald-l1a6w7hxd2yELgA04lAiVw@public.gmane.org>
Subject: Re: Massive NFS problems on large cluster with large number of mounts
Date: Fri, 15 Aug 2008 17:04:12 -0400	[thread overview]
Message-ID: <1218834252.7037.31.camel@localhost> (raw)
In-Reply-To: <1218833230.7037.29.camel@localhost>

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

On Fri, 2008-08-15 at 16:47 -0400, Trond Myklebust wrote:
> On Fri, 2008-08-15 at 16:34 -0400, Chuck Lever wrote:
> > Trond, NFS_MOUNT_FLAGMASK is used in nfs_init_server() and
> > nfs4_init_server() for both legacy binary and text-based mounts.  This
> > needs to be moved to a legacy-only path if we want to use the
> > high-order 16 bits in the 'flags' field for text-based mounts.
> 
> We definitely want to do this. The point of introducing text-based
> mounts was to allow us to add functionality without having to worry
> about legacy binary mount formats. The mask should be there in order to
> ensure that binary formats don't start enabling features that they
> cannot support. There is no justification for applying it to the text
> mount path.

I've attached the patch...

Cheers
  Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

[-- Attachment #2: linux-2.6.27-005-dont_apply_nfs_mount_flagmask_to_text_mounts.dif --]
[-- Type: message/rfc822, Size: 1938 bytes --]

From: Trond Myklebust <Trond.Myklebust@netapp.com>
Subject: No Subject
Date: Fri, 15 Aug 2008 16:59:14 -0400
Message-ID: <1218834252.7037.32.camel@localhost>

The point of introducing text-based mounts was to allow us to add
functionality without having to worry about legacy binary mount formats.
The mask should be there in order to ensure that binary formats don't start
enabling features that they cannot support. There is no justification for
applying it to the text mount path.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
---

 fs/nfs/client.c |    4 ++--
 fs/nfs/super.c  |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/nfs/client.c b/fs/nfs/client.c
index 2accb67..7547600 100644
--- a/fs/nfs/client.c
+++ b/fs/nfs/client.c
@@ -675,7 +675,7 @@ static int nfs_init_server(struct nfs_server *server,
 	server->nfs_client = clp;
 
 	/* Initialise the client representation from the mount data */
-	server->flags = data->flags & NFS_MOUNT_FLAGMASK;
+	server->flags = data->flags;
 
 	if (data->rsize)
 		server->rsize = nfs_block_size(data->rsize, NULL);
@@ -1072,7 +1072,7 @@ static int nfs4_init_server(struct nfs_server *server,
 		goto error;
 
 	/* Initialise the client representation from the mount data */
-	server->flags = data->flags & NFS_MOUNT_FLAGMASK;
+	server->flags = data->flags;
 	server->caps |= NFS_CAP_ATOMIC_OPEN;
 
 	if (data->rsize)
diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index f67d44c..5725af9 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -1544,7 +1544,7 @@ static int nfs_validate_mount_data(void *options,
 		 * Translate to nfs_parsed_mount_data, which nfs_fill_super
 		 * can deal with.
 		 */
-		args->flags		= data->flags;
+		args->flags		= data->flags & NFS_MOUNT_FLAGMASK;
 		args->rsize		= data->rsize;
 		args->wsize		= data->wsize;
 		args->timeo		= data->timeo;

  reply	other threads:[~2008-08-15 21:04 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-01  8:19 Massive NFS problems on large cluster with large number of mounts Carsten Aulbert
     [not found] ` <4869E8AB.4060905-l1a6w7hxd2yELgA04lAiVw@public.gmane.org>
2008-07-01 18:22   ` J. Bruce Fields
2008-07-01 18:26     ` J. Bruce Fields
2008-07-02 14:00     ` Carsten Aulbert
     [not found]       ` <486B89F5.9000109-l1a6w7hxd2yELgA04lAiVw@public.gmane.org>
2008-07-02 20:31         ` J. Bruce Fields
2008-07-02 21:04           ` Trond Myklebust
2008-07-02 21:08             ` J. Bruce Fields
2008-07-03  5:31             ` Carsten Aulbert
     [not found]               ` <486C642B.3020100-l1a6w7hxd2yELgA04lAiVw@public.gmane.org>
2008-07-03 12:35                 ` Carsten Aulbert
2008-07-16  9:49             ` Carsten Aulbert
     [not found]               ` <487DC43F.8040408-l1a6w7hxd2yELgA04lAiVw@public.gmane.org>
2008-07-16 19:06                 ` J. Bruce Fields
2008-07-17  5:53                   ` Carsten Aulbert
     [not found]                     ` <487EDE57.4070100-l1a6w7hxd2yELgA04lAiVw@public.gmane.org>
2008-07-17 14:27                       ` J. Bruce Fields
2008-07-17 14:47                   ` Chuck Lever
     [not found]                     ` <76bd70e30807170747r31af3280icf0bd3fdbde17bac-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-17 14:48                       ` J. Bruce Fields
2008-07-17 15:11                         ` Chuck Lever
     [not found]                           ` <76bd70e30807170811s78175c0ep3a52da7c0ef95fc6-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-28 20:55                             ` Chuck Lever
     [not found]                               ` <76bd70e30807281355t4890a9b2q6960d79552538f60-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-29 11:32                                 ` Jeff Layton
     [not found]                                   ` <20080729073203.546a4269-RtJpwOs3+0O+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2008-07-29 17:43                                     ` Mike Mackovitch
2008-07-30 17:53                                 ` J. Bruce Fields
2008-07-30 19:33                                   ` Chuck Lever
     [not found]                                     ` <76bd70e30807301233t73f92775tbdeb3f8efbb34a4f-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-30 22:01                                       ` Chuck Lever
     [not found]                                         ` <76bd70e30807301501p5c0ba3c6i38fee02a1e606e31-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-08-15 20:34                                           ` Chuck Lever
     [not found]                                             ` <76bd70e30808151334i19822280j67a08b92b17582ba-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-08-15 20:47                                               ` Trond Myklebust
2008-08-15 21:04                                                 ` Trond Myklebust [this message]
2008-08-15 21:39                                                   ` Chuck Lever
2008-07-30 22:13                                       ` J. Bruce Fields
2008-07-31 16:35                                         ` Chuck Lever
2008-07-17 15:35                       ` Trond Myklebust

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=1218834252.7037.31.camel@localhost \
    --to=trond.myklebust@netapp.com \
    --cc=carsten.aulbert-l1a6w7hxd2yELgA04lAiVw@public.gmane.org \
    --cc=chucklever@gmail.com \
    --cc=henning.fehrmann-l1a6w7hxd2yELgA04lAiVw@public.gmane.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=steffen.grunewald-l1a6w7hxd2yELgA04lAiVw@public.gmane.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