Comment 2Raghavendra Talur
2017-12-07 12:30:50 UTC
This difference is because FUSE uses a block size and fragment size of 128K instead of using the backend filesystem's block size.
When statvfs call is made, this is the statvfs buffer content
blocks bfree bavail
gfapi 259584, 248433, 251028
brick 259584, 251028, 251028
fuse 8112, 7763, 7844
As you can see, gfapi and brick match in total blocks and bavail.
There is a difference in bfree because of posix xlator. Posix xlator deducts 1% of the total blocks from free blocks.
The numbers in fuse are the numbers in gfapi row divided by 32(because the numbers obtained from brick are for 4K blocks and fuse wants to communicate in terms of 128K blocks). Here, we are converting into a larger unit and value is rounded off.
df on a mount point would get data from fuse and hence the discrepancy.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHSA-2018:2607
This difference is because FUSE uses a block size and fragment size of 128K instead of using the backend filesystem's block size. When statvfs call is made, this is the statvfs buffer content blocks bfree bavail gfapi 259584, 248433, 251028 brick 259584, 251028, 251028 fuse 8112, 7763, 7844 As you can see, gfapi and brick match in total blocks and bavail. There is a difference in bfree because of posix xlator. Posix xlator deducts 1% of the total blocks from free blocks. The numbers in fuse are the numbers in gfapi row divided by 32(because the numbers obtained from brick are for 4K blocks and fuse wants to communicate in terms of 128K blocks). Here, we are converting into a larger unit and value is rounded off. df on a mount point would get data from fuse and hence the discrepancy.