From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0A510C2D0CE for ; Mon, 30 Dec 2019 09:21:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D8E8F20663 for ; Mon, 30 Dec 2019 09:21:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727320AbfL3JVg convert rfc822-to-8bit (ORCPT ); Mon, 30 Dec 2019 04:21:36 -0500 Received: from mail-ot1-f68.google.com ([209.85.210.68]:45035 "EHLO mail-ot1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727310AbfL3JVg (ORCPT ); Mon, 30 Dec 2019 04:21:36 -0500 Received: by mail-ot1-f68.google.com with SMTP id h9so42928036otj.11 for ; Mon, 30 Dec 2019 01:21:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ULl1uc6HW6X9bHzhIUlNiafKQdm3dkUlJ7IN1ObRsQ0=; b=ZFRscXr0P+Q1PmKr5VQpU84NvUklmoRenETQWz7tDBfvt/iwP4HUezIjikRPLB1KV2 hTM2mZbGCytA3/GhD8ziPP3AgLA0VV9dkUYgTxVGgOx+bjjuofuNKPzDKyFWsYr9Li6o mwSMlP8TiSCenVzr2AT9TmuxLJyUUao4461pqfRkwN0A2t0UB6dfu3RfV23dpZjFEkbM atZMgS35T+9cXcFC5WFErFSEquOCL8xmEOAJIA4zQ3LaqEg9HgoOtLwUe4AGkF8yv0TZ 1+/YCZvpElAJfKBRC7uuMNjypi1Q5gnI7O2RfuRmnYb8XHugxH54ZK+0GSGBcgZdbrrH WzOw== X-Gm-Message-State: APjAAAVOjckAx5Zfaw/gE4KFwoCwMgkhyqolbC8kq0BEIzzPeMLDpyoR +zHqmPAjaeP0Rk7cAfYX2b3vuG75nRRFourXKK2P5oSA X-Google-Smtp-Source: APXvYqxYqrycYEJ3asy3AjmEozvWF4YjF6k10hPNiozNloPuCuVt5rjy0WHk4UR6usfHQ2Km08dAtLmGdJKw3yM/BTc= X-Received: by 2002:a05:6830:1251:: with SMTP id s17mr71869690otp.108.1577697695165; Mon, 30 Dec 2019 01:21:35 -0800 (PST) MIME-Version: 1.0 References: <4bf17941-2ab0-15ca-b4c9-f6ba037624ee@gmx.com> <66d35620-160e-105a-6970-03c3de3f7c78@gmx.com> <4c06d3a9-7f09-c97c-a6f3-c7f7419d16a7@gmx.com> <27a9570c-70cc-19b6-3f5f-cd261040a67c@gmx.com> <4a28f224-a602-61e7-3404-68a4414df81c@gmx.com> In-Reply-To: <4a28f224-a602-61e7-3404-68a4414df81c@gmx.com> From: Patrick Erley Date: Mon, 30 Dec 2019 09:21:24 +0000 Message-ID: Subject: Re: read time tree block corruption detected To: Qu Wenruo Cc: Btrfs BTRFS Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Mon, Dec 30, 2019 at 9:09 AM Qu Wenruo wrote: > > > > On 2019/12/30 下午5:01, Patrick Erley wrote: > > On Mon, Dec 30, 2019 at 8:54 AM Qu Wenruo wrote: > >> On 2019/12/30 下午4:14, Patrick Erley wrote: > >>> On Mon, Dec 30, 2019 at 6:09 AM Qu Wenruo wrote: > >>> > >>> Should I also paste in the repair log? > >>> > >> Yes please. > >> > >> This sounds very strange, especially for the transid mismatch part. > >> > >> Thanks, > >> Qu > >> > > > > > > > > enabling repair mode > > WARNING: > > > > Do not use --repair unless you are advised to do so by a developer > > or an experienced user, and then only after having accepted that no > > fsck can successfully repair all types of filesystem corruption. Eg. > > some software or hardware bugs can fatally damage a volume. > > The operation will start in 10 seconds. > > Use Ctrl-C to stop it. > > 10 9 8 7 6 5 4 3 2 1parent transid verify failed on 499774464000 > > wanted 3323349 found 3323340 > > parent transid verify failed on 499774521344 wanted 3323349 found 3323340 > > parent transid verify failed on 499774529536 wanted 3323349 found 3323340 > > This message is from open_ctree(), which means the fs is already corrupted. > > Would you like to provide the history between last good btrfs check run > and --repair run? > > Thanks, > Qu In theory, all I did was boot back into 5.1 and continued using the system. After you said I should go ahead and try to --repair, I rebooted into initramfs and ran the repair, then continued booting(which failed spectacularly, due to almost all of / being missing). I then rebooted back into initramfs to assess what was going on, and made a liveusb (from which I'm sending this on that system). Some 'background' on the FS: It was migrated from ext4 ~7? years ago, and has been moved between multiple discs and systems using dd. Interesting point: The only files/folders that still exist in / were created after I migrated the filesystem. If I can get /etc and maybe /var back, I'm golden (there are a few bits in each I don't include in my hot backups, so will have to go to offline storage to fetch them).