Re: large ufs2 partitions and 'df'

I think that we should use merge the two spares at the start of the
structure into a 64-bit f_bfree field. Rename the existing f_bfree
to f_old_bfree and set it to the same value as f_bfree if it will fit,
otherwise the largest number that will fit (ox7fffffff). Similarly,
take the two spare longs at the end and merge them into a 64-bit
b_avail field. Rename f_bavail to f_old_bavail and set as with
f_old_bfree. Those are the only two fields that need to grow, and
this will provide binary compatibility for existing applications.
Seem reasonable?

	Kirk McKusick

=-=-=-=-=

Date: Wed, 7 May 2003 15:44:45 -0700 (PDT)
From: Julian Elischer <julian_at_elischer.org>
To: Kirk McKusick <mckusick_at_mckusick.com>
cc: freebsd-current_at_freebsd.org
Subject: large ufs2 partitions and 'df'
X-ASK-Info: Whitelist match

Kirk, with the advent of UFS2 filesystems > 2TB 
what do you think we need to do about the statfs structure in mount.h?

struct statfs {
	long    f_spare2;         /* placeholder */
	long    f_bsize;          /* fundamental filesystem block size */
	long    f_iosize;         /* optimal transfer block size */  
	long    f_blocks;         /* total data blocks in filesystem */
	long    f_bfree;          /* free blocks in fs */
[...]

note:
biggie# df
Filesystem  1K-blocks       Used      Avail Capacity  Mounted on
/dev/da1s1a      128990    72192      46480    61%    /
devfs                 1        1          0   100%    /dev
/dev/da1s1f      257998      254     237106     0%    /tmp
[...]
procfs                4        4          0   100%    /proc
/dev/da2p1  -2125157230 71722434 1924502828     4%    /junk
biggie# dumpfs /dev/da2p1 |more
magic   19540119 (UFS2) time    Tue May  6 17:48:43 2003
superblock location     65536   id      [ 3eb83524 bb0b0d56 ]
ncg     11906   size    1120146927      blocks  1084905033
bsize   16384   shift   14      mask    0xffffc000
fsize   2048    shift   11      mask    0xfffff800
frag    8       shift   3       fsbtodb 2
minfree 8%      optim   time    symlinklen 120
maxbsize 16384  maxbpg  2048    maxcontig 8     contigsumsize 8
nbfree  131130475       ndir    1       nifree  280410108       nffree
16
bpg     11761   fpg     94088   ipg     23552
nindir  2048    inopb   64      maxfilesize     140806241583103
sbsize  2048    cgsize  16384   csaddr  3000    cssize  192512
sblkno  40      cblkno  48      iblkno  56      dblkno  3000
cgrotor 2188    fmod    0       ronly   0       clean   0
flags   none
fsmnt   /junk
volname         swuid   0


In this case it is purely a printing error in sf I think, as the number
of free frags is 2^30.
but that will probably overflow on the next version of this box.
(at least become -ve)

Should we define a new entrypoint for fstat() and what should the old
entrypoint return for partitions that are > 2^32 frags in size?