All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Costaras <stevecs@chaven.com>
To: linux-raid@vger.kernel.org
Subject: mdadm / force parity checking of blocks on all reads?
Date: Thu, 17 Feb 2011 20:04:48 -0600	[thread overview]
Message-ID: <4D5DD3C0.3020804@chaven.com> (raw)



I'm looking at alternatives to ZFS since it still has some time to go 
for large scale deployment as a kernel-level file system (and brtfs has 
years to go).   I am running into problems with silent data corruption 
with large deployments of disks.    Currently no hardware raid vendor 
supports T10 DIF (which even if supported would only work w/ SAS/FC 
drives anyway) nor does read parity checking.

I am hoping that either there is a way that I don't know of to enable 
mdadm to read the data plus p+q parity blocks for every request and 
compare them for accuracy (simlar to what you need to do for a scrub but 
/ALWAYS/) or have the functionality added as an option.

With the current large capacity drives we have today getting bit errors 
is quite common (I have some scripts that I do complete file checks 
every two weeks across 50TB arrays and come up with errros every 
month).   I'm looking at expanding to 200-300TB volumes shortly so the 
problem will only get that much more frequent.     Being able to check 
the data against parity will be able to find/notify and correct errors 
at read time before they get to user space.   This fixes bit rot as well 
as torn/wild reads/writes and mitigates transmission issues.

I searched the list but couldn't find this benig discussed before, is 
this possible?

Steve Costaras
stevecs@chaven.com

             reply	other threads:[~2011-02-18  2:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-18  2:04 Steve Costaras [this message]
2011-02-18  3:25 ` mdadm / force parity checking of blocks on all reads? NeilBrown
2011-02-18  4:34   ` Roberto Spadim
2011-02-18 11:13   ` Steve Costaras
2011-02-18 12:07     ` John Robinson

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=4D5DD3C0.3020804@chaven.com \
    --to=stevecs@chaven.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.