From: Frank Cusack <fcusack@fcusack.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: torvalds@osdl.org, lkml <linux-kernel@vger.kernel.org>
Subject: Re: effect of nfs blocksize on I/O ?
Date: Mon, 29 Sep 2003 22:23:45 -0700 [thread overview]
Message-ID: <20030929222345.A3043@google.com> (raw)
In-Reply-To: <16247.60679.415937.295532@charged.uio.no>; from trond.myklebust@fys.uio.no on Mon, Sep 29, 2003 at 01:27:51AM -0700
On Mon, Sep 29, 2003 at 01:27:51AM -0700, Trond Myklebust wrote:
> >>>>> " " == Frank Cusack <fcusack@fcusack.com> writes:
>
> >> OTOH, bsize is of informational interest to programs that wish
> >> to optimize I/O throughput by grouping their data into
> >> appropriately sized records.
>
> > So then isn't the optimal record size 8192 for r/wsize=8192?
> > Since the data is going to be grouped into 8192-byte reads and
> > writes over the wire, shouldn't bsize match that? Why should I
> > make 16x 512-byte write() syscalls (if "optimal" I/O size is
> > bsize=512) instead of 1x 8192-byte syscall?
>
> Yes. It is already on my list of bugs.
>
> We basically need to feed 'wtpref' (a.k.a. 'wsize') into the f_bsize,
> and 'wtmult' into f_frsize.
Then it sounds like the current wtmult/512 value for f_bsize is a bug.
Until such time as you get f_frsize going, just directly plugging
wsize into s_blocksize seems like a win. Doesn't it? At least, I don't
see the advantage of using wtmult. (but could easily be missing it!)
> OTOH, the s_blocksize (and inode->i_blkbits) might well want to stay
> with wtmult.
ISTM that f_frsize is pretty useless for NFS. Even if the server gives
you this value (as wtmult), what use besides conversion of tbytes/abytes
values does it have?
If you like, I can supply such a patch.
- s_blocksize, either
. leave it as is (wtmult?wtmult:512)
. set to wsize (ie, my first patch in this thread)
- statfs, both
. report wtpref as f_bsize (already done if s_blocksize = wsize)
. report (wtmult?wtmult:wtpref) as f_frsize
I think the second s_blocksize option is better because not only statfs()
but also stat() will use this value without any additional work.
/fc
next prev parent reply other threads:[~2003-09-30 5:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-29 6:42 effect of nfs blocksize on I/O ? Frank Cusack
2003-09-29 7:19 ` Trond Myklebust
2003-09-29 7:52 ` Frank Cusack
2003-09-29 8:27 ` Trond Myklebust
2003-09-30 5:23 ` Frank Cusack [this message]
2003-09-30 6:04 ` 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=20030929222345.A3043@google.com \
--to=fcusack@fcusack.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
--cc=trond.myklebust@fys.uio.no \
/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.