On 2019/12/18 上午12:05, Josef Bacik wrote: > On 12/16/19 1:12 AM, Qu Wenruo wrote: >> [BUG] >> There are several reports about vanilla `df` reports no available space, >> while `btrfs filesystem df` is still reporting tons of unallocated >> space. >> >> https://lore.kernel.org/linux-btrfs/CAJCQCtQEu_+nL_HByAWK2zKfg2Zhpm3Ezto+sA12wwV0iq8Ghg@xxxxxxxxxxxxxx/T/#t >> >> https://lore.kernel.org/linux-btrfs/CAJCQCtSWW4ageK56PdHtSmgrFrDf_Qy0PbxZ5LSYYCbr3Z10ug@xxxxxxxxxxxxxx/T/#t >> >> >> The example output from vanilla `df` would look like: >> Filesystem Size Used Avail Use% Mounted on >> /dev/loop0 7.4T 623G 0 100% /media/backup >> >> [CAUSE] >> There is a special check in btrfs_statfs(), which reset f_bavail: >> >> if (!mixed && total_free_meta - SZ_4M < block_rsv->size) >> buf->f_bavail = 0; > > Why not just read fs_info->free_chunk_space and take that into account? > The point is we want to tell the user there's no room left if we can't > allocate a new chunk and we only have the global reserve space left. So > just subtract the global reserve size from the total f_bavail as long as > free_chunk_space is sufficient, otherwise fall back to the original > calculation. Thanks, Because not all unallocated space can be utilized by all profiles, that's why we have complex calculation in btrfs_calc_avail_data_space(), which tries to emulate chunk allocator to get how many space we can really use. And we also need to take space usage factor into consideration. Thanks, Qu > > Josef
Attachment:
signature.asc
Description: OpenPGP digital signature
