From: Roman Mamedov <rm@romanrm.ru>
To: Pavel Herrmann <morpheus.ibis@gmail.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: data corruption after rebuild
Date: Wed, 20 Jul 2011 00:12:28 +0600 [thread overview]
Message-ID: <20110720001228.7d3d45b2@natsu> (raw)
In-Reply-To: <2015932.L0f6vYYk3Y@bloomfield>
[-- Attachment #1: Type: text/plain, Size: 1408 bytes --]
On Tue, 19 Jul 2011 19:05:39 +0200
Pavel Herrmann <morpheus.ibis@gmail.com> wrote:
> > How it got there and how to prevent that from
> > happening in the future - that's a whole different question.
>
> would ZFS in raidz2 mode be much better than raid6+ext4? I understand its not
> the topic of this list, but file-level checksummed rebuild looks like a nice
> feature
Personally I prefer to not bother with ZFS, it brings way too many complications into software choice, and I just want to use my favorite GNU/Linux distro and not Solaris, and also not trusting 12 TB of data to a third-party kernel module or a FUSE driver which are barely tested and have uncertain future. I'd put more hope in BTRFS RAID5, but that one is a long way ahead from becoming a viable option too.
Regarding mdadm+raid6, AFAIK it currently does not try to heal itself from silent corruption inside a single chunk, even though that should be possible with RAID6. On a repair, if the data chunks are readable with no I/O error, they are considered to be the golden standard and all parity chunks are simply recalculated from data and overwritten (also incrementing mismatch_cnt, if they changed). So maybe implementing a more advanced repair feature could give protection against silent corruption not much weaker than what is offered by per-file checksumming RAID implementations.
--
With respect,
Roman
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2011-07-19 18:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-19 13:55 data corruption after rebuild Pavel Herrmann
2011-07-19 15:12 ` Roman Mamedov
2011-07-19 16:18 ` Pavel Herrmann
2011-07-19 17:38 ` Roman Mamedov
2011-07-19 17:44 ` Pavel Herrmann
2011-07-19 16:35 ` Pavel Herrmann
2011-07-19 16:48 ` Roman Mamedov
2011-07-19 17:05 ` Pavel Herrmann
2011-07-19 18:12 ` Roman Mamedov [this message]
2011-07-20 6:24 ` NeilBrown
2011-07-20 8:20 ` Pavel Herrmann
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=20110720001228.7d3d45b2@natsu \
--to=rm@romanrm.ru \
--cc=linux-raid@vger.kernel.org \
--cc=morpheus.ibis@gmail.com \
/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.