From: Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>
To: Neil Brown <neilb@suse.de>
Cc: Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>,
Peter Rabbitson <rabbit+list@rabbit.us>,
Goswin von Brederlow <goswin-v-b@web.de>,
Doug Ledford <dledford@redhat.com>,
Michael Evans <mjevans1983@gmail.com>,
Eyal Lebedinsky <eyal@eyal.emu.id.au>,
linux-raid list <linux-raid@vger.kernel.org>
Subject: Re: mismatch_cnt again
Date: Sun, 15 Nov 2009 22:05:42 +0100 [thread overview]
Message-ID: <20091115210542.GA6826@lazy.lzy> (raw)
In-Reply-To: <19196.50782.113024.239657@notabene.brown>
Hi,
> I think just "block ABC is inconsistent" is sufficient.
> user-space can then quiesce that part of the array, read the relevant
> blocks, do any analysis that might be appropriate, and report to the
> admin.
personally I think user space is good for
this kind of operations.
I think the point here is not if this kind of
recovery should be in kernel space or not, but
to have this kind of recovery.
> That is a very interesting threat scenario - occasional bit flip on
> read between media and memory. I had a drive like that once. One
> particular bit in the sector would fairly often return '1' no matter
> what had been written. I had it in a RAID1 and it quickly made a mess
> of the filesystem.
In my case, a further analisys showed that the "bits"
where always *written* correctly, but the reading
operation was, sometimes, flipping bits.
This was especially nasty, because, without "resync"
the array would have been always fine.
> As you say, there is nothing that md can or should do about this
> except report that something odd is happening, which it does, and
> report where it is happening, which it does not.
Well, md specifically may or may not have the infrastructure
to use the RAID-6 parity to correct this sort of issues.
Nevertheless, using the RAID-6 double parity, in user or
kernel space, is really one point for software RAID.
bye,
--
piergiorgio
next prev parent reply other threads:[~2009-11-15 21:05 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-07 0:41 mismatch_cnt again Eyal Lebedinsky
2009-11-07 1:53 ` berk walker
2009-11-07 7:49 ` Eyal Lebedinsky
2009-11-07 8:08 ` Michael Evans
2009-11-07 8:42 ` Eyal Lebedinsky
2009-11-07 13:51 ` Goswin von Brederlow
2009-11-07 14:58 ` Doug Ledford
2009-11-07 16:23 ` Piergiorgio Sartor
2009-11-07 16:37 ` Doug Ledford
2009-11-07 22:25 ` Eyal Lebedinsky
2009-11-07 22:57 ` Doug Ledford
2009-11-08 15:32 ` Goswin von Brederlow
2009-11-09 18:08 ` Bill Davidsen
2009-11-07 22:19 ` Eyal Lebedinsky
2009-11-07 22:58 ` Doug Ledford
2009-11-08 15:46 ` Goswin von Brederlow
2009-11-08 16:04 ` Piergiorgio Sartor
2009-11-09 18:22 ` Bill Davidsen
2009-11-09 21:50 ` NeilBrown
2009-11-10 18:05 ` Bill Davidsen
2009-11-10 22:17 ` Peter Rabbitson
2009-11-13 2:15 ` Neil Brown
2009-11-09 19:13 ` Goswin von Brederlow
2009-11-08 22:51 ` Peter Rabbitson
2009-11-09 18:56 ` Piergiorgio Sartor
2009-11-09 21:14 ` NeilBrown
2009-11-09 21:54 ` Piergiorgio Sartor
2009-11-10 0:17 ` NeilBrown
2009-11-10 9:09 ` Peter Rabbitson
2009-11-10 14:03 ` Martin K. Petersen
2009-11-12 22:40 ` Bill Davidsen
2009-11-13 17:12 ` Martin K. Petersen
2009-11-14 17:01 ` Bill Davidsen
2009-11-17 5:19 ` Martin K. Petersen
2009-11-14 19:04 ` Goswin von Brederlow
2009-11-17 5:22 ` Martin K. Petersen
2009-11-10 19:52 ` Piergiorgio Sartor
2009-11-13 2:37 ` Neil Brown
2009-11-13 5:30 ` Goswin von Brederlow
2009-11-13 9:33 ` Peter Rabbitson
2009-11-15 21:05 ` Piergiorgio Sartor [this message]
2009-11-15 22:29 ` Guy Watkins
2009-11-16 1:23 ` Goswin von Brederlow
2009-11-16 1:37 ` Neil Brown
2009-11-16 5:21 ` Goswin von Brederlow
2009-11-16 5:35 ` Neil Brown
2009-11-16 7:40 ` Goswin von Brederlow
2009-11-12 22:57 ` Bill Davidsen
2009-11-09 18:11 ` Bill Davidsen
2009-11-09 20:58 ` Doug Ledford
2009-11-09 22:03 ` Eyal Lebedinsky
-- strict thread matches above, loose matches on Subject: below --
2009-11-12 19:20 greg
2009-11-13 2:28 ` Neil Brown
2009-11-13 5:19 ` Goswin von Brederlow
2009-11-15 1:54 ` Bill Davidsen
2009-11-16 21:36 greg
2009-11-16 22:14 ` Neil Brown
2009-11-17 4:50 ` Goswin von Brederlow
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=20091115210542.GA6826@lazy.lzy \
--to=piergiorgio.sartor@nexgo.de \
--cc=dledford@redhat.com \
--cc=eyal@eyal.emu.id.au \
--cc=goswin-v-b@web.de \
--cc=linux-raid@vger.kernel.org \
--cc=mjevans1983@gmail.com \
--cc=neilb@suse.de \
--cc=rabbit+list@rabbit.us \
/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).