All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Webb <chris@arachsys.com>
To: Kent Overstreet <kent.overstreet@gmail.com>
Cc: linux-bcachefs@vger.kernel.org
Subject: Re: Metadata rereplication not triggering
Date: Wed, 13 Oct 2021 17:52:40 +0100	[thread overview]
Message-ID: <20211013165240.GC11670@arachsys.com> (raw)
In-Reply-To: <YWXRy46DZY7AV+Kf@moria.home.lan>

Kent Overstreet <kent.overstreet@gmail.com> writes:

> On Tue, Oct 12, 2021 at 10:07:46AM +0100, Chris Webb wrote:
> > 
> > If I create a filesystem with --replicas=2, fail a component drive and
> > replace with a new one, then use bcachefs data rereplicate, metadata
> > doesn't seem to get copied to the new drive.
> 
> It turns out rereplicate_pred() wasn't checking the key types correctly, and it
> wasn't rereplicating any of the newer key types - I just pushed a fix. Thanks
> for the report and the test!

Hi Kent. Ah, that makes sense, thanks!

I pulled the latest HEADs of bcachefs-tools and bcachefs, including this
patch, but when rerunning the ktest, it still fails.

  00016 bcachefs (dev-1): btree write error: device removed
  00016 bcachefs (f5d59006-9408-4179-859c-16e94b1d9b7a): insufficient devices
  online (0) for replicas entry btree: 1/2 [0 1]
  00016 bcachefs: bch2_fs_open() bch_fs_open err opening /dev/sdd:
  insufficient devices
  00016 mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sdd,
  missing codepage or helper program, or other error.
  00016 
  00016 ========= FAILED replace_replica in 2s

I added a bcachefs fs usage to the ktest just before the first umount to
provide a bit of additional debugging info: looks like sb and journal are
still zero on the newly added device even following the data rereplicate
operation.

Is there something extra I should be adding to the test to ensure the
superblock also gets mirrored (e.g. a pause if it's kicked off
asynchronously), or is there still something not quite right here? (Does the
test now pass for you? I'm guessing this should be reasonably deterministic
and host independent?)

Best wishes,

Chris.

  reply	other threads:[~2021-10-13 16:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-12  9:07 Metadata rereplication not triggering Chris Webb
2021-10-12  9:11 ` [PATCH] [ktest] Test simple drive replacement on a replicated fs Chris Webb
2021-10-12 18:19 ` Metadata rereplication not triggering Kent Overstreet
2021-10-13 16:52   ` Chris Webb [this message]
2021-10-13 17:29     ` Kent Overstreet
2021-10-13 19:39       ` Chris Webb

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=20211013165240.GC11670@arachsys.com \
    --to=chris@arachsys.com \
    --cc=kent.overstreet@gmail.com \
    --cc=linux-bcachefs@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 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.