From: NeilBrown <neilb@suse.de>
To: clplayer <cl.player@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Content Of Files May Be Changed After One Disk Is Failed In RAID5
Date: Fri, 7 Sep 2012 16:48:33 +1000 [thread overview]
Message-ID: <20120907164833.540cf96d@notabene.brown> (raw)
In-Reply-To: <CAOHz195Bhfs5Rx-qd2BmO8N4cqrdjCXDuXwF5QjNf6mVSS9Y8g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]
On Fri, 7 Sep 2012 14:30:56 +0800 clplayer <cl.player@gmail.com> wrote:
> > --assume-clean is not safe with RAID5 unless the array actually is clean.
> > It is safe with RAID1 and RAID6 due to details of the specific implementation.
> > So I suspect that is the cause of the corruption.
> >
> > NeilBrown
> >
>
> Thank you for the information.
>
> I have removed --assume-clean in the script and executed the stress
> after that raid5 completed resync.
>
> The files are all consistent in the rest tests.
>
> I am now wondering, what's different between the implementation of
> raid5 algorithm and of raid6 algorithm?
>
> Would you please suggest some hints in the implementation?
>
> Thank you,
> Peng.
RAID5 will sometimes update the parity block by
read old parity and data blocks
subtract old data block from parity block
add new data block to parity block
write new data and parity.
When it does this, if the parity was wrong before, it will still be wrong
afterwards.
RAID6 doesn't do that, because 'subtracting' old data from the 'Q' parity
block is complicated and hasn't been implemented. So RAID6 always calculates
the 2 parity blocks from the actual data. So every time you write a parity
block you can be sure it is correct.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
prev parent reply other threads:[~2012-09-07 6:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-07 1:40 Content Of Files May Be Changed After One Disk Is Failed In RAID5 clplayer
2012-09-07 2:33 ` NeilBrown
2012-09-07 6:30 ` clplayer
2012-09-07 6:48 ` 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=20120907164833.540cf96d@notabene.brown \
--to=neilb@suse.de \
--cc=cl.player@gmail.com \
--cc=linux-kernel@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