All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miao Xie <miaox@cn.fujitsu.com>
To: Linux Btrfs <linux-btrfs@vger.kernel.org>, David Sterba <dave@jikos.cz>
Subject: Re: [RFC PATCH] Btrfs: fix full backref problem when inserting shared block reference
Date: Tue, 21 Aug 2012 14:24:19 +0800	[thread overview]
Message-ID: <50332993.1000902@cn.fujitsu.com> (raw)
In-Reply-To: <20120809072129.GC17430@twin.jikos.cz>

On Thu, 9 Aug 2012 09:21:29 +0200, David Sterba wrote:
> On Thu, Aug 09, 2012 at 08:48:02AM +0200, David Sterba wrote:
>> and down, no problems so far, and the "wikipedia" test-subvol stresstest
>> that caused trouble to one of your patches is also ok. I'll do some more
>> testing on other machines and will report problems eventually.
> 
> So it won't be so easy :)
> 
> The test generated 15+ G of data, ~500 snapshots, then umount and fsck:
> 
> lots of
> 
> ref mismatch on [9655283712 4096] extent item 1, found 0
> Incorrect local backref count on 9655283712 root 5 owner 589776 offset 110592 found 0 wanted 1 back 0x86badf0
> backpointer mismatch on [9655283712 4096]
> owner ref check failed [9655283712 4096]

By debuging, I found it should be a bug of btrfsck.
Could you try this patch?

Thanks
Miao

>From 77e9bcaae464354c0b0176631ba51374e3d31cfc Mon Sep 17 00:00:00 2001
From: Miao Xie <miaox@cn.fujitsu.com>
Date: Tue, 21 Aug 2012 14:16:27 +0800
Subject: [PATCH] Btrfs-progs: fix wrong return value of check_owner_ref()

If we find the block by seach corresponding fs tree, we should return 0,
and tell the caller we pass the check.

Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
---
 btrfsck.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/btrfsck.c b/btrfsck.c
index 4e91769..57e7b57 100644
--- a/btrfsck.c
+++ b/btrfsck.c
@@ -1954,7 +1954,7 @@ static int check_owner_ref(struct btrfs_root *root,
 
 	if (buf->start == btrfs_node_blockptr(path.nodes[level + 1],
 					      path.slots[level + 1]))
-		rec->owner_ref_checked = 1;
+		found = 1;
 
 	btrfs_release_path(ref_root, &path);
 	return found ? 0 : 1;
-- 
1.7.6.5

> and then
> 
> checking fs roots
> root 2854 inode 233882 errors 2500
> root 2880 inode 271639 errors 2200
> 
> and it's not finished yet, other types of error may pop up.


  parent reply	other threads:[~2012-08-21  6:43 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-09  3:10 [RFC PATCH] Btrfs: fix full backref problem when inserting shared block reference Miao Xie
2012-08-09  6:48 ` David Sterba
2012-08-09  7:21   ` David Sterba
2012-08-09  7:50     ` Miao Xie
2012-08-10 10:38     ` Miao Xie
2012-08-21  6:24     ` Miao Xie [this message]
2012-08-09 12:23 ` Josef Bacik
2012-08-09 13:11   ` Chris Mason
2012-08-09 13:12     ` Josef Bacik
2012-08-09 13:16       ` Chris Mason
2012-08-09 18:04 ` Chris Mason
2012-08-10 10:38   ` Miao Xie
2012-08-10 11:56     ` Chris Mason
2013-01-30 18:23       ` Alex Lyakas
2013-01-31  2:42         ` Miao Xie
2013-01-31 13:06           ` Alex Lyakas

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=50332993.1000902@cn.fujitsu.com \
    --to=miaox@cn.fujitsu.com \
    --cc=dave@jikos.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.