From: Josef Bacik <josef@toxicpanda.com>
To: Johannes Rohr <jorohr@gmail.com>, linux-btrfs@vger.kernel.org
Subject: Re: kernel BUG at fs/btrfs/relocation.c:437!
Date: Thu, 3 Sep 2020 11:56:22 -0400 [thread overview]
Message-ID: <3ee07ef0-2712-09d8-df19-85fb920b0c82@toxicpanda.com> (raw)
In-Reply-To: <28e01acb-a8b8-6801-ee49-94e56d7371aa@gmail.com>
On 9/1/20 4:18 AM, Johannes Rohr wrote:
> Dear devs,
>
> I tried to replace an SSD with bad S.M.A.R.T. status and since I don't
> have physical access to the server, I first wanted to remove it from the
> RAID 1 (which has 4 SSDs) and then erase it.
>
> I ran "btrfs device delete /dev/sda2 /". After a while, the command
> terminated with a segfault and the system hung. I waited for 30 minutes.
> Fortunately, it could be resurrected with a hard reset.
>
> dmesg, as this happened, reports that a block on a different SSD, on
> /dev/sdc can't be found.
>
> See full backtrace here:
> https://gist.github.com/vasyugan/340d9cd2292e3122c1d7773df718a234
>
> Now I am afraid that if sda is just removed physically, then marked as
> degraded and swapped for a new SSD using the btrfs replace command, this
> might also go bad because of the block that can't be found.
>
> Does any of you have advice on what to do? From the backtrace I don't
> even understand if the issue is a physical problem with sdc (whose
> S.M.A.R.T. values are just fine) or whether this is another btrfs bug
> and if you, if there is any way to work around it.
>
> We are running Ubuntu 20.04, the kernel is 5.4.0-45-generic, Ubuntu's
> version number is: 5.4.0-45.49. It was released yesterday and was
> supposed to have a relocation relate bug fixed, see
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1889669
>
> I suppose, this is a separate issue. Should I report a bug? If so, where?
>
> Thanks a lot in advance for your support!!!
>
This error message sounds like a corrupted file system. However I fixed quite a
few things in relocation recently, try a more recent kernel, 5.8 has all my
recent fixes in this area. If not then I'd try btrfs check /dev/whatever to see
if it complains about your fs being corrupted. Thanks,
Josef
prev parent reply other threads:[~2020-09-03 15:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-01 8:18 kernel BUG at fs/btrfs/relocation.c:437! Johannes Rohr
2020-09-03 8:15 ` Johannes Rohr
2020-09-03 15:56 ` Josef Bacik [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=3ee07ef0-2712-09d8-df19-85fb920b0c82@toxicpanda.com \
--to=josef@toxicpanda.com \
--cc=jorohr@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