From owner-freebsd-current@FreeBSD.ORG Sun May 11 14:38:35 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 941D637B401 for ; Sun, 11 May 2003 14:38:35 -0700 (PDT) Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE47843FB1 for ; Sun, 11 May 2003 14:38:34 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.12.8/8.12.3) with ESMTP id h4BLcVTh036013; Sun, 11 May 2003 14:38:32 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200305112138.h4BLcVTh036013@beastie.mckusick.com> To: Julian Elischer In-Reply-To: Your message of "Wed, 07 May 2003 15:44:45 PDT." Date: Sun, 11 May 2003 14:38:31 -0700 From: Kirk McKusick cc: freebsd-current@freebsd.org Subject: Re: large ufs2 partitions and 'df' 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: Sun, 11 May 2003 21:38:35 -0000 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 To: Kirk McKusick cc: freebsd-current@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?