On Fri, Jun 22, 2018 at 01:13:31AM +0200, waxhead wrote: > According to this: > > https://stratis-storage.github.io/StratisSoftwareDesign.pdf > Page 4 , section 1.2 > > It claims that BTRFS still have significant technical issues that may > never be resolved. > Could someone shed some light on exactly what these technical issues > might be?! What are BTRFS biggest technical problems? The subject you write is 'unsolvable', which I read as 'impossible to solve', eg. on the design level. I'm not aware of such issues. If this is about issues that are difficult either to implement or getting right, there are a few known ones. > If you forget about the "RAID"5/6 like features then the only annoyances > that I have with BTRFS so far is... > > 1. Lack of per subvolume "RAID" levels > 2. Lack of not using the deviceid to re-discover and re-add dropped devices > > And that's about it really... This could quickly turn into 'my faviourite bug/feature' list that can be very long. The most asked for are raid56, and performance of qgroups. Qu Wenruo improved some of the core problems and Jeff is working on the performance problem. So there are people working on that. On the raid56 front, there were some recent updates that fixed some bugs, but the fix for write hole is still missing so we can't raise the status yet. I have some some good news but nobody should get too excited until the code lands. I have prototype for the N-copy raid (where N is 3 or 4). This will provide the underlying infrastructure for the raid5/6 logging mechanism, the rest can be taken from Liu Bo's patchset sent some time ago. In the end the N-copy can be used for data and metadata too, independently and flexibly switched via the balance filters. This will cost one incompatibility bit. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
