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

[Andreas Dilger]

On Oct 09, 2003  18:16 -0400, Trond Myklebust wrote:
>   We appear to have a problem with the new statfs interface
> in 2.6.0...
> 
> The problem is that as far as userland is concerned, 'struct statfs'
> reports f_blocks, f_bfree,... in units of the "optimal transfer size":
> f_bsize (backwards compatibility).
> 
> OTOH 'struct statvfs' reports the same values in units of the fragment
> size (the blocksize of the underlying filesyste): f_frsize. (says
> Single User Spec v2)
> 
> Both are apparently supposed to syscall down via sys_statfs()...
> 
> Question: how we're supposed to reconcile the two cases for something
> like NFS, where these 2 values are supposed to differ?

Actually, what is also a problem is that there is no hook for the system
to return different results for the 32-bit and 64-bit statfs structs.
Because Lustre is used on very large filesystems (i.e. 100TB+) we can't
fit the result into 32 bits without increasing f_bsize and reducing
f_bavail/f_bfree/f_blocks proportionately.

It would be nice if we could know in advance if we are returning values
for sys_statfs() or sys_statfs64() (e.g. by sys_statfs64() calling an
optional sb->s_op->statfs64() method if available) so we didn't have to
do this munging.  We can't just assume 64-bit results, or callers of
sys_statfs() will get EOVERFLOW instead of slightly innacurate results.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/