On 7.12.18 г. 9:09 ч., Nikolay Borisov wrote:
>
>
> On 6.12.18 г. 19:54 ч., David Sterba wrote:
>> On Thu, Dec 06, 2018 at 06:52:21PM +0200, Nikolay Borisov wrote:
>>>
>>>
>>> On 3.12.18 г. 17:20 ч., Josef Bacik wrote:
>>>> Now with the delayed_refs_rsv we can now know exactly how much pending
>>>> delayed refs space we need. This means we can drastically simplify
>>>
>>> IMO it will be helpful if there is a sentence here referring back to
>>> btrfs_update_delayed_refs_rsv to put your first sentence into context.
>>> But I guess this is something David can also do.
>>
>> I'll update the changelog, but I'm not sure what exactly you want to see
>> there, please post the replacement text. Thanks.
>
> With the introduction of dealyed_refs_rsv infrastructure, namely
> btrfs_update_delayed_refs_rsv we now know exactly how much pending
> delayed refs space is required.
To put things into context as to why I deem this change beneficial -
basically doing the migration of reservation from transaction to delayed
refs rsv modifies both size and reserved - they will be equal. Calling
btrfs_update_delayed_refs_rsv actually increases ->size and doesn't
really decrement ->reserved. Also we never do
btrfs_block_rsv_migrate/use_block_rsv on the delayed refs block rsv so
managing ->reserved value for delayed refs rsv is different than for
the rest of the block rsv.
>
>>
>>>> btrfs_check_space_for_delayed_refs by simply checking how much space we
>>>> have reserved for the global rsv (which acts as a spill over buffer) and
>>>> the delayed refs rsv. If our total size is beyond that amount then we
>>>> know it's time to commit the transaction and stop any more delayed refs
>>>> from being generated.
>>>>
>>>> Signed-off-by: Josef Bacik <jo...@toxicpanda.com>
>>
>
