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

[Nikolaus Rath]

On 05/10/2012 12:24 PM, Paul Eggert wrote:
> On 05/04/2012 07:23 PM, Nikolaus Rath wrote:
>> # strace -v src/df -h ~/tmp/mnt
>> [...]
>> stat("/home/nikratio/tmp/mnt", {st_dev=makedev(0, 23), st_ino=1, 
>> st_mode=S_IFDIR|0755, st_nlink=1, st_uid=1000, st_gid=1000, 
>> st_blksize=131072, st_blocks=0, st_size=0, st_atime=2012/05/04-22:13:30, 
>> st_mtime=2012/05/04-22:13:18, st_ctime=2012/05/04-22:13:18}) = 0
>> statfs("/home/nikratio/tmp/mnt", {f_type=0x65735546, f_bsize=81920, 
>> f_blocks=104857, f_bfree=104854, f_bavail=104854, f_files=1000000, 
>> f_ffree=999994, f_fsid={0, 0}, f_namelen=0, f_frsize=10485760}) = 0
> 
> Sorry, I've lost context here.  What's wrong with those numbers,
> or with the output of df?
> 
> The numbers indicate a file system with 104857 blocks, each of size
> 81920 bytes, for a total of 8,589,885,440 bytes.  Are those
> numbers wrong?  If so, it's a problem with the kernel or the
> file system, not with df.  And if the numbers are correct,
> then what's wrong with df's behavior (you didn't say what
> it was...)?

The problem is that the file system actually has a size of 1 TB, not 7
GB. The file system reports its size in st_frsize units, which are 10 MB
each. Since du is using statfs instead of statvfs, it does not have
access to st_frsize and apparently uses st_bsize instead. But why isn't
it du using statvfs instead of statfs?

I am not quite sure who's to blame here. This is a FUSE file system, and
there is only a callback handler for statvfs calls (but not statfs).
Should the FUSE kernel module maybe return st_frsize as st_bsize when
processing a statfs syscall?


Best,

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C