From owner-freebsd-current@FreeBSD.ORG Mon May 12 17:11:54 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 9F34637B401 for ; Mon, 12 May 2003 17:11:54 -0700 (PDT) Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DDA143FDF for ; Mon, 12 May 2003 17:11:54 -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 h4D0BlTh038399; Mon, 12 May 2003 17:11:47 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200305130011.h4D0BlTh038399@beastie.mckusick.com> To: Julian Elischer In-Reply-To: Your message of "Mon, 12 May 2003 14:40:55 PDT." Date: Mon, 12 May 2003 17:11:47 -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: Tue, 13 May 2003 00:11:54 -0000 > Date: Mon, 12 May 2003 14:40:55 -0700 (PDT) > From: Julian Elischer > To: Kirk McKusick > cc: freebsd-current@freebsd.org > Subject: Re: large ufs2 partitions and 'df' > X-ASK-Info: Whitelist match > > 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)? The fields at the top are the ones found in the Sun statfs structure versus the BSD ones following them. But there is no real need to do them in that order. Also Solaris have now done some renaming: f_bsize => f_frsize f_iosize => f_bsize So f_bsize which used to be the filesystem fragment size is now the filesystem block size (as it should have been in the first place, sigh). But, these name changes are likely too painful for us to make, so we should probably just stick with what we have. And Solaris has added: f_favail /* free inodes avail to non-superuser */ f_namemax /* maximum filename length */ and our f_fstypename was added but is called f_basetype. > Why are f_bfree and f_blocks signed? (and f_files and f_ffree > for that matter). They should be unsigned. > (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?) f_bavail is what Sun originally defined and still uses and what all the existing utilities (like df) expect and use. I see no good reason to go to the effort to change something to be incompatible. With all this discussion, I conclude that we should use the following. Note that I expanded the flags to 64-bits as we are nearly out and because I would have just had to pad up to a 64-bit boundary anyway. #define MFSNAMELEN 16 /* length of fs type name, including null */ #define MNAMELEN 80 /* size of on/from name bufs */ #define VERSION 0x20030101 /* current version number */ struct statfs { u_int_32 f_version; /* version number */ u_int_32 f_bsize; /* fundamental filesystem block size */ u_int_32 f_iosize; /* optimal transfer block size */ u_int_32 f_type; /* type of filesystem */ u_int_64 f_flags; /* copy of mount exported flags */ u_int_64 f_blocks; /* total data blocks in filesystem */ u_int_64 f_bfree; /* free blocks in filesystem */ int_64 f_bavail; /* free blocks avail to non-superuser */ u_int_64 f_files; /* total file nodes in filesystem */ u_int_64 f_ffree; /* free file nodes in filesystem */ int_64 f_favail; /* free nodes avail to non-superuser */ 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 */ char f_fstypename[MFSNAMELEN]; /* fs type name */ char f_mntfromname[MNAMELEN]; /* mounted filesystem */ char f_mntonname[MNAMELEN]; /* directory on which mounted */ }; Kirk McKusick