]> git.ipfire.org Git - thirdparty/xfsprogs-dev.git/commit
xfs_repair: junk leaf attribute if count == 0
authorEric Sandeen <sandeen@redhat.com>
Wed, 21 Dec 2016 04:38:01 +0000 (22:38 -0600)
committerEric Sandeen <sandeen@redhat.com>
Wed, 21 Dec 2016 04:38:01 +0000 (22:38 -0600)
commitf71401617acd8fccb2461dcd03d8868f8c87c07b
tree2613fdde4d188719118ac5f9f6c52799e4e52d79
parentf9cd7f89801246cefb0d4d194b1346898bead59b
xfs_repair: junk leaf attribute if count == 0

We have recently seen a case where, during log replay, the
attr3 leaf verifier reported corruption when encountering a
leaf attribute with a count of 0 in the header.

We chalked this up to a transient state when a shortform leaf
was created, the attribute didn't fit, and we promoted the
(empty) attribute to the larger leaf form.

I've recently been given a metadump of unknown provenance which actually
contains a leaf attribute with count 0 on disk.  This causes the
verifier to fire every time xfs_repair is run:

 Metadata corruption detected at xfs_attr3_leaf block 0x480988/0x1000

If this 0-count state is detected, we should just junk the leaf, same
as we would do if the count was too high.  With this change, we now
remedy the problem:

 Metadata corruption detected at xfs_attr3_leaf block 0x480988/0x1000
 bad attribute count 0 in attr block 0, inode 12587828
 problem with attribute contents in inode 12587828
 clearing inode 12587828 attributes
 correcting nblocks for inode 12587828, was 2 - counted 1

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
repair/attr_repair.c