On 05/11/2012 09:56 PM, Nikolaus Rath wrote:
On 05/11/2012 01:04 PM, Paul Eggert wrote:
On 05/11/2012 03:42 AM, Jim Meyering wrote:
it's not clear that there is even a problem with our
current use of statfs on glibc-based Linux systems.
Yes, I find it curious. GNU/Linux statvfs
simply invokes statfs internally, right?
So why should it matter whether df uses statvfs
or statfs? And yet from Nikolaus Rath's evidence
it does appear that we have a problem with current FUSE systems.
In the long run I'd rather have the Linux-based code
use statvfs, since that's the more-standard interface.
Nikolaus, does the attached hack fix things for you?
Basically, it transforms a configure-time test into a
run-time test. After applying this patch,
you'll need to run autoreconf + configure before 'make'.
Yes, this works:
[..]
I just noticed that the "stat" command is affected by this as well:
# src/stat -f ~/tmp/mnt
File: "/home/nikratio/tmp/mnt"
ID: 0 Namelen: 0 Type: fuseblk
Block size: 81920 Fundamental block size: 81920
Blocks: Total: 104857 Free: 104854 Available: 104854
Inodes: Total: 1000000 Free: 999994
It incorrectly reports the same value for the block size and fundamental
block size.
I also checked the FUSE mailing list. If I understand
http://article.gmane.org/gmane.comp.file-systems.fuse.devel/3902 right,
then FUSE is behaving correctly and the only solution is to use statvfs
instead of statfs if any file system properties need to be determined in
bytes rather than blocks.
Best,
-Nikolaus
--
»Time flies like an arrow, fruit flies like a Banana.«
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C