Re: Exactly what is wrong with RAID5/6

From: Chris Murphy <lists@colorremedies.com>
To: Goffredo Baroncelli <kreijack@inwind.it>
Cc: Chris Murphy <lists@colorremedies.com>,
	Qu Wenruo <quwenruo@cn.fujitsu.com>,
	waxhead <waxhead@dirtcellar.net>,
	Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Exactly what is wrong with RAID5/6
Date: Wed, 21 Jun 2017 17:19:54 -0600	[thread overview]
Message-ID: <CAJCQCtSNg_RsxzdgBU5Bb1R9NoZHxYTB=K4NnL1qs6OdnaV=WQ@mail.gmail.com> (raw)
In-Reply-To: <34ac2dd7-88ba-6de7-d8e2-061c283bb9c1@inwind.it>

On Wed, Jun 21, 2017 at 2:12 PM, Goffredo Baroncelli <kreijack@inwind.it> wrote:

>
> Generally speaking, when you write "two failure" this means two failure at the same time. But the write hole happens even if these two failures are not at the same time:
>
> Event #1: power failure between the data stripe write and the parity stripe write. The stripe is incoherent.
> Event #2: a disk is failing: if you try to read the data from the remaining data and the parity you have wrong data.
>
> The likelihood of these two event at the same time (power failure and  in the next boot a disk is failing) is quite low. But in the life of a filesystem, these two event likely happens.
>
> However BTRFS has an advantage: a simple scrub may (crossing finger) recover from event #1.

Event #3: the stripe is read, missing a data strip due to event #2,
and is wrongly reconstructed due to event #1, Btrfs computes crc32c on
the reconstructed data and compares to extent csum, which then fails
and EIO happens.

Btrfs is susceptible to the write hole happening on disk. But it's
still detected and corrupt data isn't propagated upward.

-- 
Chris Murphy