Re: [PATCH] btrfs: raid56: Use correct stolen pages to calculate P/Q

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

On 2016-11-28 14:01, Christoph Anton Mitterer wrote:
> On Mon, 2016-11-28 at 19:45 +0100, Goffredo Baroncelli wrote:
>> I am understanding that the status of RAID5/6 code is so badly
> Just some random thought:
>
> If the code for raid56 is really as bad as it's often claimed (I
> haven't read it, to be honest) .... could it perhaps make sense to
> consider to start it from scratch? And/or merge it with a more generic
> approach that allows n-way-parity RAIDs (I think such patch was posted
> hear some year(s) ago).
Such a suggestion for higher order parity support was made some time ago 
(at least a year and a half I believe, probably more).  It was at the 
time stated that it was planned after n-way replication and raid5/6.

Personally I feel that sort of road-map is misguided, as all three are 
functionally interdependent as the original proposal had suggested, and 
I'm also of the opinion that the raid5/6 code probably should be redone 
from scratch (I wasn't the one who wrote it, and can't contribute much 
more than some attempts at testing as a third-party, so I obviously 
can't make that decision myself).  Doing so would likely make it much 
easier to implement higher order parity (and arbitrary 
striping/replication, which is something I'm _very_ interested in).  The 
existing code isn't bad in a stylistic or even traditional coding sense, 
but makes a significant number of poor choices in the high-level side of 
things (all the issues with parity for example).  If we just want 
working raid5/6, then working on the existing implementation is fine. 
If we want support for arbitrary combinations of 
striping/replication/parity (which would be a killer feature and 
something that BTRFS could actually say nothing else has), then 
rewriting from scratch is probably easier because of some of the 
low-level design choices made in the raid5/6 code.

Part of the problem though is that there are more admins and support 
focused people than coders involved.  In my case I very much do not have 
the expertise to work on kernel code beyond tweaking constants and 
twiddling default values for things (I'm technically a programmer, but 
90% of the work I do is sysops type stuff written in a mix of sh, 
Python, and about 7 different data serialization formats).