bug#11406: Bug? df uses f_bsize instead of f_frsize to calculate file system sizes

[Nikolaus Rath]

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