Re: [PATCH] btrfs: super: Make btrfs_statfs() work with metadata over-commiting

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1593 bytes --]



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@mail.gmail.com/T/#t
>>
>> https://lore.kernel.org/linux-btrfs/CAJCQCtSWW4ageK56PdHtSmgrFrDf_Qy0PbxZ5LSYYCbr3Z10ug@mail.gmail.com/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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 520 bytes --]