From: Jan Schmidt <list.btrfs@jan-o-sch.net>
To: Andrey Kuzmin <andrey.v.kuzmin@gmail.com>
Cc: linux-btrfs@vger.kernel.org, linux-raid@vger.kernel.org,
Chris Mason <chris.mason@oracle.com>,
Josef Bacik <josef@redhat.com>
Subject: Re: How to implement raid1 repair
Date: Thu, 17 Mar 2011 18:37:54 +0100 [thread overview]
Message-ID: <4D8246F2.8080104@jan-o-sch.net> (raw)
In-Reply-To: <AANLkTi=ckrr4BNSPxkMCveLAY7NyQ6SF6OzYHMnxC-rD@mail.gmail.com>
On 03/17/2011 06:09 PM, Andrey Kuzmin wrote:
> On Thu, Mar 17, 2011 at 5:46 PM, Jan Schmidt <list.btrfs@jan-o-sch.net
> <mailto:list.btrfs@jan-o-sch.net>> wrote:
> - Is it acceptable to retry reading a block immediately after the disk
> said it won't work? Or in case of a successful read followed by a
> checksum error? (Which is already being done right now in btrfs.)
>
>
> These are two pretty different cases. When disk firmware fails read, it
> means it has retried number of times but gave up (suggesting media
> error), so an upper layer retry would hardly make sense. Checksum error
> catches on-disk EDC fault, so retry is on the contrary quite reasonable.
Agreed.
> - Is it acceptable to always write both mirrors if one is found to be
> bad (also consider ssds)?
>
>
> Writing on read path bypassing file-system transaction mechanism doesn't
> seem a good idea to me. Just imaging loosing power while overwriting
> last good copy.
Okay, sounds reasonable to me. Let's say we're bypassing transaction
mechanism in the same rude manner, but only write the bad mirror. Does
that seem reasonable?
Thanks,
Jan
next prev parent reply other threads:[~2011-03-17 17:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-17 14:46 How to implement raid1 repair Jan Schmidt
2011-03-17 17:19 ` Josef Bacik
2011-03-17 17:52 ` Jan Schmidt
2011-03-17 17:36 ` Chris Mason
2011-03-17 17:49 ` Jan Schmidt
[not found] ` <AANLkTi=ckrr4BNSPxkMCveLAY7NyQ6SF6OzYHMnxC-rD@mail.gmail.com>
2011-03-17 17:37 ` Jan Schmidt [this message]
2011-03-17 17:42 ` Chris Mason
2011-03-17 17:45 ` Andrey Kuzmin
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=4D8246F2.8080104@jan-o-sch.net \
--to=list.btrfs@jan-o-sch.net \
--cc=andrey.v.kuzmin@gmail.com \
--cc=chris.mason@oracle.com \
--cc=josef@redhat.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-raid@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox