linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Cc: dsterba@suse.cz
Subject: [PATCH 10/11] btrfs-progs: lowmem check: Fix false alerts of referencer count mismatch for snapshot
Date: Wed, 22 Nov 2017 17:03:24 +0800	[thread overview]
Message-ID: <20171122090325.29458-11-wqu@suse.com> (raw)
In-Reply-To: <20171122090325.29458-1-wqu@suse.com>

Btrfs lowmem check reports such false alerts:
------
ERROR: extent[366498091008, 134217728] referencer count mismatch (root: 827, owner: 73782, offset: 134217728) wanted: 4, have: 26
ERROR: extent[366498091008, 134217728] referencer count mismatch (root: 818, owner: 73782, offset: 134217728) wanted: 4, have: 26
ERROR: extent[366498091008, 134217728] referencer count mismatch (root: 870, owner: 73782, offset: 134217728) wanted: 4, have: 26
------

While in extent tree, the extent has:
------
        item 81 key (366498091008 EXTENT_ITEM 134217728) itemoff 9008 itemsize 169
                refs 39 gen 224 flags DATA
                extent data backref root 827 objectid 73782 offset 134217728 count 4
                extent data backref root 818 objectid 73782 offset 134217728 count 4
                extent data backref root 259 objectid 73482 offset 134217728 count 1
                extent data backref root 644 objectid 73782 offset 134217728 count 26
                extent data backref root 870 objectid 73782 offset 134217728 count 4
------

And in root 827, there is one leaf with 4 references to that extent
which is owned by 827:
------
leaf 714964992 items 68 free space 10019 generation 641 owner 827
leaf 714964992 flags 0x1(WRITTEN) backref revision 1
......
        item 64 key (73782 EXTENT_DATA 134217728) itemoff 11878 itemsize 53
                generation 224 type 1 (regular)
                extent data disk byte 366498091008 nr 134217728
                extent data offset 0 nr 6410240 ram 134217728
                extent compression 0 (none)
        item 65 key (73782 EXTENT_DATA 140627968) itemoff 11825 itemsize 53
                generation 224 type 1 (regular)
                extent data disk byte 366498091008 nr 134217728
                extent data offset 6410240 nr 5120000 ram 134217728
                extent compression 0 (none)
        item 66 key (73782 EXTENT_DATA 145747968) itemoff 11772 itemsize 53
                generation 224 type 1 (regular)
                extent data disk byte 366498091008 nr 134217728
                extent data offset 11530240 nr 7675904 ram 134217728
                extent compression 0 (none)
        item 67 key (73782 EXTENT_DATA 153423872) itemoff 11719 itemsize 53
                generation 224 type 1 (regular)
                extent data disk byte 366498091008 nr 134217728
                extent data offset 19206144 nr 6397952 ram 134217728
                extent compression 0 (none)
------

And starts from next leaf, there are 22 references to the data extent:
------
leaf 894861312 items 208 free space 59 generation 261 owner 644
leaf 894861312 flags 0x1(WRITTEN) backref revision 1
        item 0 key (73782 EXTENT_DATA 159821824) itemoff 16230 itemsize 53
                generation 224 type 1 (regular)
                extent data disk byte 366498091008 nr 134217728
                extent data offset 25604096 nr 8192 ram 134217728
                extent compression 0 (none)
        item 1 key (73782 EXTENT_DATA 159830016) itemoff 16177 itemsize 53
                generation 224 type 1 (regular)
                extent data disk byte 366498091008 nr 134217728
                extent data offset 25612288 nr 7675904 ram 134217728
                extent compression 0 (none)
......
------

However the next leaf is owned by other subvolume, normally owned by (part of)
the snapshot source.

Fix it by also checking the leaf's owner before increasing the reference
counter.

Reported-by: Chris Murphy <chris@colorremedies.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
---
 cmds-check.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/cmds-check.c b/cmds-check.c
index 791fab6b3e6a..e746ee7b281d 100644
--- a/cmds-check.c
+++ b/cmds-check.c
@@ -12518,11 +12518,17 @@ static int check_extent_data_backref(struct btrfs_fs_info *fs_info,
 		 * Except normal disk bytenr and disk num bytes, we still
 		 * need to do extra check on dbackref offset as
 		 * dbackref offset = file_offset - file_extent_offset
+		 *
+		 * Also, we must check the leaf owner.
+		 * In case of shared tree blocks (snapshots) we can inherit
+		 * leaves from source snapshot.
+		 * In that case, reference from source snapshot should not
+		 * count.
 		 */
 		if (btrfs_file_extent_disk_bytenr(leaf, fi) == bytenr &&
 		    btrfs_file_extent_disk_num_bytes(leaf, fi) == len &&
 		    (u64)(key.offset - btrfs_file_extent_offset(leaf, fi)) ==
-		    offset)
+		    offset && btrfs_header_owner(leaf) == root_id)
 			found_count++;
 
 next:
-- 
2.15.0


  parent reply	other threads:[~2017-11-22  9:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-22  9:03 [PATCH 00/11] Lowmem mode btrfs fixes exposed by complex tree Qu Wenruo
2017-11-22  9:03 ` [PATCH 01/11] btrfs-progs: lowmem check: Fix regression which screws up extent allocator Qu Wenruo
2017-11-22  9:03 ` [PATCH 02/11] btrfs-progs: lowmem check: Fix NULL pointer access caused by large tree reloc tree Qu Wenruo
2017-11-22  9:03 ` [PATCH 03/11] btrfs-progs: lowmem check: Fix inlined data extent ref lookup Qu Wenruo
2017-11-22  9:03 ` [PATCH 04/11] btrfs-progs: lowmem check: Fix false backref lost warning for keyed extent data ref Qu Wenruo
2017-11-22  9:03 ` [PATCH 05/11] btrfs-progs: fsck-test: Introduce test case for false data extent backref lost Qu Wenruo
2017-11-22  9:03 ` [PATCH 06/11] btrfs-progs: backref: Allow backref walk to handle direct parent ref Qu Wenruo
2017-11-22  9:03 ` [PATCH 07/11] btrfs-progs: lowmem check: Fix function call stack overflow caused by wrong tree reloc tree detection Qu Wenruo
2017-11-22  9:03 ` [PATCH 08/11] btrfs-progs: lowmem check: Fix false alerts for image with shared block ref only backref Qu Wenruo
2017-11-22  9:03 ` Qu Wenruo [this message]
2017-11-22  9:03 ` [PATCH 11/11] btrfs-progs: fsck-tests: Introduce test case with keyed data backref with shared tree blocks Qu Wenruo
2017-11-24 14:46 ` [PATCH 00/11] Lowmem mode btrfs fixes exposed by complex tree David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171122090325.29458-11-wqu@suse.com \
    --to=wqu@suse.com \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).