From patchwork Wed May 7 12:09:14 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Filipe Manana X-Patchwork-Id: 4127081 X-Patchwork-Delegate: dave@jikos.cz Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id F2A6A9F23C for ; Wed, 7 May 2014 11:10:56 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 1B1C2202F2 for ; Wed, 7 May 2014 11:10:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2CCC7202EB for ; Wed, 7 May 2014 11:10:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932442AbaEGLKv (ORCPT ); Wed, 7 May 2014 07:10:51 -0400 Received: from mail-wi0-f177.google.com ([209.85.212.177]:52991 "EHLO mail-wi0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932180AbaEGLKu (ORCPT ); Wed, 7 May 2014 07:10:50 -0400 Received: by mail-wi0-f177.google.com with SMTP id f8so1102454wiw.16 for ; Wed, 07 May 2014 04:10:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id; bh=a/c6VHZB9PPLpD7/d9WnImVYcTIQ52N4Bm7wtGOWeDw=; b=t4uHhghd7NYP9Ly+QQbuRUn63mZf1FRhK4Ri9RqOWgpllblkOhVaLgp1QKhkzNQq80 LAzKof0UhpJOtoZvnuV6BLLLJuGGYW/KnID3fKbKxzHjTgBNzdOGmHW3QUD5BkT5mQmo PVHQlma9C2sYb9rYJwVn4hoSfS2Y65PdL67CViX/EH21aqQAufODYGIZqGi6Z3tCAxyG +it/6fXo4Ew5cvjLvidR3i4G23HVfebleMIeqir6AYh7lzE5Md5hXuSDKWMs6OiZhDFF VL8HYaR6l3NFhiYmF4G9Y8G7V0TAGneURmizKfOSuknqSk2D+rgWbYFBxvzqZlUARdyM Rn4w== X-Received: by 10.180.73.140 with SMTP id l12mr25890683wiv.3.1399461049395; Wed, 07 May 2014 04:10:49 -0700 (PDT) Received: from debian-vm3.lan (bl14-143-112.dsl.telepac.pt. [85.247.143.112]) by mx.google.com with ESMTPSA id co9sm26172233wjb.22.2014.05.07.04.10.47 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 07 May 2014 04:10:48 -0700 (PDT) From: Filipe David Borba Manana To: linux-btrfs@vger.kernel.org Cc: Filipe David Borba Manana Subject: [PATCH] Btrfs-progs: check, fix csum check in the presence of non-inlined refs Date: Wed, 7 May 2014 13:09:14 +0100 Message-Id: <1399464554-899-1-git-send-email-fdmanana@gmail.com> X-Mailer: git-send-email 1.9.1 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP When we have non-inlined extent references, we were failing to find the corresponding extent item for an existing csum item in the csum tree. Reproducer: mkfs.btrfs -f /dev/sdd mount /dev/sdd /mnt xfs_io -f -c "falloc 780366 135302" /mnt/foo xfs_io -c "falloc 327680 151552" /mnt/foo xfs_io -c "pwrite -S 0xff -b 131072 0 131072" /mnt/foo sync for i in `seq 1 40`; do btrfs subvolume snapshot /mnt /mnt/snap$i ; done umount /mnt btrfs check /dev/sdd The check command exited with status 1 and the following output: Checking filesystem on /dev/sdd UUID: 2416ab5f-9d71-457e-bb13-a27d4f6b399a checking extents checking free space cache checking fs roots checking csums There are no extents for csum range 12980224-12984320 Csum exists for 12980224-12984320 but there is no extent record found 1388544 bytes used err is 1 total csum bytes: 132 total tree bytes: 704512 total fs tree bytes: 573440 total extent tree bytes: 16384 btree space waste bytes: 564479 file data blocks allocated: 19341312 referenced 14606336 Btrfs v3.14.1-94-g80597e7 After this change it no longer erroneously reports a missing extent for the csum item and exits with a status of 0. Also added missing btrfs_prev_leaf() return value checks, as we were ignoring errors and non-existence of left siblings completely. Signed-off-by: Filipe David Borba Manana --- cmds-check.c | 38 +++++++++++++++++++++++++++----------- 1 file changed, 27 insertions(+), 11 deletions(-) diff --git a/cmds-check.c b/cmds-check.c index 103efc5..18612c8 100644 --- a/cmds-check.c +++ b/cmds-check.c @@ -3650,8 +3650,7 @@ static int check_extent_exists(struct btrfs_root *root, u64 bytenr, key.objectid = bytenr; key.type = BTRFS_EXTENT_ITEM_KEY; - key.offset = 0; - + key.offset = (u64)-1; again: ret = btrfs_search_slot(NULL, root->fs_info->extent_root, &key, path, @@ -3661,10 +3660,17 @@ again: btrfs_free_path(path); return ret; } else if (ret) { - if (path->slots[0]) + if (path->slots[0] > 0) { path->slots[0]--; - else - btrfs_prev_leaf(root, path); + } else { + ret = btrfs_prev_leaf(root, path); + if (ret < 0) { + goto out; + } else if (ret > 0) { + ret = 0; + goto out; + } + } } btrfs_item_key_to_cpu(path->nodes[0], &key, path->slots[0]); @@ -3674,13 +3680,22 @@ again: * bytenr, so walk back one more just in case. Dear future traveler, * first congrats on mastering time travel. Now if it's not too much * trouble could you go back to 2006 and tell Chris to make the - * BLOCK_GROUP_ITEM_KEY lower than the EXTENT_ITEM_KEY please? + * BLOCK_GROUP_ITEM_KEY (and BTRFS_*_REF_KEY) lower than the + * EXTENT_ITEM_KEY please? */ - if (key.type == BTRFS_BLOCK_GROUP_ITEM_KEY) { - if (path->slots[0]) + while (key.type > BTRFS_EXTENT_ITEM_KEY) { + if (path->slots[0] > 0) { path->slots[0]--; - else - btrfs_prev_leaf(root, path); + } else { + ret = btrfs_prev_leaf(root, path); + if (ret < 0) { + goto out; + } else if (ret > 0) { + ret = 0; + goto out; + } + } + btrfs_item_key_to_cpu(path->nodes[0], &key, path->slots[0]); } while (num_bytes) { @@ -3752,7 +3767,8 @@ again: } ret = 0; - if (num_bytes) { +out: + if (num_bytes && !ret) { fprintf(stderr, "There are no extents for csum range " "%Lu-%Lu\n", bytenr, bytenr+num_bytes); ret = 1;