[PATCH] statfs fails with EOVERFLOW

[PATCH] statfs fails with EOVERFLOW

[Olaf Kirch]

[-- 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)

Re: [PATCH] statfs fails with EOVERFLOW

[Christoph Hellwig]

On Tue, Mar 23, 2004 at 02:05:13PM +0100, Olaf Kirch wrote:
> 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).

that's why we have statfs64 in 2.6, a program with the right LFS magic
and a recentish glibc should use if for you.



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [PATCH] statfs fails with EOVERFLOW

[Olaf Kirch]

On Tue, Mar 23, 2004 at 01:21:27PM +0000, Christoph Hellwig wrote:
> On Tue, Mar 23, 2004 at 02:05:13PM +0100, Olaf Kirch wrote:
> > 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).
> 
> that's why we have statfs64 in 2.6, a program with the right LFS magic
> and a recentish glibc should use if for you.

The glibc maintainers at suse tell me it's broken at the moment.

Second, not all apps can easily be converted to LFS support. One of the
apps that barfed was OpenOffice... be my guest and make it LFS clean :)

And finally, I think it's really an NFS bug. A local statfs on the file
system on the server works fine; it's just that the NFS client barfs
because it uses wtmult as the block size (and if it's a v2 mount, things
are even worse because it picks a totally arbitrary wtmult value of 512).

Olaf
-- 
Olaf Kirch     |  Stop wasting entropy - start using predictable
okir@suse.de   |  tempfile names today!
---------------+ 


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [PATCH] statfs fails with EOVERFLOW

[Christoph Hellwig]

On Tue, Mar 23, 2004 at 02:30:19PM +0100, Olaf Kirch wrote:
> > that's why we have statfs64 in 2.6, a program with the right LFS magic
> > and a recentish glibc should use if for you.
> 
> The glibc maintainers at suse tell me it's broken at the moment.
> 
> Second, not all apps can easily be converted to LFS support. One of the
> apps that barfed was OpenOffice... be my guest and make it LFS clean :)

OpenOffice is hopeless, it's one of this "if it's finally unmaintainable,
opensource it" things :)

> And finally, I think it's really an NFS bug. A local statfs on the file
> system on the server works fine; it's just that the NFS client barfs
> because it uses wtmult as the block size (and if it's a v2 mount, things
> are even worse because it picks a totally arbitrary wtmult value of 512).

Hmm.  Why do you limit the sb_blocksize changes to 32bit architectures then?
I see it doesn't trip easily for 64bit arches, but having different values
for exactly the same filesystem and mount options sounds like a rather bad
idea to me.



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [PATCH] statfs fails with EOVERFLOW

[Trond Myklebust]

P=E5 ty , 23/03/2004 klokka 08:05, skreiv Olaf Kirch:

> 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.

This will tend to fail if you are using strong authentication on NFSv3.
The only NFSv3 call you can rely upon to succeed at mount time is
fsinfo().

Cheers,
  Trond


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs