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'
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
