Messages in this thread | ![/](/images/icornerl.gif) | | Date | Thu, 9 Oct 2003 19:31:02 -0400 | Subject | Re: statfs() / statvfs() syscall ballsup... | From | Trond Myklebust <> |
| |
>>>>> " " == Linus Torvalds <torvalds@osdl.org> writes:
>> Note that f_bsize is usually larger than f_frsize, hence >> conversions from the former to the latter are subject to >> rounding errors...
> 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.
It can lead to funny quirks when doing df: Used + Available != Total
Granted the effects won't be enormous (typically you'll see between 1 and 63 blocks off in the case of NFS w/ 32kwsize and 512byte frsize) but people get upset about this. That was the reason for adding an f_frsize field in the first place...
Note: one solution might be to swap the positions of f_frsize and f_bsize in the kernel struct that is passed up to userland. I.e. pass up
struct statfs { __u32 f_type; - __u32 f_bsize; + __u32 f_frsize; __u32 f_blocks; __u32 f_bfree; __u32 f_bavail; __u32 f_files; __u32 f_ffree; __kernel_fsid_t f_fsid; __u32 f_namelen; - __u32 f_frsize; + __u32 f_bsize; __u32 f_spare[5]; };
That will give correct values for the f_bfree, f_bavail,... in the legacy statfs() case for all existing filesystems.
glibc's statvfs() can then do the correct thing if it detects a >=2.6.0 kernel. It needs to do a copy to its private statvfs struct anyway.
Cheers, Trond - 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/
| ![\](/images/icornerr.gif) |