mbox series

[0/8] xfs-5.0: inode btree scrub fixes

Message ID 154147728649.32496.4515247239602322709.stgit@magnolia (mailing list archive)
Headers show
Series xfs-5.0: inode btree scrub fixes | expand

Message

Darrick J. Wong Nov. 6, 2018, 4:08 a.m. UTC 
Hi all,

This series fixes some problems with the inode btree scrub code, namely
that the existing code does not handle the case where a single inode
cluster is mapped by multiple inobt records.  The series also cleans up
the rather confusing variable names.

Patch 1 teaches the inode record block counting code to handle the case
where there's more than one inobt record per inode cluster.  We do this
by counting inodes and converting to blocks only at the end.

Patch 2 starts moving the inode geometry stuff to the xchk_iallocbt
context so that we only calculate those things once.

Patches 3-4 move the inobt record alignment checks to a separate
function and enhance the function to check that when we have more than
one inobt record per cluster we actually check that *all* of the
necessary records are present and in the correct order.

Patches 5-7 reorganize the inobt free data checks to deal with the
"multiple inobt records per icluster" situation.  In restructuring the
code to do so, we also rename variables and functions to be less
confusing about what they're there for.

Patch 8 fixes the 'is the inode free?' check to calculate dinode buffer
offsets correctly in the "multiple inobt records per icluster"
situation.

If you're going to start using this mess, you probably ought to just
pull from my git trees.  The kernel patches[1] should apply against
4.20-rc1.

This is an extraordinary way to eat your data.  Enjoy!
Comments and questions are, as always, welcome.

--D

[1] https://git.kernel.org/cgit/linux/kernel/git/djwong/xfs-linux.git/log/?h=djwong-devel

Comments

Christoph Hellwig Nov. 9, 2018, 3:07 p.m. UTC | #1 
What is the xfs-5.0 in the subject line?
Darrick J. Wong Nov. 9, 2018, 4:39 p.m. UTC | #2 
On Fri, Nov 09, 2018 at 07:07:06AM -0800, Christoph Hellwig wrote:
> 
> What is the xfs-5.0 in the subject line?

The 5.0 was intended to convey "patches for the next merge window" (as
opposed to "fixes for 4.20").  Maybe I'll just say "xfs-next" from now
on as that clearly didn't come across. :)

--D