From: Olaf Kirch <okir@suse.de>
To: nfs@lists.sourceforge.net
Subject: [PATCH] statfs fails with EOVERFLOW
Date: Tue, 23 Mar 2004 14:05:13 +0100 [thread overview]
Message-ID: <20040323130513.GB30984@suse.de> (raw)
[-- Attachment #1: Type: text/plain, Size: 1312 bytes --]
Hi,
I am currently dealing with a 2.6 bug report concerning statfs failing
with EOVERFLOW. This happens on very large NFS file systems, and the
problem is obviously that by default, we set s_blocksize to the wtmult
value advertised by the server. If tbytes / wtmult exceeds 31 bits, statfs
will fail with EOVERFLOW (on 2.4 it would silently produce crap values).
There are several ways to deal with this. One is to require the admin
to explicitly use the bsize NFS mount option - the obvious drawback is
that mount(8) doesn't support this option yet. I will submit a patch
for this shortly, but that doesn't really cure things, because you still
cannot put that into say ab autofs map distributed over NIS without
updating all clients.
So the proper fix IMO is for the client to perform an fstat call select
the proper bsize based on the tbytes value. This can be done either in
user space or in the kernel.
I'm attaching a patch that does this in the kernel; the 2.4 equivalent
of this patch has been in our kernel for more than 6 months now, without
known adverse effects.
If Trond thinks this is a bad idea, I'd as happily provide a patch that
does the same in mount(8).
Olaf
--
Olaf Kirch | Stop wasting entropy - start using predictable
okir@suse.de | tempfile names today!
---------------+
[-- Attachment #2: nfs-blocksize --]
[-- Type: text/plain, Size: 1538 bytes --]
--- linux-2.6.4/fs/nfs/inode.c.nocrash 2004-03-23 11:13:17.000000000 +0100
+++ linux-2.6.4/fs/nfs/inode.c 2004-03-23 11:28:18.000000000 +0100
@@ -279,12 +279,16 @@
struct nfs_server *server;
struct inode *root_inode = NULL;
struct nfs_fattr fattr;
+ int res;
struct nfs_fsinfo fsinfo = {
.fattr = &fattr,
};
struct nfs_pathconf pathinfo = {
.fattr = &fattr,
};
+ struct nfs_fsstat fsstat = {
+ .fattr = &fattr
+ };
/* We probably want something more informative here */
snprintf(sb->s_id, sizeof(sb->s_id), "%x:%x", MAJOR(sb->s_dev), MINOR(sb->s_dev));
@@ -293,6 +297,10 @@
sb->s_magic = NFS_SUPER_MAGIC;
+ res = server->rpc_ops->statfs(server, &server->fh, &fsstat);
+ if (res < 0)
+ return res;
+
root_inode = nfs_get_root(sb, &server->fh, &fsinfo);
/* Did getting the root inode fail? */
if (IS_ERR(root_inode))
@@ -319,6 +327,18 @@
} else
sb->s_blocksize = nfs_block_bits(fsinfo.wtmult,
&sb->s_blocksize_bits);
+#if BITS_PER_LONG != 64
+ /* Prevent statfs from reporting incorrect file system sizes.
+ * struct statfs holds the number of blocks in a long. A disk
+ * of 2.8 TB and a wtmult value of 512 will produce a block count
+ * that doesn't fit into 31 bits, causing statfs to fail with
+ * EOVERFLOW.
+ */
+ while ((fsstat.tbytes >> sb->s_blocksize_bits) >= 0x80000000ULL) {
+ sb->s_blocksize = nfs_block_bits(sb->s_blocksize * 2,
+ &sb->s_blocksize_bits);
+ }
+#endif
}
if (fsinfo.rtmax >= 512 && server->rsize > fsinfo.rtmax)
next reply other threads:[~2004-03-23 13:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-23 13:05 Olaf Kirch [this message]
2004-03-23 13:21 ` [PATCH] statfs fails with EOVERFLOW Christoph Hellwig
2004-03-23 13:30 ` Olaf Kirch
2004-03-23 13:36 ` Christoph Hellwig
2004-03-23 16:25 ` 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=20040323130513.GB30984@suse.de \
--to=okir@suse.de \
--cc=nfs@lists.sourceforge.net \
/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.