Roger Binns posted on Thu, 01 Jan 2015 12:12:31 -0800 as excerpted: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 12/31/2014 05:26 PM, Chris Samuel wrote: >> I suspect this is a knock-on effect of the fact that (unless this has >> changed recently & IIRC) RAID-1 with btrfs will only mirrors data over >> two drives, no matter how many you add to an array.
It hasn't changed yet, but now that raid56 support is basically complete (with 3.19, other than bugs of course, it'll be another kernel cycle or two before I'd rely on it), that's next up on the raid-features roadmap. =:^) I know as that's my most hotly anticipated roadmapped btrfs feature yet to hit, and I've been waiting for it, patiently only because I didn't have much choice, for a couple years now. > I wish btrfs wouldn't use the old school micro-managing storage > terminology (or only as aliases) and instead let you set the goals. What > people really mean is that they want their data to survive the failure > of N drives - exactly how that is done doesn't matter. It would also be > nice to be settable as an xattr on files and directories. Actually, a more flexible terminology has been discussed, and /might/ actually be introduced either along with or prior to the multi-way- mirroring feature (depending on how long the latter takes to develop, I'd guess). The suggested terminology would basically treat number of data strips, mirrors, parity, hot-spares, etc, each on its own separate axis, with parity levels ultimately extended well beyond 2 (aka raid6) as well -- I think to something like a dozen or 16. Obviously if it's introduced before N-way-mirroring, N-way-parity, etc, it would only support the current feature set for now, and would just be a different way of configuring mkfs as well as displaying the current layouts in btrfs filesystem df and usage. Hugo's the guy who has proposed that, and has been doing the preliminary patch development. Meanwhile, ultimately the ability to configure all this at least by subvolume is planned, and once it's actually possible to set it on less than a full filesystem basis, setting it by individual xattr has been discussed as well. I think the latter depends on the sorts of issues they run into in actual implementation. Finally, btrfs is already taking the xattr/property route with this sort of attribute. The basic infrastructure for that went in a couple kernel cycles ago, and can be seen and worked with using the btrfs property command. So the basic property/xattr infrastructure is already there, and the ability to configure redundancy per subvolume already built into the original btrfs design and roadmapped altho it's not yet implemented, which means it's actually quite likely to eventually be configurable by file via xattr/properties as well -- emphasis on /eventually/, as these features /do/ tend to take rather longer to actually develop and stabilize than originally predicted. The raid56 code is a good example, as it was originally slated for kernel cycle 3.6 or so, IIRC, but it took it over two years to cook and we're finally getting it in 3.19! -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
