All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Pernegger <pernegger@gmail.com>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: first it froze, now the (btrfs) root fs won't mount ...
Date: Sat, 26 Oct 2019 11:23:20 +0200	[thread overview]
Message-ID: <CAKbQEqFWiGdgJNSWOwvHkHGjrXu=2x0zAK-n9T-oza7qexwz7g@mail.gmail.com> (raw)
In-Reply-To: <503118ac-877f-989c-50f2-5e2a3d0b58d8@gmx.com>

Am Sa., 26. Okt. 2019 um 02:01 Uhr schrieb Qu Wenruo <quwenruo.btrfs@gmx.com>:
> It's already working, the problem is, there is a dirty log while
> nologreplay mount option doesn't really work.

For the record, I didn't try to mount using nologreplay, only
notreelog. (Apologies if notreelog and/or skipbg imply nologreplay.)

> You can btrfs-zero-log to clear the log, then try again using skipbg
> mount option.

I don't think I can, actually. At least, zeroing the log didn't work
back when btrfs check --repair was still in the table. Admittedly,
that was using Ubuntu eoan's 5.3 kernel, not yours, and with their
btrfs-progs (5.2.1); I don't think I'd gotten around to compiling
btrfs-progs 5.3, yet. So if you think trying again with the
rescue_options kernel and/or latest btrfs-progs might allow me to zero
the log, I'll try again.
Alternatively, using backup super 1 or 2 got me past that hurdle with
btrfs check --repair, so if there's an option to mount using one of
these ...?
(Output quoted below for reference.)

> > $ btrfs check --init-extent-tree patient
> > Opening filesystem to check...
> > Checking filesystem on patient
> > UUID: c2bd83d6-2261-47bb-8d18-5aba949651d7
> > repair mode will force to clear out log tree, are you sure? [y/N]: y
> > ERROR: Corrupted fs, no valid METADATA block group found
> > ERROR: failed to zero log tree: -117
> > ERROR: attempt to start transaction over already running one
> > # rollback
> >
> > $ btrfs rescue zero-log patient
> > checksum verify failed on 284041084928 found E4E3BDB6 wanted 00000000
> > checksum verify failed on 284041084928 found E4E3BDB6 wanted 00000000
> > bad tree block 284041084928, bytenr mismatch, want=284041084928, have=0
> > ERROR: could not open ctree
> > # rollback
> >
> > # hm, super 0 has log_root 284056535040, super 1 and 2 have log_root 0 ...
> > [...]

> And thanks for the report, I'll look into why nologreplay doesn't work.

On the contrary, thank you! It's the least I can do. If there's
anything else I can to help make it less likely (something like) this
bites me or anyone else again, just say the word. Also, I'm curious as
to the state of the data and btrfs restore doesn't care about
checksums, so I'd love to be able to ro-mount the image sometime.

Cheers,
C.

  reply	other threads:[~2019-10-26  9:27 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAKbQEqE7xN1q3byFL7-_pD=_pGJ0Vm9pj7d-g+rRgtONeH-GrA@mail.gmail.com>
2019-10-19 22:34 ` first it froze, now the (btrfs) root fs won't mount Christian Pernegger
2019-10-20  0:38   ` Qu Wenruo
2019-10-20 10:11     ` Christian Pernegger
2019-10-20 10:22       ` Christian Pernegger
2019-10-20 10:28         ` Qu Wenruo
2019-10-21 10:47           ` Christian Pernegger
2019-10-21 10:55             ` Qu Wenruo
2019-10-21 11:47             ` Austin S. Hemmelgarn
2019-10-21 13:02               ` Christian Pernegger
2019-10-21 13:34                 ` Qu Wenruo
2019-10-22 22:56                   ` Christian Pernegger
2019-10-23  0:25                     ` Qu Wenruo
2019-10-23 11:31                     ` Austin S. Hemmelgarn
2019-10-24 10:41                       ` Christian Pernegger
2019-10-24 11:26                         ` Qu Wenruo
2019-10-24 11:40                         ` Austin S. Hemmelgarn
2019-10-25 16:43                           ` Christian Pernegger
2019-10-25 17:05                             ` Christian Pernegger
2019-10-25 17:16                               ` Austin S. Hemmelgarn
2019-10-25 17:12                             ` Austin S. Hemmelgarn
2019-10-26  0:01                             ` Qu Wenruo
2019-10-26  9:23                               ` Christian Pernegger [this message]
2019-10-26  9:41                                 ` Qu Wenruo
2019-10-26 13:52                                   ` Christian Pernegger
2019-10-26 14:06                                     ` Qu Wenruo
2019-10-26 16:30                                       ` Christian Pernegger
2019-10-27  0:46                                         ` Qu Wenruo
     [not found]                                           ` <CAKbQEqFne8eohE3gvCMm8LqA-KimFrwwvE5pUBTn-h-VBhJq1A@mail.gmail.com>
2019-10-27 13:38                                             ` Qu Wenruo
2019-10-21 14:02                 ` Austin S. Hemmelgarn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKbQEqFWiGdgJNSWOwvHkHGjrXu=2x0zAK-n9T-oza7qexwz7g@mail.gmail.com' \
    --to=pernegger@gmail.com \
    --cc=ahferroin7@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.