On 2/10/20 8:43 AM, Eric Sandeen wrote:
>> John Jore wrote:
...
>>>> Any suggestions or additional data I can provide?
>>>
>>> If you are willing to provide an xfs_metadump to me (off-list) I will see if I can
>>> reproduce it from the metadump.
>>>
>>> # xfs_metadump /dev/$WHATEVER metadump.img
>>> # bzip2 metadump.img
>
> Thanks for providing this offline, I'll take a look.
Ok, so the problem is that you have a whole chunk of inodes that is nothing but
zeros; you can see this with:
# xfs_db -r -c "fsblock 1140850974" -c "type data" -c "p" /dev/$WHATEVER
where fsblock 1140850974 is the location of the bad section of inodes.
How that happened, nobody knows, but that's the corruption that's being detected.
So the problem here is that we added a new test to the inode verifiers, which
validates the next_unlinked field of the inode; this got inherited from kernelspace:
commit 2949b46779cf054a7f9067000bbadf35e55b3ce7
Author: Darrick J. Wong <darrick.wong@xxxxxxxxxx>
Date: Wed Apr 18 14:46:07 2018 -0500
xfs: don't accept inode buffers with suspicious unlinked chains
Source kernel commit: 6a96c5650568a2218712d43ec16f3f82296a6c53
When we're verifying inode buffers, sanity-check the unlinked pointer.
We don't want to run the risk of trying to purge something that's
obviously broken.
Signed-off-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx>
Reviewed-by: Brian Foster <bfoster@xxxxxxxxxx>
Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx>
so we now have a test for a valid next unlinked field when we write the inodes,
but we never reset it in repair, so the write verifier fails, and the modified
inodes do not get written back to disk.
I'll send a patch to fix this for this for review, and cc: you, in a moment.
-Eric
