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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox