From: Chris Murphy <lists@colorremedies.com>
To: Martin Steigerwald <Martin@lichtvoll.de>
Cc: "linux-btrfs@vger.kernel.org BTRFS" <linux-btrfs@vger.kernel.org>,
Fredrik Tolf <fredrik@dolda2000.com>,
Hugo Mills <hugo@carfax.org.uk>
Subject: Re: Rebalancing RAID1
Date: Thu, 14 Feb 2013 11:45:47 -0700 [thread overview]
Message-ID: <7857EB12-1C91-4FCA-A819-B85EC51281B5@colorremedies.com> (raw)
In-Reply-To: <201302141544.05747.Martin@lichtvoll.de>
On Feb 14, 2013, at 7:44 AM, Martin Steigerwald <Martin@lichtvoll.de> wrote:
> For some reason BTRFS is still trying to write to /dev/sdd, which isn´t
> there anymore. That perfectly explains those lost page writes for me. If
> that is the case, this seems to me like a serious bug in BTRFS.
Following the ICRC ABRT error, /dev/sdd becomes /dev/sdi. Btrfs-progs recognizes this by only listing /dev/sdi and /dev/sde as devices in the volume. But the btrfs kernel space code continues to try to write to /dev/sdd, while /dev/sdi isn't getting any writes (at least, it's not filling up with data).
Btrfs kernel space code is apparently unaware that /dev/sdd is gone. That seems to be the primary problem.
A question is, if the kernel space code was aware of a member device vanishing and then reappearing, whether as the same or different block device designation, should it automatically re-add the device to the volume? Upon being re-added, it would be out of sync, leading to a follow-up question about whether it should be auto-scrubbed to fix this? And yet another follow-up question which is if the file system metadata contains information that can be used similar to the function of the md write-intent bitmap, reducing the time to catch the drive up, avoiding a full scrub?
Chris Murphy
next prev parent reply other threads:[~2013-02-14 18:45 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-12 23:01 Rebalancing RAID1 Fredrik Tolf
2013-02-13 0:58 ` Chris Murphy
2013-02-13 6:18 ` Fredrik Tolf
2013-02-13 8:10 ` Chris Murphy
2013-02-14 6:42 ` Fredrik Tolf
2013-02-14 7:27 ` Chris Murphy
2013-02-14 7:58 ` Fredrik Tolf
2013-02-14 8:41 ` Chris Murphy
2013-02-14 8:59 ` Hugo Mills
2013-02-14 18:05 ` Chris Murphy
2013-02-14 20:56 ` Hugo Mills
2013-02-14 22:11 ` Chris Murphy
2013-02-15 3:50 ` Fredrik Tolf
2013-02-15 3:55 ` Chris Murphy
2013-02-15 3:56 ` Fredrik Tolf
2013-02-15 4:03 ` Chris Murphy
2013-02-14 8:01 ` Chris Murphy
2013-02-15 4:06 ` Fredrik Tolf
2013-02-14 14:44 ` Martin Steigerwald
2013-02-14 18:45 ` Chris Murphy [this message]
2013-02-15 3:44 ` Fredrik Tolf
2013-02-15 5:49 ` Sander
2013-02-15 9:05 ` Martin Steigerwald
2013-02-15 21:56 ` Fredrik Tolf
2013-02-18 15:29 ` Stefan Behrens
2013-02-23 0:36 ` Fredrik Tolf
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=7857EB12-1C91-4FCA-A819-B85EC51281B5@colorremedies.com \
--to=lists@colorremedies.com \
--cc=Martin@lichtvoll.de \
--cc=fredrik@dolda2000.com \
--cc=hugo@carfax.org.uk \
--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 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.