From: "Swâmi Petaramesh" <swami@petaramesh.org>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [BUG] BTRFS critical corrupt leaf - bisected to 496245cac57e
Date: Tue, 30 Jul 2019 10:02:55 +0200 [thread overview]
Message-ID: <d4b7fba8-632d-2d3b-4edd-70433b835a59@petaramesh.org> (raw)
In-Reply-To: <83294063-9f98-71ab-428b-e2251b96e5b9@gmx.com>
On 7/30/19 9:21 AM, Qu Wenruo wrote:
>
>> I have emergency downgraded my system to 5.1 not to take any risk of
>> crashing my SSD again (and if it crashes again anyway, then I will know
>> it is not kernel 5.2's fault and let you know...)
> That kernel message is to *prevent* any further damage, by rejecting any
> invalid metadata.
> If it caused mount failure, it shouldn't have written anything to the disk.
>
> The later transid error doesn't really match the original report.
>
> We really need the mount failure message of that fs.
This message is what I just got from my external backup USB HD that
started acting up yesterday (before I reverted back to 5.1).
I may find more in the syslog (but the machine is at home and I'm at
work so it'll have to wait... I have the external disk with me however,
so I would be able to run anything to test it now.)
For the machine's system SSD, what happened is that mount never actually
*failed* but the machine started displaying error messages at boot and
these error messages went along with such BTRFS error messages on the
console.
For example the machines wouldn't boot to GUI anymore but I would still
be able to log in in console and see that the log was crowded with
failing services and BTRFS errors.
Then I reformatted and reinstalled from backup, so the corresponding
logs are indeed lost.
ॐ
--
Swâmi Petaramesh <swami@petaramesh.org> PGP 9076E32E
next prev parent reply other threads:[~2019-07-30 8:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-13 20:48 [BUG] BTRFS critical corrupt leaf - bisected to 496245cac57e Alexander Wetzel
2019-07-14 1:30 ` Qu Wenruo
2019-07-14 9:25 ` Alexander Wetzel
2019-07-14 9:49 ` Qu Wenruo
2019-07-14 12:07 ` Alexander Wetzel
2019-07-14 12:51 ` Qu Wenruo
2019-07-14 15:40 ` Chris Murphy
2019-07-15 1:07 ` Qu Wenruo
2019-07-29 12:46 ` Swâmi Petaramesh
2019-07-29 13:33 ` Qu Wenruo
2019-07-30 4:56 ` Qu Wenruo
2019-07-30 6:44 ` Swâmi Petaramesh
2019-07-30 7:21 ` Qu Wenruo
2019-07-30 8:02 ` Swâmi Petaramesh [this message]
2019-07-30 13:57 ` Swâmi Petaramesh
2019-07-30 14:16 ` 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=d4b7fba8-632d-2d3b-4edd-70433b835a59@petaramesh.org \
--to=swami@petaramesh.org \
--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.