Subject: Re: statfs, statvfs and friends.
To: Simon Burge <simonb@wasabisystems.com>
From: Christos Zoulas <christos@zoulas.com>
List: tech-kern
Date: 03/30/2004 22:06:11
On Mar 31, 12:52pm, simonb@wasabisystems.com (Simon Burge) wrote:
-- Subject: Re: statfs, statvfs and friends.

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

good.

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

fine.

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

libc glue it is.

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

except fsid as you mention.

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

ok.

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

The problem is that we have 4 bits left for mount flags, and freebsd
has made flags 64 bits already. I say we leave it to unsigned long
because we'll have to version to mount call too already.

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

correct.

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

It is used to get statfs info for multiple filesystems. The long is the
size of the buffer, so it should really be a size_t.

christos