From patchwork Sun Dec 10 23:50:00 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Qu Wenruo X-Patchwork-Id: 10104065 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 325BF60223 for ; Sun, 10 Dec 2017 23:50:25 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 185762919C for ; Sun, 10 Dec 2017 23:50:25 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id EEBF0291CC; Sun, 10 Dec 2017 23:50:24 +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=-6.9 required=2.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_HI,T_TVD_MIME_EPI 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 7C7252919C for ; Sun, 10 Dec 2017 23:50:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751602AbdLJXuI (ORCPT ); Sun, 10 Dec 2017 18:50:08 -0500 Received: from mout.gmx.net ([212.227.17.22]:56097 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751347AbdLJXuH (ORCPT ); Sun, 10 Dec 2017 18:50:07 -0500 Received: from [0.0.0.0] ([45.32.131.59]) by mail.gmx.com (mrgmx103 [212.227.17.174]) with ESMTPSA (Nemesis) id 0MA9FV-1eCw0T2wor-00BNTl; Mon, 11 Dec 2017 00:50:05 +0100 Subject: Re: Chunk-Recovery fails with alignment error To: Benjamin Beichler Cc: linux-btrfs@vger.kernel.org References: <211ded6e-5b02-0c33-b75e-b0ad6ff30ca4@gmx.com> <2f4346d5-ccb9-8de2-11d1-b270058723c1@gmx.com> <80e80ca8-5fbe-d0c9-c389-28df820f01dd@gmx.com> From: Qu Wenruo Message-ID: <4b8d8cfe-de39-b587-075a-65a502bf5e08@gmx.com> Date: Mon, 11 Dec 2017 07:50:00 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: X-Provags-ID: V03:K0:W57C1lTorhVXougyH1lH6A4jyhJSnOck7+x39cR/nbiuspb6bHY TGXXv83mJG1bkl3t0tc1sNW8gEFpjMa7eMFEy71EWij7bhwXPsq88DbngcS8ClNB171S/pv AWP9De+ZtBzsL5y6Qt3P11arCdnWcApjGJIlFoKbkk7re9ByjWVGYgmzYjMECKjFVJDzoqb HjebxK9ZOo53e0qPgQ0zg== X-UI-Out-Filterresults: notjunk:1; V01:K0:7N4Lrl5rMPM=:qJEVE+CIfgCdm8/DeY6c1p FX5KB5i6EkxbsHOufSZ3vPLQ1rNdeqKlfvdHM4OHqpEX7R/7/Rb6PRKUpBApsQZYMLSewC3qk oQryFBJpOk/8yhWmMsONdWTkELH+C0JpZtkI1fU96lT/cSzX0HMzY0fMgfJxdOBrwubMvdiXY X+s+YYFjCD+yPKq72WjP1RZ1E/KDM6rWxe7n33bF+CHYs14IqRbfno+rxE4FplmX8iNhhXhQ7 erCtz0ec4O0J9OmU8TBqyJ+E2/5cU94Q1egxRE756V5aGi3cAaM9lofR2a6ql3hVS5C4bOr4g 0lSZrfm/gwLsRFBy+Xx0D30lve4yFAjnchLfLdYuQRPM69bW0WuPCapq/aVWu/mSlI/lP9diC D17K9Cr3eN+mkrESdfXo6oilK4rNitraSpwvYAQolxC20ZuxakUTiK4yQXe+b+uY4n97zEVwj LI8TZTfZb/A/3eWbMdsdBR9JddN9qpR+PXqfT2vVvLI3q6on/2llAvMhmeJH7TjgZpMZf+lG0 DImROQVQOXrml/VSRE6TLo3rVNEhIgBh5sj6b9G4m2sUn8k3XR9B4GVrQuopoN9rVTaL+nNAz 6T0gYoaIt2pH6uh/FxdW4fN71YWIKNeD24GH70LGsOvTmALZ5/dRjUTSRD+e3sYjhPrFoOlX9 aNqsgC+jtAq3lFEZ/odAZ3eJWKELYQA/o2OwO6JC1LiBaHS0HDleSpAXKOh1qM3KDEsDJRp8H e0ydO7tUrQmlKGVf2BqUVJku9RABKSS/RS6sIFsmmuC8MG0EDNSObS1X/azAHhPURo2XjFOgO 85VnQPtymxeta0M32QZ255/2OkNjg== 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 On 2017年12月11日 05:16, Benjamin Beichler wrote: > The patch let the chunk-recover be successful. But I'm no lucky man, > the recovered chunk tree does not work or other metadata is also > broken. > > Mounting the system is not successful (dmesg): > BTRFS critical (device dm-0): corrupt node, invalid item slot: > block=16384, root=1, slot=0 > BTRFS error (device dm-0): failed to read chunk root > BTRFS error (device dm-0): open_ctree failed For this error, you could apply this diff to by-pass it: ------ "unaligned pointer, have %llu should be aligned to %u", ------ Thanks, Qu > > Therefore I tried a btrfs check --repair, this time without error: > https://gist.github.com/anonymous/5cf7ad9e187032d2c94db4f91bb62c24 > > Then I tried btrfs check --init-extent-tree and this produces much > output. I put the beginning into here: > https://gist.github.com/anonymous/70e2482646a8235ee2327105d920dadd > From a fast view, the messages keep to be similar to the last of the > gist, but the messages in the beginning are not repeating. If it helps > I have complete compressed log. > > Then I tried a btrfs recover to get files, but for many files (also > improtant data, but I filtered the output) I get outputs like in: > https://gist.github.com/anonymous/1cc7f7ab5af33e76d0bf80960bb300eb > > Any new suggestions? > diff --git a/fs/btrfs/tree-checker.c b/fs/btrfs/tree-checker.c index ce4ed6ec8f39..355220e21c2e 100644 --- a/fs/btrfs/tree-checker.c +++ b/fs/btrfs/tree-checker.c @@ -413,12 +413,6 @@ int btrfs_check_node(struct btrfs_root *root, struct extent_buffer *node) btrfs_node_key_to_cpu(node, &key, slot); btrfs_node_key_to_cpu(node, &next_key, slot + 1); - if (!bytenr) { - generic_err(root, node, slot, - "invalid NULL node pointer"); - ret = -EUCLEAN; - goto out; - } if (!IS_ALIGNED(bytenr, root->fs_info->sectorsize)) { generic_err(root, node, slot,