Goffredo Baroncelli posted on Wed, 02 May 2018 22:40:27 +0200 as excerpted:
> Anyway, my "rant" started when Ducan put near the missing of parity > checksum and the write hole. The first might be a performance problem. > Instead the write hole could lead to a loosing data. My intention was to > highlight that the parity-checksum is not related to the reliability and > safety of raid5/6. Thanks for making that point... and to everyone else for the vigorous thread debating it, as I'm learning quite a lot! =:^) >From your first reply: >> 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. I must have missed those threads, or at least, missed that conclusion from them (maybe believing they were about something rather narrower, or conflating... for instance), because AFAICT, this is the first time I've seen the practical merits of checksummed parity actually debated, at least in terms I as a non-dev can reasonably understand. To my mind it was settled (or I'd have worded my original claim rather differently) and only now am I learning different. And... to my credit... given the healthy vigor of the debate, it seems I'm not the only one that missed them... But I'm surely learning of it now, and indeed, I had somewhat conflated parity-checksumming with the in-place-stripe-read-modify-write atomicity issue. I'll leave the parity-checksumming debate (now that I know it at least remains debatable) to those more knowledgeable than myself, but in addition to what I've learned of it, I've definitely learned that I can't properly conflate it with the in-place stripe-rmw atomicity issue, so thanks! -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
