From: Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>
To: linux-raid@vger.kernel.org
Subject: Re: detection/correction of corruption with raid6
Date: Wed, 17 Dec 2008 22:52:51 +0100 [thread overview]
Message-ID: <1229550771.13544.20.camel@localhost.localdomain> (raw)
In-Reply-To: <1229466317.22331.71.camel@localhost>
On Tue, 2008-12-16 at 23:25 +0100, Redeeman wrote:
[...]
> > Why a RAID system might have inconsistencies?
> > Why do we have a "check" command at all, to run weekly or monthly?
> As previously stated in discussion, while most bitflips etc does not
> happen on disk(apparently), they do happen, whether its in ram, pci,
> controller etc...
Ah! You spoiled it! :-)
Actually I was waiting for an answer from Neil Brown.
Because I'm under the impression that if it is not the HD,
it does not count... See below...
> Also, i imagine its just to be on top of things, read and ensure stuff
> works.. (but this is pure speculation)
I still have some comments on the topic.
First of all, someone mentioned the CRC/EDAC capabilities in the
filesystem. While this would be advisable, there is a fundamental
problem with it: there is no information on which device could
have caused the error (in case of RAID).
The FS can report, maybe correct, the data, but it is unaware of
the underlining hardware, so it does not help further.
On the other end (not hand), there are the device drivers.
Also these may report errors, but it can also be they just
deliver garbage, for several reasons.
The only component which can handle the problem is the "md", since
this is the only one which knows the devices _and_ the data.
Second. As mentioned above, it seems to me that RAID scope is
intentionally limited to pure HD failures.
Nowadays, one could build a RAID over usb-storage plus fw-sbp2
plus nbd plus esata.
The "HD" is not anymore the physical thing, it is everything
from the specific driver on.
If I stomp on the USB cable, detaching it, I would like the RAID
reacting as a real HD failure occurred (actually it does it properly).
So, IMHO, the argument that the "soft errors are improbable
within the HD" is limited, since it can happen elsewhere and
it should count like it was in the HD, IMHO...
Final point. More or less one year ago the same topic popped up,
with similar discussion.
At the end of the thread someone was asking if patches are
accepted in order to implement this feature.
I could not find any answer to that question in the archive.
What is the idea? Are patches accepted? Rejected by default?
Not that I want to provide one, but I was just curious...
bye,
--
pg
next prev parent reply other threads:[~2008-12-17 21:52 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-16 21:58 detection/correction of corruption with raid6 Piergiorgio Sartor
2008-12-16 22:25 ` Redeeman
2008-12-17 21:52 ` Piergiorgio Sartor [this message]
2008-12-19 4:39 ` Neil Brown
2008-12-19 5:38 ` Redeeman
2008-12-17 14:48 ` Bill Davidsen
2008-12-17 15:50 ` David Lethe
[not found] ` <494960E8.8020407@tmr.com>
2008-12-17 21:47 ` David Lethe
-- strict thread matches above, loose matches on Subject: below --
2008-12-19 8:40 piergiorgio.sartor
2008-12-19 13:10 ` Redeeman
2008-12-05 21:00 Redeeman
2008-12-05 21:02 ` Justin Piszcz
2008-12-05 21:06 ` Redeeman
2008-12-05 21:09 ` Justin Piszcz
2008-12-05 21:12 ` Redeeman
2008-12-05 21:17 ` Justin Piszcz
2008-12-05 21:30 ` Michał Przyłuski
2008-12-05 22:12 ` Peter Rabbitson
2008-12-05 22:26 ` Michał Przyłuski
2008-12-05 22:43 ` Greg Freemyer
2008-12-06 0:39 ` Roger Heflin
2008-12-12 15:31 ` Redeeman
2008-12-16 2:33 ` Neil Brown
2008-12-16 6:33 ` Redeeman
2008-12-16 7:59 ` Mattias Wadenstein
2008-12-16 22:20 ` Chris Worley
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=1229550771.13544.20.camel@localhost.localdomain \
--to=piergiorgio.sartor@nexgo.de \
--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).