From owner-freebsd-current@FreeBSD.ORG Sun May 11 21:04:27 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 F1C1A37B401 for ; Sun, 11 May 2003 21:04:26 -0700 (PDT) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E75643F3F for ; Sun, 11 May 2003 21:04:26 -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 (rwcrmhc53) with ESMTP id <2003051204042505300j1qlve>; Mon, 12 May 2003 04:04:26 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id VAA86799; Sun, 11 May 2003 21:04:24 -0700 (PDT) Date: Sun, 11 May 2003 21:04:23 -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 04:04:27 -0000 On Sun, 11 May 2003, Kirk McKusick wrote: > > > > I think that switching to a new syscall with a fixed structure > > and using the rules you mention above to populate the structure in an > > ostatfs call might be the best answer. > > Old binaries probably only need to know that there is > X blocks free > > and not necessarily the correct number. > > New binaries can use the new syscall. > > 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? Before we go all gung hoon this, is this structure described in any standard? (posix?) > > Kirk McKusick >