[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <19596057-5403-4ecd-a817-efdc5d69adc6@gmx.com>
Date: Thu, 31 Oct 2024 08:31:32 +1030
From: Qu Wenruo <quwenruo.btrfs@....com>
To: dsterba@...e.cz
Cc: iamhswang@...il.com, linux-btrfs@...r.kernel.org, clm@...com,
josef@...icpanda.com, dsterba@...e.com, wqu@...e.com, boris@....io,
linux-kernel@...r.kernel.org, Haisu Wang <haisuwang@...cent.com>
Subject: Re: [PATCH 2/2] btrfs: simplify regions mark and keep start unchanged
in err handling
在 2024/10/31 01:58, David Sterba 写道:
> On Wed, Oct 30, 2024 at 01:31:15PM +1030, Qu Wenruo wrote:
>>
>>
>> 在 2024/10/25 17:24, iamhswang@...il.com 写道:
>>> From: Haisu Wang <haisuwang@...cent.com>
>>>
>>> Simplify the regions mark by using cur_alloc_size only to present
>>> the reserved but may failed to alloced extent. Remove the ram_size
>>> as well since it is always consistent to the cur_alloc_size in the
>>> context. Advanced the start mark in normal path until extent succeed
>>> alloced and keep the start unchanged in error handling path.
>>>
>>> PASSed the fstest generic/475 test for a hundred times with quota
>>> enabled. And a modified generic/475 test by removing the sleep time
>>> for a hundred times. About one tenth of the tests do enter the error
>>> handling path due to fail to reserve extent.
>>>
>>
>> Although this patch is already merged into for-next, it looks like the
>> next patch will again change the error handling, mostly render the this
>> one useless:
>>
>> https://lore.kernel.org/linux-btrfs/2a0925f0264daf90741ed0a7ba7ed4b4888cf778.1728725060.git.wqu@suse.com/
>>
>> The newer patch will change the error handling to a simpler one, so
>> instead of 3 regions, there will be only 2.
>>
>> There will be no change needed from your side, I will update my patches
>> to solve the conflicts, just in case if you find the error handling is
>> different in the future.
>
> Please take care of that, the only request I have is that it's done by
> the end of this week so we have the code in linux-next and that a fix
> should come before a refactoring (due to backports). Update for-next as
> you need.
Then everything is done.
The patch itself is not touched and already in for-next branch.
The new one is part of the subpage enhancement series now, which is not
that urgent.
The subpage compression write support is already large enough for the
next release cycle.
Thanks,
Qu
Powered by blists - more mailing lists