Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: dsterba@suse.cz
Cc: iamhswang@gmail.com, linux-btrfs@vger.kernel.org, clm@fb.com,
	josef@toxicpanda.com, dsterba@suse.com, wqu@suse.com,
	boris@bur.io, linux-kernel@vger.kernel.org,
	Haisu Wang <haisuwang@tencent.com>
Subject: Re: [PATCH 2/2] btrfs: simplify regions mark and keep start unchanged in err handling
Date: Thu, 31 Oct 2024 08:31:32 +1030	[thread overview]
Message-ID: <19596057-5403-4ecd-a817-efdc5d69adc6@gmx.com> (raw)
In-Reply-To: <20241030152836.GA31418@twin.jikos.cz>



在 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@gmail.com 写道:
>>> From: Haisu Wang <haisuwang@tencent.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

  reply	other threads:[~2024-10-30 22:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-25  6:54 [PATCH v2 0/2] btrfs: fix the length of reserved qgroup to free iamhswang
2024-10-25  6:54 ` [PATCH 1/2] " iamhswang
2024-10-25  6:54 ` [PATCH 2/2] btrfs: simplify regions mark and keep start unchanged in err handling iamhswang
2024-10-30  3:01   ` Qu Wenruo
2024-10-30  3:22     ` hs wang
2024-10-30 15:28     ` David Sterba
2024-10-30 22:01       ` Qu Wenruo [this message]
2024-10-30  0:13 ` [PATCH v2 0/2] btrfs: fix the length of reserved qgroup to free David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19596057-5403-4ecd-a817-efdc5d69adc6@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=boris@bur.io \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=dsterba@suse.cz \
    --cc=haisuwang@tencent.com \
    --cc=iamhswang@gmail.com \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wqu@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox