--UFHRwCdBEJvubb2X
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 30, 2004 at 06:32:36PM -0500, Christos Zoulas wrote:
>=20
> Hello,
>=20
> As we know our statfs needs to be modernized because we can only support
> fs's up to 2TB. Here's a proposed new structure:
>=20
> struct statvfs {
>         uint32_t  f_flags;              /* copy of mount exported flags */
>         uint32_t  f_bsize;              /* filesystem block size */
>         unit32_t  f_frsize;             /* filesystem fragment size */
>         uint32_t  f_iosize;             /* optimal transfer block size */=
=20
>   =20
>         uint64_t  f_blocks;             /* total data blocks in filesyste=
m */
>         uint64_t  f_bfree;              /* free blocks in filesystem */
>         int64_t   f_bavail;             /* free blocks avail to non-super=
user */
>   =20
>         uint64_t  f_files;              /* total file nodes in filesystem=
 */
>         uint64_t  f_ffree;              /* free nodes avail in filesystem=
 */
>         int64_t   f_favail;             /* free nodes avail to non-superu=
ser */
>=20
>         uint64_t  f_syncreads;          /* count of sync reads since moun=
t */
>         uint64_t  f_syncwrites;         /* count of sync writes since mou=
nt */
>         uint64_t  f_asyncreads;         /* count of async reads since mou=
nt */
>         uint64_t  f_asyncwrites;        /* count of async writes since mo=
unt */
>        =20
>         fsid_t    f_fsid;               /* filesystem id */
>         uint32_t  f_namemax;            /* maximum filename length */
>         uid_t     f_owner;              /* user that mounted the filesyst=
em */
>=20
>         char      f_fstypename[MFSNAMELEN]; /* filesystem type name */
>         char      f_mntfromname[MNAMELEN];  /* mounted filesystem */
>         char      f_mntonname[MNAMELEN];    /* directory on which mounted=
 */
> };    =20

Ok, looks like we're losing f_type, f_oflags, and we're gaining f_frsize,=
=20
f_avail, and the read stats.

> Issues [I supply my opinions...]
>=20
> 1. Q: what should be the old ones named __foostatfs20()?
>    A: I say yes since there is precedence of using the last OS version
>       supported them natively.

?? You mean the old structures or the old calls?

The old calls stay statfs() & such, their structure should be statfs16,=20
and you use a __RENAME() to map statfs to __statfs20(). The new calls=20
should be __statfs20().

Note: I think you should pull this change into 2.0. :-)

Note: the number for the call is the version where the call appeared, not=
=20
the last one to use it. Look at how stat() is handled in sys/stat.h.

> 2. Q: Should we go all the way and implement statvfs()?
>    A: I think so. statfs() is a berkeleism.

Don't forget fstatvfs() and fhstatvfs().

>    2a. Q: If we supply statvfs(), then do we still supply statfs too?
>        A: Not sure.

Yes.

>    2b. Q: X/Open says we should use unsigned long for bsize, frsize and
>           fsblkcnt_t for the rest. Should we do that?
>        A: I say keep the types as I have them.

If the standards say long and it isn't stupid, I'd say use "long".

>    2c. Q: bsize in statfs() has been the fragment size; bsize in statvfs()
> 	  is the block size, and frsize is the fragment size. Should we go
> 	  the statvfs() way.
>        A: I propose go that way too.

Ick. That's be redefining what bsize is. I'm not sure about it.

> 3. Q: I added more stats, favail [statvfs has it too], is there anything =
else
>       we need?
>    A: ???
> 4. Q: Should we change sys_getstatfs() to take size_t instead of long as
>       the second arg.
>    A: I think so.

No thoughts on those.

Take care,

Bill

--UFHRwCdBEJvubb2X
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFAaiihWz+3JHUci9cRAidHAJ4lsp0KEgWxKXY+fPTIHGowDAl2VwCfXJ6l
iTdnI0709ARd1bK2dhMBbfg=
=kItP
-----END PGP SIGNATURE-----

--UFHRwCdBEJvubb2X--