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:

Cool, since at least our NFSv3 already supports >32 bit filesystem info
and we'll silently truncate anything bigger.

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

You've mentioned we've already broken the original naming idea.  "Stick
with what's in current usage".

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

Yes.  We don't want a program written for NetBSD 1.6 not to work on
NetBSD 2.0, especially since it only needs a bit of glue in libc to
handle 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.

As Bill mentioned, I'm inclined to stick with what the standard says.
Less portability problems, less confusion.

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

Definitely stick with what the standard says.  Code that uses this will
have per-stat*fs handlers and will deal with it.  We lose portability if
use a POSIX/SUSv3 interface and change the meanings - we'd may as well
not use statvfs and beef up statfs if we do that.

> 3. Q: I added more stats, favail [statvfs has it too], is there anything else
>       we need?
>    A: ???

You have:
          uint32_t  f_flags;              /* copy of mount exported flags */

but SUSv3 says

	unsigned long f_flag		Bit mask of f_flag values.

where ST_RDONLY and ST_NOSUID are listed.  Perhaps we have that latter
only and define MNT_RDONLY to ST_RDONLY, MNT_NOSUID to ST_NOSUID and so
on for all the current MNT_ flags?  Having both seems like overkill, and
for the reason I listed about (portability) I think it makes sense to
include all the members defined in the statvfs structure by SUSv3.

SUSv3 does say that f_fsid should be a ulong, but we know our fsid_t
doesn't fit in that on 32bit arch's.  "Hmmm."  We really do need to
keep that as an fsid_t...

> 4. Q: Should we change sys_getstatfs() to take size_t instead of long as
>       the second arg.
>    A: I think so.

What is sys_getstatfs() and what is it's second arg used for?

Simon.
--
Simon Burge                                   <simonb@wasabisystems.com>
NetBSD Development, Support and Service:   http://www.wasabisystems.com/