From: Jeffin Philip <jeffinphilip14@gmail.com>
To: dgc@kernel.org
Cc: cem@kernel.org, jeffinphilip14@gmail.com,
linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [RFC PATCH 0/2] xfs: change xfs log item refcount design
Date: Thu, 17 Sep 2026 09:21:04 +0530 [thread overview]
Message-ID: <20260917035104.10762-1-jeffinphilip14@gmail.com> (raw)
In-Reply-To: <aqsYHjEp-7TM1h8F@dread>
On Wed, September 16 2026 at 10:28 PM, Dave Chinner wrote:
>On Fri, Sep 11, 2026 at 03:55:00PM +0530, Jeffin Philip wrote:
>> This patch series is the first of the series where we attempt to convert
>> the XFS Log item reference counting design to be more generic
>> compared to the previous type-specific state to fix the "zero
>> refcount but in AIL means alive" state. The patch series follows
>> instructions outlined here[1].
>>
>> Obviously, the wrappers will be integrated in type-specific functions
>> later on.
>>
>> No behavioral change as of yet.
>>
>> [1]: https://lore.kernel.org/all/aqI6v-_dc2DDSbgB@dread/
>>
>> Jeffin Philip (2):
>> xfs: add lockref and generic helpers for refcounting
>> xfs: change xfs_trans_ail_delete return type to bool
>
>It's great to see you starting on this, but there's not much point
>in just posting wrappers that aren't used by anything. Until there
>is code that uses them, we can't really say anythign useful about
>the wrappers. e.g.
>
>Is the API optimal? Don't know.
>
>Is open coding the init correct for the generic case or is that just
>projecting an antipattern from the BLI reference counting? Don't
>know.
>
>And so on. Hence it's best to present the wrappers with the code
>that then uses them so we have the necessary context with which to
>review them.
The BLI changes have almost been finished and I am testing them. The
reason I did not post it is because I wanted it to face more proper
review and that is likely to be stricter when the patches are
few. I could still write the entire implementation and post it as a
giant patch series provided it does not fatigue the reviewers from
reviewing several tens of patches at a time. Until then, I feel like
it mould be much better to post 1 implementation step at a time in 1
patchset. If you prefer otherwise, that can be done too.
Thanks,
Jeffin.
next prev parent reply other threads:[~2026-09-17 3:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-11 10:25 [RFC PATCH 0/2] xfs: change xfs log item refcount design Jeffin Philip
2026-09-11 10:25 ` [RFC PATCH 1/2] xfs: add lockref and generic helpers for refcounting Jeffin Philip
2026-09-11 10:25 ` [RFC PATCH 2/2] xfs: change xfs_trans_ail_delete return type to bool Jeffin Philip
2026-09-16 22:28 ` [RFC PATCH 0/2] xfs: change xfs log item refcount design Dave Chinner
2026-09-17 3:51 ` Jeffin Philip [this message]
2026-09-21 22:19 ` Dave Chinner
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=20260917035104.10762-1-jeffinphilip14@gmail.com \
--to=jeffinphilip14@gmail.com \
--cc=cem@kernel.org \
--cc=dgc@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.