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: Text based mount options ignoring the preferred rwsize?
Date: Wed, 09 Sep 2009 22:47:06 +0100	[thread overview]
Message-ID: <4AA8225A.9060107@moving-picture.com> (raw)
In-Reply-To: <188B198A-A113-4CA7-940D-EFBD026CBDD2@oracle.com>

Chuck Lever wrote:
>>
>> Should the kernel be setting rsize (and wsize) to 0 by default?
> 
> 
> nfs(5) says:
> 
> "If an [rw]size value is not specified, or if the specified [rw]size  
> value is larger than the maximum that either client or server can  
> support, the client and server negotiate the largest [rw]size value  
> that they can both support."
> 
> So the text-based behavior is what is documented now.
> 
> Does anyone know of a reason to use the server's "preferred" transfer  
> size rather than the largest size supported by both client and  server?  
> Usually those are the same.

In this case, the manufacturer of the NFS server recommends using 128Kb 
for rsize and 512Kb for wsize - although the maximum rsize it supports 
is 512Kb. I assume in their testing, these values have given optimal 
performance figures.

The default behaviour with binary mount options when no [rw]size is to 
select these preferred values - which to me, makes sense - as by not 
giving a [rw]size, you are leaving it up the server to pick the 'best' 
values for you - which I guess in most (all other?) cases happen to be 
the maximum size.

James Pearson

  reply	other threads:[~2009-09-09 21:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-08 16:47 Text based mount options ignoring the preferred rwsize? James Pearson
     [not found] ` <4AA68AA4.7090606-5Ol4pYTxKWu0ML75eksnrtBPR1lH4CV8@public.gmane.org>
2009-09-09 19:23   ` Chuck Lever
2009-09-09 21:47     ` James Pearson [this message]
     [not found]       ` <4AA8225A.9060107-5Ol4pYTxKWu0ML75eksnrtBPR1lH4CV8@public.gmane.org>
2009-09-09 22:34         ` Chuck Lever
2009-09-09 22:56         ` Trond Myklebust
     [not found]           ` <1252536970.8722.110.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-09-10  9:08             ` James Pearson
     [not found]               ` <4AA8C215.2030002-5Ol4pYTxKWu0ML75eksnrtBPR1lH4CV8@public.gmane.org>
2009-09-10 17:49                 ` Chuck Lever

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=4AA8225A.9060107@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.