All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Roller <sebastian.roller@gmail.com>
To: "Dāvis Mosāns" <davispuh@gmail.com>
Cc: Chris Murphy <lists@colorremedies.com>,
	Btrfs BTRFS <linux-btrfs@vger.kernel.org>,
	quwenruo.btrfs@gmx.com
Subject: Re: All files are damaged after btrfs restore
Date: Wed, 17 Mar 2021 11:50:16 +0100	[thread overview]
Message-ID: <CALS+qHM0Zvcu60dbAwO1GtrsFyHMfhpRM-FmFeu6+aeo9X4wEA@mail.gmail.com> (raw)
In-Reply-To: <CAOE4rSxJdEB+==k3RpOPScrh8RXQ-+Q0cpR8AKSbv3DV8L=FTw@mail.gmail.com>

Am Mi., 17. März 2021 um 02:54 Uhr schrieb Dāvis Mosāns <davispuh@gmail.com>:

> > root@hikitty:~$ install/btrfs-progs-5.9/btrfs check --readonly /dev/sdi1
> > Opening filesystem to check...
> > checksum verify failed on 99593231630336 found 000000B6 wanted 00000000
> > checksum verify failed on 124762809384960 found 000000B6 wanted 00000000
> > checksum verify failed on 124762809384960 found 000000B6 wanted 00000000
> > checksum verify failed on 124762809384960 found 000000B6 wanted 00000000
> > bad tree block 124762809384960, bytenr mismatch, want=124762809384960, have=0
> > ERROR: failed to read block groups: Input/output error
> > ERROR: cannot open file system
>
> One possible reason could be that extent tree is corrupted. Right now
> I'm dealing with such filesystem.
> I wrote a patch that allows to read-only mount such filesystem
> (assuming there's no other problems).
>
> Currently none of btrfs tools work when extent tree is corrupted, but
> for `btrfs check` this patch would allow it to go further. Only for
> data recovery this isn't really that useful.
>
> --- a/check/main.c
> +++ b/check/main.c
> @@ -10197,7 +10197,7 @@ static int cmd_check(const struct cmd_struct
> *cmd, int argc, char **argv)
> int qgroup_report = 0;
> int qgroups_repaired = 0;
> int qgroup_verify_ret;
> -       unsigned ctree_flags = OPEN_CTREE_EXCLUSIVE;
> +       unsigned ctree_flags = OPEN_CTREE_EXCLUSIVE |
> OPEN_CTREE_NO_BLOCK_GROUPS;
> int force = 0;
>
> while(1) {

The patch works fine. Btrfs check is now running and I'm getting "bad
tree block  … have=0" for a lot of blocks. It supports the point of
Chris and Qu that some parts of the filesystem are missing completely.
I will have to look again into the hardware.
Thank you.

root@hikitty:~/install/btrfs-progs-5.11-patch$ ./btrfs check
--readonly /dev/sdi1
Opening filesystem to check...
Checking filesystem on /dev/sdi1
UUID: 56051c5f-fca6-4d54-a04e-1c1d8129fe56
[1/7] checking root items
checksum verify failed on 99593231630336 found 000000B6 wanted 00000000
checksum verify failed on 93744341237760 found 000000B6 wanted 00000000
checksum verify failed on 134571939774464 found 000000B6 wanted 00000000
checksum verify failed on 134571939774464 found 000000B6 wanted 00000000
checksum verify failed on 134571939774464 found 000000B6 wanted 00000000
bad tree block 134571939774464, bytenr mismatch, want=134571939774464, have=0
ERROR: failed to repair root items: Input/output error
[2/7] checking extents
checksum verify failed on 114674562678784 found 000000B6 wanted 00000000
checksum verify failed on 57137668423680 found 000000B6 wanted 00000000
checksum verify failed on 113640702476288 found 000000B6 wanted 00000000
checksum verify failed on 113640702476288 found 000000B6 wanted 00000000
checksum verify failed on 113640702476288 found 000000B6 wanted 00000000
bad tree block 113640702476288, bytenr mismatch, want=113640702476288, have=0
ERROR: errors found in extent allocation tree or chunk allocation
[3/7] checking free space cache
[4/7] checking fs roots
checksum verify failed on 121433146130432 found 000000B6 wanted 00000000
checksum verify failed on 122593932312576 found 000000B6 wanted 00000000
checksum verify failed on 136599398825984 found 000000B6 wanted 00000000
checksum verify failed on 101807915597824 found 000000B6 wanted 00000000
checksum verify failed on 57164715065344 found 000000B6 wanted 00000000
checksum verify failed on 96553819602944 found 000000B6 wanted 00000000
checksum verify failed on 117685684518912 found 000000B6 wanted 00000000
checksum verify failed on 94429572694016 found 000000B6 wanted 00000000
checksum verify failed on 103132624437248 found 000000B6 wanted 00000000
checksum verify failed on 136601755516928 found 000000B6 wanted 00000000
checksum verify failed on 57973615050752 found 000000B6 wanted 00000000
checksum verify failed on 121433143312384 found 000000B6 wanted 00000000
checksum verify failed on 136602075971584 found 000000B6 wanted 00000000
checksum verify failed on 57973809496064 found 000000B6 wanted 00000000
checksum verify failed on 110464911507456 found 000000B6 wanted 00000000
checksum verify failed on 57602967863296 found 000000B6 wanted 00000000
checksum verify failed on 121020084862976 found 000000B6 wanted 00000000
checksum verify failed on 122343797145600 found 000000B6 wanted 00000000
checksum verify failed on 136601758367744 found 000000B6 wanted 00000000
checksum verify failed on 58255412936704 found 000000B6 wanted 00000000
checksum verify failed on 98233031737344 found 000000B6 wanted 00000000
checksum verify failed on 112202434707456 found 000000B6 wanted 00000000
checksum verify failed on 112202434707456 found 000000B6 wanted 00000000
checksum verify failed on 112202434707456 found 000000B6 wanted 00000000
bad tree block 112202434707456, bytenr mismatch, want=112202434707456, have=0
checksum verify failed on 112202478764032 found 000000B6 wanted 00000000
checksum verify failed on 112202504568832 found 000000B6 wanted 00000000
checksum verify failed on 99302161956864 found 000000B6 wanted 00000000
checksum verify failed on 57229417267200 found 000000B6 wanted 00000000
checksum verify failed on 123018565664768 found 000000B6 wanted 00000000
checksum verify failed on 123018565664768 found 000000B6 wanted 00000000
checksum verify failed on 123018565664768 found 000000B6 wanted 00000000
bad tree block 123018565664768, bytenr mismatch, want=123018565664768, have=0
(…)
(killed the run after some minutes and a lot more of these errors)

--
Sebastian

      reply	other threads:[~2021-03-17 10:51 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-23 15:45 All files are damaged after btrfs restore Sebastian Roller
2021-02-25  5:40 ` Chris Murphy
2021-02-25  5:52   ` Chris Murphy
2021-02-26 16:01     ` Sebastian Roller
2021-02-27  1:04       ` Chris Murphy
2021-03-04 15:34         ` Sebastian Roller
2021-03-05  3:01           ` Chris Murphy
2021-03-07 13:58             ` Sebastian Roller
2021-03-08  0:56               ` Chris Murphy
2021-03-09 17:02                 ` Sebastian Roller
2021-03-09 20:34                   ` Chris Murphy
2021-03-16  9:35                     ` Sebastian Roller
2021-03-16 19:34                       ` Chris Murphy
2021-03-17  1:38 ` Qu Wenruo
2021-03-17  2:59   ` Chris Murphy
2021-03-17  9:01     ` Sebastian Roller
2021-03-17  1:54 ` Dāvis Mosāns
2021-03-17 10:50   ` Sebastian Roller [this message]

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=CALS+qHM0Zvcu60dbAwO1GtrsFyHMfhpRM-FmFeu6+aeo9X4wEA@mail.gmail.com \
    --to=sebastian.roller@gmail.com \
    --cc=davispuh@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.com \
    --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.