From: Christoph Hellwig <hch@lst.de>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: Christoph Hellwig <hch@lst.de>,
clm@fb.com, josef@toxicpanda.com, dsterba@suse.com,
linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: repair all bad mirrors
Date: Wed, 22 Jun 2022 09:47:19 +0200 [thread overview]
Message-ID: <20220622074719.GA24601@lst.de> (raw)
In-Reply-To: <baeb9e98-fba4-8af9-9fd5-da6e1bd8ee34@gmx.com>
On Wed, Jun 22, 2022 at 01:14:30PM +0800, Qu Wenruo wrote:
>> We need to record at least one failed mirror to be able to repair it, and
>> with the design in this patch we can trivially walk back from the first
>> good mirror to the first bad one.
>
> Then in that case, I guess we can also just submit the good copy to all
> mirrors instead, no matter if it's corrupted or not?
Why would we submit it to a known good mirror?
> But considering repair_io_failure() is still synchronous submission,
> it's definitely going to be slower for RAID1C3/C4.
Yes, two or in the worst case three repair writes are going to be slower
than a single one. But I think that is worth it for the improved
reliability.
> Just a small nitpick related to the failrec.
> Isn't the whole failrec facility going to be removed after the read
> repair code rework?
Yes.
> So I guess this patch itself is just to solve the test case failure, but
> will still be replaced by the new read repair rework?
I've shifted plans for repair a bit and plan to do more gradual work.
Eventually the failrec should go away in this form, though.
next prev parent reply other threads:[~2022-06-22 7:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-19 8:28 [PATCH] btrfs: repair all bad mirrors Christoph Hellwig
2022-06-21 15:19 ` Nikolay Borisov
2022-06-21 15:46 ` Christoph Hellwig
2022-06-21 17:49 ` Nikolay Borisov
2022-06-22 4:23 ` Christoph Hellwig
2022-06-22 4:32 ` Qu Wenruo
2022-06-22 5:06 ` Christoph Hellwig
2022-06-22 5:14 ` Qu Wenruo
2022-06-22 7:47 ` Christoph Hellwig [this message]
2022-06-22 8:46 ` Qu Wenruo
2022-06-22 11:02 ` Christoph Hellwig
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=20220622074719.GA24601@lst.de \
--to=hch@lst.de \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.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 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.