From: Frank Cusack <fcusack@fcusack.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>, torvalds@osdl.org
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: effect of nfs blocksize on I/O ?
Date: Sun, 28 Sep 2003 23:42:36 -0700 [thread overview]
Message-ID: <20030928234236.A16924@google.com> (raw)
I am not talking about rsize/wsize, rather the fs blocksize.
2.4 sets this to MIN(MAX(MAX(4096,rsize),wsize),32768) = 8192 typically.
2.6 sets this to nfs_fsinfo.wtmult?nfs_fsinfo.wtmult:512 = 512 typically.
(My estimation of "typical" may be way off though.)
At a 512 byte blocksize, this overflows struct statfs for fs > 1TB.
Most of my NFS filesystems (on netapp) are larger than that.
But more importantly, what does the VFS *do* with the blocksize?
strace seems to show that glibc/stdio does consider it. If I fprintf()
two 4096 byte strings, libc does a single write() with 8192 blocksize,
and 3 write()'s for 512 blocksize. I haven't looked to see what goes
over the wire, but I assume that still follows rsize/wsize.
Does any NFS server report wtmult?
Here's a patch.
/fc
--- a/fs/nfs/inode.c 2003-09-28 23:41:13.000000000 -0700
+++ b/fs/nfs/inode.c 2003-09-28 23:40:18.000000000 -0700
@@ -323,8 +323,8 @@
server->wsize = nfs_block_size(fsinfo.wtpref, NULL);
if (sb->s_blocksize == 0) {
if (fsinfo.wtmult == 0) {
- sb->s_blocksize = 512;
- sb->s_blocksize_bits = 9;
+ sb->s_blocksize = nfs_block_bits(server->rsize > server->wsize ? server->rsize : server->wsize,
+ &sb->s_blocksize_bits);
} else
sb->s_blocksize = nfs_block_bits(fsinfo.wtmult,
&sb->s_blocksize_bits);
next reply other threads:[~2003-09-29 6:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-29 6:42 Frank Cusack [this message]
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
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=20030928234236.A16924@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®