Linux bcache driver list
 help / color / mirror / Atom feed
From: Kent Overstreet <kent.overstreet@gmail.com>
To: Mauricio Oliveira <mauricio.oliveira@canonical.com>
Cc: Nikhil Kshirsagar <nkshirsagar@gmail.com>, linux-bcache@vger.kernel.org
Subject: Re: bcache-register hang after reboot
Date: Sat, 13 Nov 2021 13:05:20 -0500	[thread overview]
Message-ID: <YY/+YDSjdZPma3oT@moria.home.lan> (raw)
In-Reply-To: <CAO9xwp006wLDLVAoCPFgp_ogLiCunB8F8rHh9UitXqSmtNqLoQ@mail.gmail.com>

On Thu, Nov 11, 2021 at 05:54:18PM -0300, Mauricio Oliveira wrote:
> Hi Kent,
> 
> On Wed, Nov 10, 2021 at 5:13 PM Kent Overstreet
> <kent.overstreet@gmail.com> wrote:
> > Your journal is completely full, so persisting the new btree root while doing
> > journal replay is hanging.
> >
> > There isn't a _good_ solution for this journal deadlock in bcache (it's fixed in
> > bcachefs), but there is a hack:
> >
> > edit drivers/md/bcache/btree.c line 2493
> >
> > delete the call to bch_journal_meta(), and build a new kernel. Once you've
> > gotten it to register, do a clean shutdown and then go back to a stock kernel.
> >
> > Running the kernel with that call deleted won't be safe if you crash, but it'll
> > get you going again.
> 
> Thanks for the clarification and suggestions.
> 
> Would it be OK to implement that workaround if requested by a sysadmin ?
> (say, to ack the data safety / crash risk)
> 
> Right now the issue is known, reproduces with v5.15, has no good solution,
> remains after reboot, prints hung task warnings continuously, and prevents
> using the device at all; and this workaround requires kernel dev/build skills.
> 
> Since its effects seem bad enough, it would seem fair enough to provide a
> way out even if it's not a _good_ one.
> 
> Say, we could try and detect the journal full during journal replay, and handle
> it by failing the device registration. This would unblock the tasks, and provide
> a more intuitive error message. (maybe leading to the next paragraph.)
> 
> We could also add a sysfs tunable to skip the call to bch_journal_meta(),
> and allow the registration to proceed, but fail it unconditionally in the end
> so the device isn't used with data safety / crash risk
> (or force an automatic unregister + register again w/ bch_journal_meta(),
> and disable the sysfs tunable).
> 
> This would help with the full journal, and allow a sysadmin to perform the
> workaround without kernel rebuild and reboots.

I think the best solution might be to change bch_btree_set_root() to check if
we're in journal replay, and if we are, make the call to bch_journal_meta()
nonblocking - pass it NULL instead of a closure.

  reply	other threads:[~2021-11-13 18:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-10  5:44 bcache-register hang after reboot Nikhil Kshirsagar
2021-11-10 20:13 ` Kent Overstreet
2021-11-11 20:54   ` Mauricio Oliveira
2021-11-13 18:05     ` Kent Overstreet [this message]
2021-12-13 22:04       ` Mauricio Faria de Oliveira
2021-12-13 22:22         ` Mauricio Faria de Oliveira
2021-12-14 16:06         ` Coly Li
2021-12-14 16:43           ` Mauricio Faria de Oliveira
2021-11-12  5:45   ` Coly Li
2021-11-13 18:12     ` Kent Overstreet

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=YY/+YDSjdZPma3oT@moria.home.lan \
    --to=kent.overstreet@gmail.com \
    --cc=linux-bcache@vger.kernel.org \
    --cc=mauricio.oliveira@canonical.com \
    --cc=nkshirsagar@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox