All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Pearson <james-p-5Ol4pYTxKWu0ML75eksnrtBPR1lH4CV8@public.gmane.org>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH] NFS: Revert default r/wsize behavior
Date: Fri, 11 Sep 2009 10:33:59 +0100	[thread overview]
Message-ID: <4AAA1987.6040202@moving-picture.com> (raw)
In-Reply-To: <20090910205950.3670.7878.stgit-RytpoXr2tKZ9HhUboXbp9zCvJB+x5qRC@public.gmane.org>

Chuck Lever wrote:
> When the "rsize=" or "wsize=" mount options are not specified,
> text-based mounts have slightly different behavior than legacy binary
> mounts.  Text-based mounts use the smaller of the server's maximum
> and the client's maximum, but binary mounts use the smaller of the
> server's _preferred_ size and the client's maximum.
> 
> This difference is actually pretty subtle.  Most servers advertise
> the same value as their largest and their preferred transfer size, so
> the end result is the same in most cases.
> 
> The reason for this difference is that for text-based mounts, if
> r/wsize are not specified, they are set to the largest value supported
> by the client.  For binary mounts, the values are set to zero if these
> options are not specified.
> 
> nfs_server_set_fsinfo() can negotiate the defaults correctly in any
> case.  There's no need to specify any particular value as default in
> the text-based option parsing logic.
> 
> Thanks to James Pearson <james-p-5Ol4pYTxKWu0ML75eksnrtBPR1lH4CV8@public.gmane.org> for reporting and
> diagnosing the problem.
> 
> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
> ---
> 
> James-
> 
> Is this what you want?
> 
>  fs/nfs/super.c |    4 ----
>  1 files changed, 0 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/nfs/super.c b/fs/nfs/super.c
> index bde444b..cf0d754 100644
> --- a/fs/nfs/super.c
> +++ b/fs/nfs/super.c
> @@ -1635,8 +1635,6 @@ static int nfs_validate_mount_data(void *options,
>  		goto out_no_data;
>  
>  	args->flags		= (NFS_MOUNT_VER3 | NFS_MOUNT_TCP);
> -	args->rsize		= NFS_MAX_FILE_IO_SIZE;
> -	args->wsize		= NFS_MAX_FILE_IO_SIZE;
>  	args->acregmin		= NFS_DEF_ACREGMIN;
>  	args->acregmax		= NFS_DEF_ACREGMAX;
>  	args->acdirmin		= NFS_DEF_ACDIRMIN;
> @@ -2351,8 +2349,6 @@ static int nfs4_validate_mount_data(void *options,
>  	if (data == NULL)
>  		goto out_no_data;
>  
> -	args->rsize		= NFS_MAX_FILE_IO_SIZE;
> -	args->wsize		= NFS_MAX_FILE_IO_SIZE;
>  	args->acregmin		= NFS_DEF_ACREGMIN;
>  	args->acregmax		= NFS_DEF_ACREGMAX;
>  	args->acdirmin		= NFS_DEF_ACDIRMIN;

That is what I've already done myself for the NFSv3 case - personally I 
would implicitly set args->[rw]size to zero (although args would have 
been initialled with kzalloc()), just to make it clear that the defaults 
are zero.

Thanks

James Pearson

      parent reply	other threads:[~2009-09-11  9:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-10 21:05 [PATCH] NFS: Revert default r/wsize behavior Chuck Lever
     [not found] ` <20090910205950.3670.7878.stgit-RytpoXr2tKZ9HhUboXbp9zCvJB+x5qRC@public.gmane.org>
2009-09-10 21:17   ` Trond Myklebust
     [not found]     ` <1252617432.8722.157.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-09-10 21:30       ` Chuck Lever
2009-09-30 15:14       ` James Pearson
2009-09-11  9:33   ` James Pearson [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=4AAA1987.6040202@moving-picture.com \
    --to=james-p-5ol4pytxkwu0ml75eksnrtbpr1lh4cv8@public.gmane.org \
    --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.