]> git.ipfire.org Git - thirdparty/xfsprogs-dev.git/commitdiff
xfs_repair: ignore empty xattr leaf blocks
authorDarrick J. Wong <djwong@kernel.org>
Fri, 24 Jun 2022 23:19:20 +0000 (16:19 -0700)
committerDarrick J. Wong <djwong@kernel.org>
Tue, 28 Jun 2022 20:42:59 +0000 (13:42 -0700)
As detailed in the previous commit, empty xattr leaf blocks can be the
benign byproduct of the system going down during the multi-step process
of adding a large xattr to a file that has no xattrs.  If we find one at
attr fork offset 0, we should clear it, but this isn't a corruption.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
repair/attr_repair.c

index 2055d96eeb3bf7b5e0b767d7a14729eb717e1442..c3a6d50267e242b7dffaa03fb3e85b919d0a8c30 100644 (file)
@@ -579,6 +579,26 @@ process_leaf_attr_block(
        firstb = mp->m_sb.sb_blocksize;
        stop = xfs_attr3_leaf_hdr_size(leaf);
 
+       /*
+        * Empty leaf blocks at offset zero can occur as a race between
+        * setxattr and the system going down, so we only take action if we're
+        * running in modify mode.  See xfs_attr3_leaf_verify for details of
+        * how we've screwed this up many times.
+        */
+       if (!leafhdr.count && da_bno == 0) {
+               if (no_modify) {
+                       do_log(
+       _("would clear empty leaf attr block 0, inode %" PRIu64 "\n"),
+                                       ino);
+                       return 0;
+               }
+
+               do_warn(
+       _("will clear empty leaf attr block 0, inode %" PRIu64 "\n"),
+                               ino);
+               return 1;
+       }
+
        /* does the count look sorta valid? */
        if (!leafhdr.count ||
            leafhdr.count * sizeof(xfs_attr_leaf_entry_t) + stop >