Re: [PATCH 5/9] libxlog: import the kernel's log recovery, log items and AIL

[Dave Chinner <dgc@kernel.org>]

On Wed, Aug 26, 2026 at 10:09:03PM -0700, Chris Wedgwood wrote:
> xfs_repair cannot replay a dirty log.  The code that can is in the
> kernel, and xfsprogs already carries kernel code rather than
> reimplementing it, so import it.
> 
> libxfs/ mirrors the kernel's fs/xfs/libxfs/ and these files are not from
> there; they are from the top level of fs/xfs.  They go in libxlog/,
> which is where this tree keeps log code, so that each directory has one
> kernel counterpart and tools/libxfs-diff can check both.
> 
> The files are copied from Linux v7.1 and are byte-identical to their
> kernel counterparts apart from their #include lists, which is the
> adaptation libxfs has always used.  v7.1 is the kernel this tree's
> libxfs/ is currently in sync with: comparing xfsprogs libxfs/ against
> v7.1 reports no difference in any of 102 files, while against v7.2 it
> reports 33.  Importing from a newer kernel than libxfs/ is synced to
> would mix two kernel versions in one tree.

This is not a direct code import - it mixed modification with code
copying.

Call it intuition, but the first thing I looked for was xlog_write()
- the function that writes new log records to disk. I immediately
notices that the kernel compat header neuters all the xlog_wait()
meaning iclogs do not work.  Hence I wondered how intent replay is
writing to the journal....

Yup, as I suspected,  the iclog code has been removed from the
journal IO path.  i.e. there's a heap of custom code buffer writing
code that is most definitely not the same as the kernel code. This
path is critical for correctness, and I have little confidence a
massive rewrite like this gets it right the first go.

Hence this whole patchset needs to seperate out the "lift to
userspace" file copies from the "modify for userspace" code changes
so that we can sanely review the actual code changes that matter.

This means -a lot more work for you-; these patches need to be
broken down into much smaller chunks that we can actually review;
a 14000 line patch that mixes kernel code with custom modifications
is not reviewable by anyone, not even a frontier LLM.

I'm not going to look at this in any more detail other than the
cursory scan I've already simply because it is impossible to find
all the changes that need careful review in this massive code
dump....

If the next posting of this series isn't at least 50+ patches, then
it probably still isn't fine grained enough to review
effectively....

Cheers,

Dave.
-- 
Dave Chinner
dgc@kernel.org