From owner-freebsd-current@FreeBSD.ORG Mon May 12 14:40:59 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 493B637B401 for ; Mon, 12 May 2003 14:40:59 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90F8243FAF for ; Mon, 12 May 2003 14:40:58 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by attbi.com (sccrmhc03) with ESMTP id <20030512214057003000n928e>; Mon, 12 May 2003 21:40:57 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA93835; Mon, 12 May 2003 14:40:56 -0700 (PDT) Date: Mon, 12 May 2003 14:40:55 -0700 (PDT) From: Julian Elischer To: Kirk McKusick In-Reply-To: <200305112244.h4BMiFTh036221@beastie.mckusick.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: Mon, 12 May 2003 21:40:59 -0000 On Sun, 11 May 2003, Kirk McKusick wrote: > So right you are. It would be possible to get the space by nibbling > a bit more space from MNAMELEN, but at some point we need to just bite > the bullet and define a new structure. I am leaning towards believing > that time is now. If we do define a new structure, I would like to > clean up the existing one a bit. I would propose this: > > #define MFSNAMELEN 16 /* length of fs type name, including null */ > #define MNAMELEN 80 /* size of on/from name bufs */ > struct statfs { > u_int_32 f_bsize; /* fundamental filesystem block size */ > u_int_32 f_iosize; /* optimal transfer block size */ > int_64 f_blocks; /* total data blocks in filesystem */ > int_64 f_bfree; /* free blocks in fs */ > int_64 f_bavail; /* free blocks avail to non-superuser */ > int_64 f_files; /* total file nodes in filesystem */ > int_64 f_ffree; /* free file nodes in fs */ > u_int_64 f_syncwrites; /* count of sync writes since mount */ > u_int_64 f_asyncwrites; /* count of async writes since mount */ > u_int_64 f_syncreads; /* count of sync reads since mount */ > u_int_64 f_asyncreads; /* count of async reads since mount */ > u_int_64 f_spare[10]; /* unused spare */ > fsid_t f_fsid; /* filesystem id */ > uid_t f_owner; /* user that mounted the filesystem */ > u_int_32 f_type; /* type of filesystem */ > u_int_32 f_flags; /* copy of mount exported flags */ > char f_fstypename[MFSNAMELEN]; /* fs type name */ > char f_mntfromname[MNAMELEN]; /* mounted filesystem */ > char f_mntonname[MNAMELEN]; /* directory on which mounted */ > }; > > It reorganizes things back into a rational order. It increases the > sizes of everything that might ever want to be 64-bits to that size, > and leaves plenty (10) of spares for future growth. Comments? Any reason the f_type and t_flags words are not nearer the top? (if not at the top)? Why are f_bfree and f_blocks signed? (and f_files and f_ffree for that matter). (I can see why f_bavail should be signed but might it be more useful to instead, keep a static 'reserved' value that you could subtract from f_bfree to get the 'user' value?) > > Kirk McKusick >