From: NeilBrown <neilb@suse.de>
To: John Robinson <john.robinson@anonymous.org.uk>
Cc: linux-raid@vger.kernel.org
Subject: Re: RAID6 rebuild stuck
Date: Wed, 3 Oct 2012 11:21:20 +1000 [thread overview]
Message-ID: <20121003112120.67d16a3b@notabene.brown> (raw)
In-Reply-To: <506B4FF9.8070904@anonymous.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1640 bytes --]
On Tue, 02 Oct 2012 21:35:05 +0100 John Robinson
<john.robinson@anonymous.org.uk> wrote:
> On 02/10/2012 21:29, NeilBrown wrote:
> > On Tue, 02 Oct 2012 20:51:31 +0100 John Robinson
> > <john.robinson@anonymous.org.uk> wrote:
> >
> >> On 02/10/2012 16:56, Brian Candler wrote:
> >>> On Tue, Oct 02, 2012 at 03:56:42PM +1000, NeilBrown wrote:
> >>>> Lesson: always do a read test as well as a write test!
> >>>
> >>> And there was me thinking that drives read back data after writing it -
> >>> clearly they do not :-)
> >>
> >> Would it be worth adding a re-read onto the end of the usual read
> >> failure reconstruct-write cycle?
> >
> > What? Read twice?
> >
> > We already read after the write when attempting to fix a failure.
>
> I didn't realise you already did that.
>
> > I suspect it doesn't do much good though as the data is in cache in the drive.
>
> No, maybe not. There isn't an option you can add to ask for an uncached
> read? But I dare say you'd have thought of that already if there was :-)
Maybe setting REQ_FUA would work. Or maybe it would cause crashes and random
data corruption. I suspect most people think of REQ_FUA as being associated
with WRITEs. Maybe I'm to cynical, but this would be extremely hard to test,
and I don't feel up to the code review that would be required to provide
sufficient confidence :-(
NeilBrown
>
> Cheers,
>
> John.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
prev parent reply other threads:[~2012-10-03 1:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-01 11:29 RAID6 rebuild stuck Brian Candler
2012-10-02 1:50 ` Chris Murphy
2012-10-02 5:56 ` NeilBrown
2012-10-02 15:56 ` Brian Candler
2012-10-02 19:51 ` John Robinson
2012-10-02 20:29 ` NeilBrown
2012-10-02 20:35 ` John Robinson
2012-10-03 1:21 ` NeilBrown [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=20121003112120.67d16a3b@notabene.brown \
--to=neilb@suse.de \
--cc=john.robinson@anonymous.org.uk \
--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;
as well as URLs for NNTP newsgroup(s).