statfs fails with EOVERFLOW

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
[email protected]   |  tempfile names today!
---------------+ 

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

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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

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
[email protected]   |  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  -  [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

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

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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

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

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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs