From: Chris Murphy <lists@colorremedies.com>
To: Christian Wimmer <telefonchris@icloud.com>
Cc: Qu Wenruo <quwenruo.btrfs@gmx.com>, Qu WenRuo <wqu@suse.com>,
Anand Jain <anand.jain@oracle.com>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: 12 TB btrfs file system on virtual machine broke again
Date: Sat, 4 Jan 2020 21:03:26 -0700 [thread overview]
Message-ID: <CAJCQCtQmvHS8+Z7=B_8panSzo=Bfo0ymVU+cr_tR5z1uw+Ejug@mail.gmail.com> (raw)
In-Reply-To: <256D0504-6AEE-4A0E-9C62-CDF975FDE32D@icloud.com>
On Sat, Jan 4, 2020 at 10:07 AM Christian Wimmer
<telefonchris@icloud.com> wrote:
>
> Hi guys,
>
> I run again in a problem with my btrfs files system.
> I start wondering if this filesystem type is right for my needs.
> Could you please help me in recovering my 12TB partition?
If you're having recurring problems, there's a decent chance it's
hardware related and not Btrfs, because Btrfs is pretty stable on
stable hardware. Btrfs is actually fussier than other file systems
because everything is checksummed.
> What happened?
> -> This time I was just rebooting normally my virtual machine. I discovered during the past days that the system hangs for some seconds so I thought it would be a good idea to reboot my SUSE Linux after 14 days of working. The machine powered off normally but when starting it run into messages like the pasted ones.
A complete dmesg leading up to the problem would be useful. Kernel
messages at the last moments it was working, and also messages for the
first mount attempt that failed. And kernel versions for both (sounds
like 5.4 series).
And also `btrfs check` output, no repair.
> btrfs-progs-5.4]# ./btrfs restore -l /dev/sdb1
> checksum verify failed on 3181912915968 found 000000A9 wanted 00000064
> checksum verify failed on 3181912915968 found 00000071 wanted 00000066
> checksum verify failed on 3181912915968 found 000000A9 wanted 00000064
> bad tree block 3181912915968, bytenr mismatch, want=3181912915968, have=4908658797358025935
> checksum verify failed on 2688520683520 found 000000D5 wanted FFFFFFA9
> checksum verify failed on 2688520683520 found 000000EE wanted FFFFFFEB
> checksum verify failed on 2688520683520 found 000000D5 wanted FFFFFFA9
> bad tree block 2688520683520, bytenr mismatch, want=2688520683520, have=10123237912294
> Could not open root, trying backup super
> checksum verify failed on 3181912915968 found 000000A9 wanted 00000064
> checksum verify failed on 3181912915968 found 00000071 wanted 00000066
> checksum verify failed on 3181912915968 found 000000A9 wanted 00000064
> bad tree block 3181912915968, bytenr mismatch, want=3181912915968, have=4908658797358025935
> checksum verify failed on 2688520683520 found 000000D5 wanted FFFFFFA9
> checksum verify failed on 2688520683520 found 000000EE wanted FFFFFFEB
> checksum verify failed on 2688520683520 found 000000D5 wanted FFFFFFA9
> bad tree block 2688520683520, bytenr mismatch, want=2688520683520, have=10123237912294
> Could not open root, trying backup super
> checksum verify failed on 3181912915968 found 000000A9 wanted 00000064
> checksum verify failed on 3181912915968 found 00000071 wanted 00000066
> checksum verify failed on 3181912915968 found 000000A9 wanted 00000064
> bad tree block 3181912915968, bytenr mismatch, want=3181912915968, have=4908658797358025935
> checksum verify failed on 2688520683520 found 000000D5 wanted FFFFFFA9
> checksum verify failed on 2688520683520 found 000000EE wanted FFFFFFEB
> checksum verify failed on 2688520683520 found 000000D5 wanted FFFFFFA9
> bad tree block 2688520683520, bytenr mismatch, want=2688520683520, have=10123237912294
> Could not open root, trying backup super
> btrfs-progs-5.4]#
I'm not sure, the checksums found vs wanted look a little suspicious.
--
Chris Murphy
next prev parent reply other threads:[~2020-01-05 4:03 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-06 3:44 [PATCH] btrfs-progs: Skip device tree when we failed to read it Qu Wenruo
2019-12-06 6:12 ` Anand Jain
2019-12-06 15:50 ` Christian Wimmer
2019-12-06 16:34 ` Christian Wimmer
[not found] ` <762365A0-8BDF-454B-ABA9-AB2F0C958106@icloud.com>
2019-12-07 1:16 ` Qu WenRuo
2019-12-07 3:47 ` Christian Wimmer
2019-12-07 4:31 ` Qu Wenruo
2019-12-07 13:03 ` Christian Wimmer
2019-12-07 14:10 ` Qu Wenruo
2019-12-07 14:25 ` Christian Wimmer
2019-12-07 16:44 ` Christian Wimmer
2019-12-08 1:21 ` Qu WenRuo
2019-12-10 21:25 ` Christian Wimmer
2019-12-11 0:36 ` Qu Wenruo
2019-12-11 15:57 ` Christian Wimmer
[not found] ` <9FB359ED-EAD4-41DD-B846-1422F2DC4242@icloud.com>
2020-01-04 17:07 ` 12 TB btrfs file system on virtual machine broke again Christian Wimmer
2020-01-05 4:03 ` Chris Murphy [this message]
2020-01-05 13:40 ` Christian Wimmer
2020-01-05 14:07 ` Martin Raiber
2020-01-05 14:14 ` Christian Wimmer
2020-01-05 14:23 ` Christian Wimmer
2020-01-05 4:25 ` Qu Wenruo
2020-01-05 14:17 ` Christian Wimmer
2020-01-05 18:50 ` Chris Murphy
2020-01-05 19:18 ` Christian Wimmer
2020-01-05 19:36 ` Chris Murphy
2020-01-05 19:49 ` Christian Wimmer
2020-01-05 19:52 ` Christian Wimmer
2020-01-05 20:34 ` Chris Murphy
2020-01-05 20:36 ` Chris Murphy
[not found] ` <3F43DDB8-0372-4CDE-B143-D2727D3447BC@icloud.com>
2020-01-05 20:30 ` Chris Murphy
2020-01-05 20:36 ` Christian Wimmer
2020-01-05 21:13 ` Chris Murphy
2020-01-05 21:58 ` Christian Wimmer
2020-01-05 22:28 ` Chris Murphy
2020-01-06 1:31 ` Christian Wimmer
2020-01-06 1:33 ` Christian Wimmer
2020-01-11 17:04 ` 12 TB btrfs file system on virtual machine broke again (third time) Christian Wimmer
2020-01-11 17:23 ` Christian Wimmer
2020-01-11 19:46 ` Chris Murphy
2020-01-13 19:41 ` 12 TB btrfs file system on virtual machine broke again (fourth time) Christian Wimmer
2020-01-13 20:03 ` Chris Murphy
2020-01-31 16:35 ` btrfs not booting any more Christian Wimmer
2020-05-08 12:20 ` btrfs reports bad key ordering after out of memory situation Christian Wimmer
2020-01-05 23:50 ` 12 TB btrfs file system on virtual machine broke again Qu Wenruo
2020-01-06 1:32 ` Christian Wimmer
2020-01-11 7:25 ` Andrei Borzenkov
2021-10-15 21:01 ` need help in a broken 2TB BTRFS partition Christian Wimmer
2021-10-16 10:08 ` Qu Wenruo
2021-10-16 17:29 ` Christian Wimmer
2021-10-16 22:55 ` Qu Wenruo
2021-10-16 17:35 ` Christian Wimmer
2021-10-16 23:27 ` Qu Wenruo
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='CAJCQCtQmvHS8+Z7=B_8panSzo=Bfo0ymVU+cr_tR5z1uw+Ejug@mail.gmail.com' \
--to=lists@colorremedies.com \
--cc=anand.jain@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
--cc=telefonchris@icloud.com \
--cc=wqu@suse.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.