From asami@sunrise.cs.berkeley.edu  Sat Jan 13 02:06:47 1996
Received: from sunrise.cs.berkeley.edu (sunrise.CS.Berkeley.EDU [128.32.38.121])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA17287
          for <FreeBSD-gnats-submit@freebsd.org>; Sat, 13 Jan 1996 02:06:47 -0800 (PST)
Received: (from asami@localhost) by sunrise.cs.berkeley.edu (8.6.12/8.6.12) id CAA07932; Sat, 13 Jan 1996 02:08:43 -0800
Message-Id: <199601131008.CAA07932@sunrise.cs.berkeley.edu>
Date: Sat, 13 Jan 1996 02:08:43 -0800
From: asami@cs.berkeley.edu
To: FreeBSD-gnats-submit@freebsd.org
Cc: nisha@sunrise.cs.berkeley.edu
Subject: df gets confused by huge filesystems
X-Send-Pr-Version: 3.2

>Number:         943
>Category:       bin
>Synopsis:       df can't handle large filesystems
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Jan 13 02:10:01 PST 1996
>Closed-Date:    Sun Jan 14 10:55:50 PST 1996
>Last-Modified:  Sun Jan 14 10:57:41 PST 1996
>Originator:     Satoshi Asami
>Release:        FreeBSD 2.1-STABLE i386 (<== this is a lie, it's 2.1R)
>Organization:
University of California at Berkeley
>Environment:

	2.1R with a striped disk driver (ccd) taken from NetBSD (the
	kernel is modified, but I don't think that will make any
	difference to this problem).

>Description:

	df seems to get confused when there is too many blocks, e.g.:

>How-To-Repeat:

	Get yourself a disk array. :)

>Fix:
	
	If I knew, I'd commit it!

>Release-Note:
>Audit-Trail:

From: Bruce Evans <bde@zeta.org.au>
To: FreeBSD-gnats-submit@FreeBSD.ORG, asami@cs.berkeley.edu
Cc: nisha@sunrise.cs.berkeley.edu
Subject: Re: bin/943: df gets confused by huge filesystems
Date: Sun, 14 Jan 1996 09:54:47 +1100

 >	df seems to get confused when there is too many blocks, e.g.:
 
 >>How-To-Repeat:
 
 >	Get yourself a disk array. :)
 
 I just happened to have a rack of 32GB ones handy :-).  Actually, I
 built one using vnconfig.  It only took a bug fix for the vn driver
 and 190MB of metadata for `newfs -i 32768'.
 
 >>> df -k -t local
 >Filesystem  1K-blocks     Used    Avail Capacity  Mounted on
 >...
 >/dev/ccd0c   19801168   205004 -3462766    -6%    /mnt
 >                               ^^^^^^^^^^^^^^
 
 The freespace calculation is buggy.  ffs does a calculation involving
 (minfree * total_blocks) / 100, so with the standard minfree of 8%, ffs
 stops working at about 1TB/8 instead of at 1TB.  ffs_statfs() and df.c
 for some reason don't use the standard freespace() macro (df.c uses a
 clone of ffs_statfs() to avoid having to mount ffs file systems to
 report them).  They do a calculation involving
 ((100 - minfree) * total_blocks) / 100.  Apart from apparently having a
 rounding bug, this overflows at 1TB/92 with the standard minfree.  This
 is only a reporting bug.  You get negative available blocks for empty
 file systems of sizes between about 1GB and 22GB, and truncated block
 sizes between 22GB and 33GB...
 
 Bruce
State-Changed-From-To: open->closed 
State-Changed-By: bde 
State-Changed-When: Sun Jan 14 10:55:50 PST 1996 
State-Changed-Why:  
Fixed in rev.1.34 of sys/ufs/ffs/ffs_vfsops.c and rev.1.8 of 
bin/df/df.c. 
>Unformatted:
 >> df -k -t local
 Filesystem  1K-blocks     Used    Avail Capacity  Mounted on
 /dev/sd0a       32254    16670    13002    56%    /
 /dev/sd0e       15391     3071    11088    22%    /var
 /dev/sd0f      530207   276313   211477    57%    /usr
 /dev/ccd0c   19801168   205004 -3462766    -6%    /mnt
                                ^^^^^^^^^^^^^^
 
 	I took a look at the source but can't for the life of myself
 	can't figure out why it's only the "avail" and "capacity"
 	fields that get screwed up.  For instance, the "1K-blocks" field
 	is handled in an identical way!
 
