From owner-freebsd-current@FreeBSD.ORG Fri Nov 14 11:46:51 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 162A516A4CE for ; Fri, 14 Nov 2003 11:46:51 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F18A43F93 for ; Fri, 14 Nov 2003 11:46:49 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id GAA29103; Sat, 15 Nov 2003 06:46:27 +1100 Date: Sat, 15 Nov 2003 06:46:26 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Peter Edwards In-Reply-To: <3FB4E8A1.6090402@openet-telecom.com> Message-ID: <20031115054126.B9400@gamplex.bde.org> References: <20031113020400.GA44619@xor.obsecurity.org> <20031113085418.GA47995@xor.obsecurity.org> <3FB4E8A1.6090402@openet-telecom.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Peter Jeremy cc: Kris Kennaway cc: ticso@cicely.de cc: current@freebsd.org Subject: Re: Who needs these silly statfs changes... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2003 19:46:51 -0000 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 @@ -223,5 +223,5 @@ struct mbuf *mreq, *mrep, *md, *mb; struct nfsnode *np; - u_quad_t tquad; + quad_t tquad; int bsize; @@ -254,19 +254,19 @@ 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