From patchwork Tue Apr 2 18:09:55 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Mahoney X-Patchwork-Id: 10882145 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 96FF7922 for ; Tue, 2 Apr 2019 18:10:02 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 81EBF28462 for ; Tue, 2 Apr 2019 18:10:02 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 74D11284AF; Tue, 2 Apr 2019 18:10:02 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 63F072847F for ; Tue, 2 Apr 2019 18:10:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730032AbfDBSKA (ORCPT ); Tue, 2 Apr 2019 14:10:00 -0400 Received: from mx2.suse.de ([195.135.220.15]:49178 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725889AbfDBSJ7 (ORCPT ); Tue, 2 Apr 2019 14:09:59 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id C3160AC86 for ; Tue, 2 Apr 2019 18:09:58 +0000 (UTC) Received: from starscream.home.jeffm.io (starscream-1.home.jeffm.io [192.168.1.254]) by mail.home.jeffm.io (Postfix) with ESMTPS id A0EC2801432F; Tue, 2 Apr 2019 14:09:47 -0400 (EDT) Received: by starscream.home.jeffm.io (Postfix, from userid 1000) id 5EC993E7FFA; Tue, 2 Apr 2019 14:09:57 -0400 (EDT) From: jeffm@suse.com To: linux-btrfs@vger.kernel.org Cc: Jeff Mahoney Subject: [PATCH 1/2] btrfs-progs: check: run delayed refs after writing out dirty block groups Date: Tue, 2 Apr 2019 14:09:55 -0400 Message-Id: <20190402180956.28893-1-jeffm@suse.com> X-Mailer: git-send-email 2.16.4 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Jeff Mahoney When repairing the extent tree, it's possible for delayed extents to be created when running btrfs_write_dirty_block_groups. We run delayed refs one last time in the kernel but that is missing in the userspace tools. That results in delayed refs getting dropped on the floor, the extent records not getting created, and in the next tranaction, when the extent tree is CoW'd again, we hit the BUG_ON when we can't find the extent record. We can fix this by running the delayed refs after writing out the dirty block groups. Signed-off-by: Jeff Mahoney --- transaction.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/transaction.c b/transaction.c index e756db33..2f19e9c8 100644 --- a/transaction.c +++ b/transaction.c @@ -194,6 +194,8 @@ commit_tree: ret = btrfs_run_delayed_refs(trans, -1); BUG_ON(ret); btrfs_write_dirty_block_groups(trans); + ret = btrfs_run_delayed_refs(trans, -1); + BUG_ON(ret); __commit_transaction(trans, root); if (ret < 0) goto out; From patchwork Tue Apr 2 18:09:56 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Mahoney X-Patchwork-Id: 10882147 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id A9C7B17EE for ; Tue, 2 Apr 2019 18:10:02 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9167C284A5 for ; Tue, 2 Apr 2019 18:10:02 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 80B592849B; Tue, 2 Apr 2019 18:10:02 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 22B4A28462 for ; Tue, 2 Apr 2019 18:10:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730058AbfDBSKB (ORCPT ); Tue, 2 Apr 2019 14:10:01 -0400 Received: from mx2.suse.de ([195.135.220.15]:49184 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1730017AbfDBSKA (ORCPT ); Tue, 2 Apr 2019 14:10:00 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 4AEC8AC8C for ; Tue, 2 Apr 2019 18:09:59 +0000 (UTC) Received: from starscream.home.jeffm.io (starscream-1.home.jeffm.io [IPv6:2001:559:c0d4::1fe]) by mail.home.jeffm.io (Postfix) with ESMTPS id 6E18B81AD3D8; Tue, 2 Apr 2019 14:09:48 -0400 (EDT) Received: by starscream.home.jeffm.io (Postfix, from userid 1000) id 438103E7FFC; Tue, 2 Apr 2019 14:09:58 -0400 (EDT) From: jeffm@suse.com To: linux-btrfs@vger.kernel.org Cc: Jeff Mahoney Subject: [PATCH 2/2] btrfs-progs: check: fixup_extent_flags needs to deal with non-skinny metadata Date: Tue, 2 Apr 2019 14:09:56 -0400 Message-Id: <20190402180956.28893-2-jeffm@suse.com> X-Mailer: git-send-email 2.16.4 In-Reply-To: <20190402180956.28893-1-jeffm@suse.com> References: <20190402180956.28893-1-jeffm@suse.com> Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Jeff Mahoney When repairing a file system created by a very old kernel, I ran into issues fixing up the extent flags since fixup_extent_flags assumed that a METADATA_ITEM would be present if the record was for metadata. Since METADATA_ITEMs don't exist without skinny metadata, we need to fall back to EXTENT_ITEMs. This also falls back to EXTENT_ITEMs even with skinny metadata enabled as other parts of the tools do. Signed-off-by: Jeff Mahoney Reviewed-by: Filipe Manana --- check/main.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/check/main.c b/check/main.c index 7547209c..4a27a443 100644 --- a/check/main.c +++ b/check/main.c @@ -7540,9 +7540,13 @@ static int fixup_extent_flags(struct btrfs_fs_info *fs_info, struct btrfs_key key; u64 flags; int ret = 0; + bool metadata_item = rec->metadata; + if (!btrfs_fs_incompat(root->fs_info, SKINNY_METADATA)) + metadata_item = false; +retry: key.objectid = rec->start; - if (rec->metadata) { + if (metadata_item) { key.type = BTRFS_METADATA_ITEM_KEY; key.offset = rec->info_level; } else { @@ -7561,6 +7565,10 @@ static int fixup_extent_flags(struct btrfs_fs_info *fs_info, btrfs_commit_transaction(trans, root); return ret; } else if (ret) { + if (key.type == BTRFS_METADATA_ITEM_KEY) { + metadata_item = false; + goto retry; + } fprintf(stderr, "Didn't find extent for %llu\n", (unsigned long long)rec->start); btrfs_release_path(&path);