Skip to contentSkip to conversation

statfs f_bfree vs. f_bavail

DISCUSSION Bernd Schubert 1 participant 1 message Jan 21, 2014 Btrfs file system

lore
Share & tools
lore
#0 lore raw

Hi all,

I just noticed a mismatch between statfs.f_bfree and statfs.f_bavail, i.e.

(squeeze)fslab2:~# ./statfs /data/fhgfs/storage1/

/data/fhgfs/storage1/: avail: 3162112 free: 801586610176

(with

        uint64_t avail = statbuf.f_bavail * statbuf.f_bsize;
        uint64_t free  = statbuf.f_bfree * statbuf.f_bsize;

)

Given the fact that I write much data to this file system anymore, f_bavail seems to be give the number I'm interested in.

According to 'man 2 statfs'

Quoted 3 lines
               fsblkcnt_t   f_bfree;   /* free blocks in fs */
               fsblkcnt_t   f_bavail;  /* free blocks available to

unprivileged user */

f_bfree and f_bavail shouldn't differ too much. But btrfs uses two entirely different calculations for that (btrfs_statfs).

f_bavail = disk_with_block_groups_total_ - disk_used - block_group_space + free_data_space f_bfree = all_disk_blocks - total_used

Now for any raid level (I'm using raid6) using the sum of all data disk blocks without substracting redundancy blocks doesn't seem to be something the user is interested in.
In our particular case we are using f_bavail if fhgfs-storage was started as root and f_bfree when it started from non-root (extN root user space reservation). Now with btrfs this entirely fails and even confuses our low target pool detection. I could add a workaround for btrfs for that into our code based on f_type, but I wonder if it wouldn't be better to improve btrfs_statfs.
What is the actual intention for the current f_bfree value?

Thanks,
Bernd