From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Jared Van Bortel <jared.e.vb@gmail.com>,
Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: system drive corruption, btrfs check failure
Date: Sat, 30 Mar 2024 10:12:46 +1030 [thread overview]
Message-ID: <32ca8678-d0fd-44e4-b0a0-9b25383dc866@gmx.com> (raw)
In-Reply-To: <CALsQ4_x-5+W_7NQR68nTiCM9aptigGf6+HD=jLftrxgXTOLyRA@mail.gmail.com>
在 2024/3/30 04:00, Jared Van Bortel 写道:
> Hi,
>
> Yesterday I ran `pacman -Syu` to update my Arch Linux installation. I
> saw a lot of complaints from ldconfig, and programs started crashing.
> Thinking it was related to having only 7GiB of free space available, I
> tried deleting some large files and reinstalling the affected
> packages. I saw no clear improvement from this, and eventually decided
> to shut my computer down.
Do you have any dmesg of that incident?
>
> I booted memtest, and it completed a full pass without errors. I then
> booted a live USB and ran `btrfs check --readonly /dev/nvme0n1p2`, and
> saw a long list of errors, realizing my filesystem is most likely
> beyond repair.
>
> Basic information (RAID1 metadata, single data):
> ```
> Label: 'System' uuid: 76721faa-8c32-4e70-8a9e-859dece0aec1
> Total devices 2 FS bytes used 2.18TiB
> devid 1 size 422.63GiB used 422.63GiB path /dev/nvme0n1p2
> devid 2 size 1.82TiB used 1.82TiB path /dev/nvme1n1
> ```
> The installed kernel is linux-zen 6.6.10 with a few patches. The live
> USB I'm using has the Arch Linux 6.4.7-arch1-1 kernel. Full `btrfs
> check` log and smartctl information is attached.
>
> There are three main errors. One:
> ```
> ref mismatch on [1248293634048 16384] extent item 1, found 0
> tree extent[1248293634048, 16384] parent 2368656916480 has no tree block found
> incorrect global backref count on 1248293634048 found 1 wanted 0
> backpointer mismatch on [1248293634048 16384]
> owner ref check failed [1248293634048 16384]
> ```
>
> Two:
> ```
> ref mismatch on [1261902016512 4096] extent item 2, found 1
> data extent[1261902016512, 4096] bytenr mimsmatch, extent item bytenr
> 1261902016512 file item bytenr 0
> data extent[1261902016512, 4096] referencer count mismatch (parent
> 2369673248768) wanted 1 have 0
> backpointer mismatch on [1261902016512 4096]
> ```
Corrupted extent tree, this can lead to fs falling back to read-only
halfway.
>
> Three:
> ```
> block group 1342751899648 has wrong amount of free space, free space
> cache has 34193408 block group has 42893312
> failed to load free space cache for block group 1342751899648
> ```
This is not that uncommon if extent tree is already corrupted.
But unfortunately, this may not be the direct/root cause of the corruption.
Thus I'd prefer to have the initial dmesg.
>
> And this warning:
> ```
> [4/7] checking fs roots
> warning line 3916
> ```
>
> I bought some replacement disks that I can install alongside the old
> ones, but I don't have a recent backup of the full FS. It seems to
> mount readonly without issue.
The fs tree is mostly fine, so you can mount it RO and grab your data.
>
> What's the best way to recover the data that's left? And is there any
> clue here as to what went wrong? I'm really not sure. If this is a
> drive failure, it seems premature.
It's hard to say. The old original mode check output is not that helpful
to locate the root cause.
Mind to run "btrfs check --mode=lowmem" on that fs, and save both stderr
and stdout?
Thanks,
Qu
>
> Thanks,
> Jared
next prev parent reply other threads:[~2024-03-29 23:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-29 17:30 system drive corruption, btrfs check failure Jared Van Bortel
2024-03-29 23:42 ` Qu Wenruo [this message]
2024-05-19 2:17 ` Jared Van Bortel
2024-05-19 3:34 ` 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=32ca8678-d0fd-44e4-b0a0-9b25383dc866@gmx.com \
--to=quwenruo.btrfs@gmx.com \
--cc=jared.e.vb@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).