>> I haven't seen that, but I doubt that it is the radical >> redesign of the multi-device layer of Btrfs that is needed to >> give it operational semantics similar to those of MD RAID, >> and that I have vaguely described previously.
> I agree that btrfs volume manager is incomplete in view of > data center RAS requisites, there are couple of critical > bugs and inconsistent design between raid profiles, but I > doubt if it needs a radical redesign. Well it needs a radical redesign because the original design was based on an entirely consistent and logical concept that was quite different from that required for sensible operations, and then special-case case was added (and keeps being added) to fix the consequences. But I suspect that it does not need a radical *recoding*, because most if not all of the needed code is already there. All tha needs changing most likely is the member state-machine, that's the bit that need a radical redesign, and it is a relatively small part of the whole. The closer the member state-machine design is to the MD RAID one the better as it is a very workable, proven model. Sometimes I suspect that the design needs to be changed to also add a formal notion of "stripe" to the Btrfs internals, where a "stripe" is a collection of chunks that are "related" (and something like that is already part of the 'raid10' profile), but I think that needs not be user-visible. -- 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
