| Message ID | 1393242914-21867-1-git-send-email-wangsl.fnst@cn.fujitsu.com (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Headers | show |
On Mon, Feb 24, 2014 at 5:55 AM, Wang Shilong <wangsl.fnst@cn.fujitsu.com> wrote: > We found btrfsck will output backrefs mismatch while the filesystem > is defenitely ok. > > The problem is that check_block() don't return right value,which > makes btrfsck won't walk all tree blocks thus we don't get a consistent > filesystem, we will fail to check extent refs etc. > > Reported-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com> > Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com> > --- > cmds-check.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/cmds-check.c b/cmds-check.c > index a2afae6..253569f 100644 > --- a/cmds-check.c > +++ b/cmds-check.c > @@ -2477,7 +2477,7 @@ static int check_block(struct btrfs_trans_handle *trans, > struct cache_extent *cache; > struct btrfs_key key; > enum btrfs_tree_block_status status; > - int ret = 1; > + int ret = 0; > int level; > > cache = lookup_cache_extent(extent_cache, buf->start, buf->len); > -- I tried this fix on a broken btrfs volume I've been trying to repair, and it seemed to put me in an infinite loop. I agree that something seems wrong with the way the caller of check_block uses the return value, and I also noticed that it seemed to exit before walking all the tree blocks. But I think the problem is more subtle than flipping the default ret value from 1 to 0. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Mitch, On 02/25/2014 07:03 AM, Mitch Harder wrote: > On Mon, Feb 24, 2014 at 5:55 AM, Wang Shilong > <wangsl.fnst@cn.fujitsu.com> wrote: >> We found btrfsck will output backrefs mismatch while the filesystem >> is defenitely ok. >> >> The problem is that check_block() don't return right value,which >> makes btrfsck won't walk all tree blocks thus we don't get a consistent >> filesystem, we will fail to check extent refs etc. >> >> Reported-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com> >> Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com> >> --- >> cmds-check.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/cmds-check.c b/cmds-check.c >> index a2afae6..253569f 100644 >> --- a/cmds-check.c >> +++ b/cmds-check.c >> @@ -2477,7 +2477,7 @@ static int check_block(struct btrfs_trans_handle *trans, >> struct cache_extent *cache; >> struct btrfs_key key; >> enum btrfs_tree_block_status status; >> - int ret = 1; >> + int ret = 0; >> int level; >> >> cache = lookup_cache_extent(extent_cache, buf->start, buf->len); >> -- > I tried this fix on a broken btrfs volume I've been trying to repair, > and it seemed to put me in an infinite loop. > > I agree that something seems wrong with the way the caller of > check_block uses the return value, and I also noticed that it seemed > to exit before walking all the tree blocks. > > But I think the problem is more subtle than flipping the default ret > value from 1 to 0. No, not really even though i know there are other problems with fsck repair mode. But this problem should be fixed and pushed into btrfs-progsv3.13.(Notice, the below problem did not exist in btrfs-progsv3.12) An easy way to trigger this problem: # mkfs.btrfs -f /dev/sda9 # mount /dev/sda9 /mnt # dd if=/dev/zero of=/mnt/data bs=4k count=10240 oflag=direct # btrfs sub snapshot /mnt /mnt/snap1 # btrfs sub snapshot /mnt /mnt/snap2 # umount /mnt # btrfs check /dev/sda9 After applying this patch, the above problems did not exist. Feel free to correct me if i miss something here.^_^ Thanks, Wang > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/cmds-check.c b/cmds-check.c index a2afae6..253569f 100644 --- a/cmds-check.c +++ b/cmds-check.c @@ -2477,7 +2477,7 @@ static int check_block(struct btrfs_trans_handle *trans, struct cache_extent *cache; struct btrfs_key key; enum btrfs_tree_block_status status; - int ret = 1; + int ret = 0; int level; cache = lookup_cache_extent(extent_cache, buf->start, buf->len);
We found btrfsck will output backrefs mismatch while the filesystem is defenitely ok. The problem is that check_block() don't return right value,which makes btrfsck won't walk all tree blocks thus we don't get a consistent filesystem, we will fail to check extent refs etc. Reported-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com> Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com> --- cmds-check.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)