Hi Filipe,
Thank you for the explanation.
On Sun, Dec 13, 2015 at 5:43 PM, Filipe Manana wrote:
> On Sun, Dec 13, 2015 at 10:51 AM, Alex Lyakas wrote:
>> Hi Filipe Manana,
>>
>> My understanding of selecting delayed refs to run or merging them is
>> far from complete. Can you please explain wha
On Sun, Dec 13, 2015 at 10:51 AM, Alex Lyakas wrote:
> Hi Filipe Manana,
>
> My understanding of selecting delayed refs to run or merging them is
> far from complete. Can you please explain what will happen in the
> following scenario:
>
> 1) Ref1 is created, as you explain
> 2) Somebody calls __b
Hi Filipe Manana,
My understanding of selecting delayed refs to run or merging them is
far from complete. Can you please explain what will happen in the
following scenario:
1) Ref1 is created, as you explain
2) Somebody calls __btrfs_run_delayed_refs() and runs Ref1, and we end
up with an EXTENT_
From: Filipe Manana
In the kernel 4.2 merge window we had a refactoring/rework of the delayed
references implementation in order to fix certain problems with qgroups.
However that rework introduced one more regression that leads to the
following trace when running delayed references for metadata: