On 1/16/20 1:04 AM, Qu Wenruo wrote:
Although btrfs_calc_avail_data_space() is trying to do an estimation on how many data chunks it can allocate, the estimation is far from perfect: - Metadata over-commit is not considered at all - Chunk allocation doesn't take RAID5/6 into consideration This patch will change btrfs_calc_avail_data_space() to use pre-calculated per-profile available space. This provides the following benefits: - Accurate unallocated data space estimation, including RAID5/6 It's as accurate as chunk allocator, and can handle RAID5/6. Although it still can't handle metadata over-commit that accurately, we still have fallback method for over-commit, by using factor based estimation. The good news is, over-commit can only happen when we have enough unallocated space, so even we may not report byte accurate result when the fs is empty, the result will get more and more accurate when unallocated space is reducing. So the metadata over-commit shouldn't cause too many problem. Since we're keeping the old lock-free design, statfs should not experience any extra delay. Signed-off-by: Qu Wenruo <wqu@xxxxxxxx>
Reviewed-by: Josef Bacik <josef@xxxxxxxxxxxxxx> Thanks, Josef
