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 20:39:05 +0100	[thread overview]
Message-ID: <20211013193905.GD11670@arachsys.com> (raw)
In-Reply-To: <YWcXczNENXOTxBuw@moria.home.lan>

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

> It looks like I must have mixed up some test run output or something - you're
> right, it's still failing for me, but it does work if prior to rereplicate we
> either remove /dev/sdc or set it to failed - that is, a device being (possibly
> momentarily) offline isn't enough for rereplicate to consider a given extent.

Brilliant, that also explains some confusion on my part: I was convinced I'd
seen it work when I manually tested, then the automated test failed and
subsequent manual tests all failed too. I must have removed and added
devices when I first tested, but only used mount -o degraded later,
incorrectly assuming that was equivalent.

Sounds like logical behaviour to me now I know about it. You wouldn't want
to start making extra copies of data and assuming a block device had
permanently failed just because it was briefly inaccessible.

Testing with

-    mount -t bcachefs -o degraded /dev/sdb /mnt
+    mount -t bcachefs /dev/sdb:/dev/sdc /mnt
+    bcachefs device remove -f /dev/sdc

everything works fine, and I now know how to drive it correctly. :)

I see it works just as well using bcachefs device set-state failed instead
of bcachefs device remove, or adding the new drive before removing the old
one.

(Need to work on retraining my fingers not to keep typing "bcachefs device
remove /mnt /dev/sdc" to match "bcachefs device add /mnt /dev/sdc" though!)

Best wishes,

Chris.

      reply	other threads:[~2021-10-13 19:39 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
2021-10-13 17:29     ` Kent Overstreet
2021-10-13 19:39       ` Chris Webb [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=20211013193905.GD11670@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.