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 E29E8C2D0C2 for ; Mon, 30 Dec 2019 10:06:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B4EDE206E4 for ; Mon, 30 Dec 2019 10:06:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727348AbfL3KGn convert rfc822-to-8bit (ORCPT ); Mon, 30 Dec 2019 05:06:43 -0500 Received: from mail-ot1-f66.google.com ([209.85.210.66]:33989 "EHLO mail-ot1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727320AbfL3KGn (ORCPT ); Mon, 30 Dec 2019 05:06:43 -0500 Received: by mail-ot1-f66.google.com with SMTP id a15so45689274otf.1 for ; Mon, 30 Dec 2019 02:06:41 -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=Sgkus2SqdNySMY+5l8CxmOI6cbvCJ3H8qjblegj7sZ4=; b=O425N/RkTkr5uD1n1ij2Bq+8bxTO32VWTqbcTS6XooNErQVa1W6NKaSnmx82U236bV QYbo2cP+xm+tEJVVxN4Lyn9LiX69OODiehMyIbHe+VAw54vj/Yb+8kUYXgB1RyTo8Vtp n/tqRfB0YjZlPOsyAVAaOvgjxNvoJGJTynHeaBNuUKbJ1ea5Um7UhwghcGJeXO/DEPW0 cW3ujHmKdnB28vzUFfoTSJ8IIngMwJ0YQ49CrRGkcD0MTGuPpcfVfkaCFJVemlLz/FKv ie248/sNSwB/RkSuJAoAsj69RhMfGE5zZ2EEmhaijMWM5kqZvohZnkvdIFUq3R7Gm8E5 7umw== X-Gm-Message-State: APjAAAV+jPymrl2LWfteHCZeE/m/2p7tfyYNPUbTBC9rt6V5NK8TpaPb hghotIcBv2btON346cAI2UIrD+T7OGkbNyqSWe1ekw99 X-Google-Smtp-Source: APXvYqxs+YmiNZxaJEtfANyn/EHPFciyuW50F0hwR4M8M9Xc5oJk1nX6+aCrUJLt+POKhcKqO1kg/6H5OIvU3pdiiSg= X-Received: by 2002:a9d:7ac9:: with SMTP id m9mr70388084otn.80.1577700401274; Mon, 30 Dec 2019 02:06:41 -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> <278545c8-3267-b6d2-8e0e-5de6be572946@gmx.com> In-Reply-To: <278545c8-3267-b6d2-8e0e-5de6be572946@gmx.com> From: Patrick Erley Date: Mon, 30 Dec 2019 10:06:30 +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 That sucks :-( The only reason I had hope for /etc and /var was they show up in btrfs check as not having a parent and i figured I could reparent them onto the new / and have a chance of extracting something useful from them. I guess I'll plan on grabbing images of the FS tomorrow and starting a full rebuild. Hopefully someone will chime in with a way to get /etc/ and /var/ before I reach the point I need them. On Mon, Dec 30, 2019 at 9:27 AM Qu Wenruo wrote: > > > > On 2019/12/30 下午5:21, Patrick Erley wrote: > > 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. > > If that's the only thing before --repair (if there is only one repair > run, and output is exactly what you pasted), then I guess something > didn't go right in that 5.1 run? > > Is that pasted output from the first --repair run? > > If there is another run before the pasted output, then it could be > previous --repair. > > Either way, I'm very sorry for the data loss... > > > 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). > > I'm afraid the only chance we left is btrfs-restore. > > And normally for transid error, the chance is pretty low then. > > Thanks, > Qu > > > >