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

[Trond Myklebust]

>>>>> " " == Linus Torvalds <torvalds@xxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/