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).
--
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
