linux-kernel - Re: Content Of Files May Be Changed After One Disk Is Failed In RAID5

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOHz195Bhfs5Rx-qd2BmO8N4cqrdjCXDuXwF5QjNf6mVSS9Y8g@mail.gmail.com>
Date:	Fri, 7 Sep 2012 14:30:56 +0800
From:	clplayer <cl.player@...il.com>
To:	NeilBrown <neilb@...e.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Content Of Files May Be Changed After One Disk Is Failed In RAID5

> --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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/