Re: statfs() / statvfs() syscall ballsup...

[viro@parcelfarce.linux.theplanet.co.uk]

On Thu, Oct 09, 2003 at 04:19:29PM -0700, Ulrich Drepper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Linus Torvalds wrote:
> 
> > User space shouldn't know or care about frsize, and it doesn't even 
> > necessarily make any sense on a lot of filesystems, so make it easy for 
> > the user. It's not as if the rounding errors really matter.
> 
> There have been numerous requests to add a statvfs syscall, at least
> made to me.  The problem is that the emulation through statfs cannot be
> optimal.  The emulation has to get all kinds of additional information
> (like mount flags) which in some cases lead to hangs or delays.

Umm...  I don't see anything equivalent to statfs(2) ->f_type in statvfs(2).
->f_frsize makes no sense for practically all filesystems we support.
->f_namemax is not well-defined ("maximum filename length" as in "you won't
see filenames longer than..." or "attempt to create a file with name longer
than... will fail" or "longer than that and I'm truncating";  and that is
aside of lovely questions about the meaning of "length" - strlen()?  number
of multibyte characters accepted by that fs? something else?)
->f_fsid is also practically undefined (and left 0 by practically every fs,
so no userland code can do anything useful with it).
->f_flag might be useful, all right.  However, I'd like to see real-world
examples of code (Solaris, whatever) that would use it in any meaningful
way...

Conclusion: if we care about something like statvfs(), it should *not* have
the statvfs() interface.