On 2018-05-02 12:55, waxhead wrote:
Goffredo Baroncelli wrote:
Hi
On 05/02/2018 03:47 AM, Duncan wrote:
Gandalf Corvotempesta posted on Tue, 01 May 2018 21:57:59 +0000 as
excerpted:
Hi to all I've found some patches from Andrea Mazzoleni that adds
support up to 6 parity raid.
Why these are wasn't merged ?
With modern disk size, having something greater than 2 parity, would be
great.
1) [...] the parity isn't checksummed, ....
Why the fact that the parity is not checksummed is a problem ?
I read several times that this is a problem. However each time the
thread reached the conclusion that... it is not a problem.
So again, which problem would solve having the parity checksummed ? On
the best of my knowledge nothing. In any case the data is checksummed
so it is impossible to return corrupted data (modulo bug :-) ).
I am not a BTRFS dev , but this should be quite easy to answer. Unless
you checksum the parity there is no way to verify that that the data
(parity) you use to reconstruct other data is correct.
While this is the biggest benefit (and it's a _huge_ one, because it
means you don't have to waste time doing the parity reconstruction if
you know the result won't be right), there's also a rather nice benefit
for scrubbing the array, namely that you don't have to recompute parity
to check if it's right or not (and thus can avoid wasting time
recomputing it for every stripe in the common case of almost every
stripe being correct).
On the other side, having the parity would increase both the code
complexity and the write amplification, because every time a part of
the stripe is touched not only the parity has to be updated, but also
the checksum has too..
Which is a good thing. BTRFS main selling point is that you can feel
pretty confident that whatever you put is exactly what you get out.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
