linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Rohr <jorohr@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: kernel BUG at fs/btrfs/relocation.c:437!
Date: Tue, 1 Sep 2020 10:18:52 +0200	[thread overview]
Message-ID: <28e01acb-a8b8-6801-ee49-94e56d7371aa@gmail.com> (raw)

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!!!

Johannes




             reply	other threads:[~2020-09-01  8:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-01  8:18 Johannes Rohr [this message]
2020-09-03  8:15 ` kernel BUG at fs/btrfs/relocation.c:437! Johannes Rohr
2020-09-03 15:56 ` Josef Bacik

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=28e01acb-a8b8-6801-ee49-94e56d7371aa@gmail.com \
    --to=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;
as well as URLs for NNTP newsgroup(s).