All of lore.kernel.org
 help / color / mirror / Atom feed
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)

             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.