Re: I need to P. are we almost there yet?

[Duncan <1i5t5.duncan@cox.net>]

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