Re: Who needs these silly statfs changes...

On Fri, 14 Nov 2003, Peter Edwards wrote:

> Bernd Walter wrote:
>
> >On Thu, Nov 13, 2003 at 12:54:18AM -0800, Kris Kennaway wrote:
> >
> >
> >>On Thu, Nov 13, 2003 at 06:44:25PM +1100, Peter Jeremy wrote:
> >>
> >>
> >>>On Wed, Nov 12, 2003 at 06:04:00PM -0800, Kris Kennaway wrote:
> >>>
> >>>
> >>>>...my sparc machine reports that my i386 nfs server has 15 exabytes of
> >>>>free space!
> >>>>
> >>>>enigma# df -k
> >>>>Filesystem  1K-blocks     Used             Avail Capacity  Mounted on
> >>>>rot13:/mnt2  56595176 54032286 18014398507517260     0%    /rot13/mnt2
> >>>>
> >>>>
> >>>18014398507517260 = 2^54 - 1964724.  and 2^54KB == 2^64 bytes.  Is it
> >>>possible that rot13:/mnt2 has negative free space?  (ie it's into the
> >>>8-10% reserved area).
> >>>
> >>>
> >>Yes, that's precisely what it is..the bug is either in df or the
> >>kernel (I suspect the latter, i.e. something in the nfs code).
> >>
> >>
> >
> >And it's nothing new - I'm seeing this since several years now.
> >
> >
>
> The NFS protocols have unsigned fields where statfs has signed
> equivalents: NFS can't represent negative available disk space ( Without
> the knowledge of the underlying filesystem on the server, negative free
> space is a little nonsensical anyway, I suppose)
>
> The attached patch stops the NFS server assigning negative values to
> unsigned fields in the statfs response, and works against my local
> solaris box.  Seem reasonable?

The client attampts to fix this by pretending that the unsigned fields
are signed.  -current tries to do more to support file system sizes larger
that 1TB, but the code for this is not even wrong except it may be wrong
enough to break the negative values.  See my reply to one of the PRs
for more details.

I just got around to testing the patch in that reply:

%%%
Index: nfs_vfsops.c
===================================================================
RCS file: /home/ncvs/src/sys/nfsclient/nfs_vfsops.c,v
retrieving revision 1.143
diff -u -2 -r1.143 nfs_vfsops.c
--- nfs_vfsops.c	12 Nov 2003 02:54:46 -0000	1.143
+++ nfs_vfsops.c	12 Nov 2003 14:37:46 -0000
_at__at_ -223,5 +223,5 _at__at_
 	struct mbuf *mreq, *mrep, *md, *mb;
 	struct nfsnode *np;
-	u_quad_t tquad;
+	quad_t tquad;
 	int bsize;

_at__at_ -254,19 +254,19 _at__at_
 		for (bsize = NFS_FABLKSIZE; ; bsize *= 2) {
 			sbp->f_bsize = bsize;
-			tquad = fxdr_hyper(&sfp->sf_tbytes);
-			if (((long)(tquad / bsize) > LONG_MAX) ||
-			    ((long)(tquad / bsize) < LONG_MIN))
+			tquad = (quad_t)fxdr_hyper(&sfp->sf_tbytes) / bsize;
+			if (bsize <= INT_MAX / 2 &&
+			    (tquad > LONG_MAX || tquad < LONG_MIN))
 				continue;
-			sbp->f_blocks = tquad / bsize;
-			tquad = fxdr_hyper(&sfp->sf_fbytes);
-			if (((long)(tquad / bsize) > LONG_MAX) ||
-			    ((long)(tquad / bsize) < LONG_MIN))
+			sbp->f_blocks = tquad;
+			tquad = (quad_t)fxdr_hyper(&sfp->sf_fbytes) / bsize;
+			if (bsize <= INT_MAX / 2 &&
+			    (tquad > LONG_MAX || tquad < LONG_MIN))
 				continue;
-			sbp->f_bfree = tquad / bsize;
-			tquad = fxdr_hyper(&sfp->sf_abytes);
-			if (((long)(tquad / bsize) > LONG_MAX) ||
-			    ((long)(tquad / bsize) < LONG_MIN))
+			sbp->f_bfree = tquad;
+			tquad = (quad_t)fxdr_hyper(&sfp->sf_abytes) / bsize;
+			if (bsize <= INT_MAX / 2 &&
+			    (tquad > LONG_MAX || tquad < LONG_MIN))
 				continue;
-			sbp->f_bavail = tquad / bsize;
+			sbp->f_bavail = tquad;
 			sbp->f_files = (fxdr_unsigned(int32_t,
 			    sfp->sf_tfiles.nfsuquad[1]) & 0x7fffffff);
%%%

This seems to work.  On a 2TB-epsilon ffs1 file system (*) on an md malloc
disk (**):

server:
Filesystem 1K-blocks  Used      Avail Capacity  Mounted on
/dev/md0   2147416896    0 1975624000     0%    /b
client:
Filesystem 1024-blocks Used      Avail Capacity  Mounted on
besplex:/b  2147416896    0 1975624000     0%    /b

These are 1K-blocks so their count fits in an int32_t, but the count in
512-blocks is too large for an int32_t so the scaling must be helping.

With newfs -m 100 (***) to get near negative free space:

server:
Filesystem 1K-blocks  Used Avail Capacity  Mounted on
/dev/md0   2147416896    0  5696     0%    /b
client:
Filesystem 1K-blocks  Used Avail Capacity  Mounted on
besplex:/b  2147416896    0  5696     0%    /b

After using up all the free space by creating a 6MB file:

server:
Filesystem 1K-blocks  Used Avail Capacity  Mounted on
/dev/md0   2147416896 6208  -512   109%    /b
client:
Filesystem 1024-blocks Used Avail Capacity  Mounted on
besplex:/b  2147416896 6208  -512   109%    /b

(*) Overflow at 1TB in fs.h:fsbtodb() must be fixed for 2TB ffs1 file
systems to be safe to use.

(**) mdconfig and md have overflow bugs at 2^32 sectors but we only
need 2^31+epsilon sectors to test file system overflow bugs at 1TB.

(***) The off-by-1 error in newfs -m must be fixed for newfs -m 100
to work.

Bruce