Date: Sun, 11 May 2003 15:44:15 -0700 From: Kirk McKusick <mckusick@beastie.mckusick.com> To: Julian Elischer <julian@elischer.org> Cc: freebsd-current@freebsd.org Subject: Re: large ufs2 partitions and 'df' Message-ID: <200305112244.h4BMiFTh036221@beastie.mckusick.com> In-Reply-To: Your message of "Sun, 11 May 2003 15:11:59 PDT." <Pine.BSF.4.21.0305111502420.4662-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Sun, 11 May 2003 15:11:59 -0700 (PDT)
> From: Julian Elischer <julian@elischer.org>
> To: Kirk McKusick <mckusick@mckusick.com>
> cc: freebsd-current@freebsd.org
> Subject: Re: large ufs2 partitions and 'df'
> In-Reply-To: <200305112138.h4BLcVTh036013@beastie.mckusick.com>
> X-ASK-Info: Whitelist match
>
> On Sun, 11 May 2003, Kirk McKusick wrote:
>
> > 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?
>
> It would be a good idea except that there is only one spare long
> at the start of the structure.. its name is f_spare2 but it is only
> one long in length.
>
> I think that swithing 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?
Kirk McKusick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200305112244.h4BMiFTh036221>