On Tue, Mar 30, 2004 at 06:32:36PM -0500, Christos Zoulas wrote:
> 
> Hello,
> 
> 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:
> 
> 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 */ 
>    
>         uint64_t  f_blocks;             /* total data blocks in filesystem */
>         uint64_t  f_bfree;              /* free blocks in filesystem */
>         int64_t   f_bavail;             /* free blocks avail to non-superuser */
>    
>         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-superuser */
> 
>         uint64_t  f_syncreads;          /* count of sync reads since mount */
>         uint64_t  f_syncwrites;         /* count of sync writes since mount */
>         uint64_t  f_asyncreads;         /* count of async reads since mount */
>         uint64_t  f_asyncwrites;        /* count of async writes since mount */
>         
>         fsid_t    f_fsid;               /* filesystem id */
>         uint32_t  f_namemax;            /* maximum filename length */
>         uid_t     f_owner;              /* user that mounted the filesystem */
> 
>         char      f_fstypename[MFSNAMELEN]; /* filesystem type name */
>         char      f_mntfromname[MNAMELEN];  /* mounted filesystem */
>         char      f_mntonname[MNAMELEN];    /* directory on which mounted */
> };     
> 
> Issues [I supply my opinions...]
> 
> 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.

Sounds correct as far as current conventions go

> 2. Q: Should we go all the way and implement statvfs()?
>    A: I think so. statfs() is a berkeleism.
>    2a. Q: If we supply statvfs(), then do we still supply statfs too?
>        A: Not sure.

Things are used to it being there. We shouldn't necessarily remove it.

>    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.

Is it actually worded as a "should" or it spec'd as part of the API?

James