Messages in this thread | | | Date | Thu, 9 Oct 2003 17:16:52 -0600 | From | Andreas Dilger <> | Subject | Re: statfs() / statvfs() syscall ballsup... |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |