BTRFS... Oh well there goes that idea.

ellnic · 23. April 2015

Is anyone else annoyed at the current direction BTRFS is moving in with regards to parity? I know some of this isn't totally new news, but I've been catching up on the state of BTRFS and am really quite irritated because I was hoping things would have changed in recent months and they don't appear to be.

According to this post: http://blog.ronnyegner-consult…nt-page-1/#comment-784446 triple parity is pretty much never going to happen in favour of distributed storage because it's not what businesses want according to the devs.

According to Ronny's blog, there is a patch by Andrea Mazzoleni for BTRFS that adds the much needed functionality and then some. This seems to suggest that the patch works brilliantly: https://lkml.org/lkml/2014/10/21/416 but it's simply not on the radar for the devs.

More recently, support for RAID 5/6 is being worked on and Linus recently approved a pull request for BTRFS RAID 5/6 improvements from Facebook who are trialling BTRFS heavily (http://www.phoronix.com/scan.p…s-Linux-3.20-Pull-Request) but this is still far from being ready and the bottom line is, no triple parity.

I only use double parity on my home server but I can't imagine that those with much more than 8-10 drives would be overly comfortable with this.

This was meant to be the answer to all the licence issues with ZoL. FreeBSD has, for a long time, been the goto OS if you want flawless ZFS out the box. I'm not saying the ZoL guys don't do good work, but it's still a hack to get it working and does have issues. Native BTRFS was meant to solve all this and make Linux amazing for redundant storage whilst adding some awesome new features like being able to grow and shink VDEVS without destroying and recreating them.

anyone else miffed that the devs don't seem to be changing their minds?

ellnic · 23. April 2015

Just me then

subzero79 · 23. April 2015

Zitat von ellnic

I'm not saying the ZoL guys don't do good work,

Just this, i think zol guys do good work too, but not with debian.

I use btrfs and my impression is they have two focuses right now stability and raid56. For the last one i think it took longer than they expected. Next feature my guess is online deduplication, a feature that competes directly with zfs, but i see at least two years from now.

Everyone though btrfs was gonna be faster because of facebook. Apparently not.

As personal use, I am very confortable right now with raid1 since is very flexible and you can expand size just adding disks, something that worked different with mdadm.

And as i think read all the links they will eventually add PAR3456, but not now. They guy could simply add a parallel branch to mantain and integrate when they feel like "bussiness"

ellnic · 23. April 2015

I'm glad it's not just me.

I'll probably have to stick with ZFS for now because I'm not in a position to use RAID 1 - whilst it's easy to expand, it's a 50% loss of disks which I cannot justify.

Like you say, maybe Andrea's code will be integrated when the time is right- but for now, it's just a little frustrating that they aren't including triple parity. I'd at least be happy with double parity - which still isn't stable enough for general use.

davidh2k · 29. April 2015

Companys who care about data do not care about a 50% loss like you do. The parity is for High Availability, not security. Allways that falsefied assumptions...

Also, as a prominet example: backblaze uses 3xraid6 in a storage pod, each array containing 15 disks.

Greetings
David

ellnic · 30. April 2015

Understood. Though, the point I'm getting at here is that I hope they aren't going to forget the smaller users once the corporate kinks are ironed out. In order to be awesome, this needs to match every feature of ZFS and then beat it. More and more people are kitting themselves out today with what we would have called 'business level' storage only a few years back. All I'm saying is that it would be a massive shame if possibly the most promising native Linux FS to date left home and small business users in the dust because they were too busy focussing on corporations.

bobafetthotmail · 19. Mai 2015

1. Andrea Mazzoleni is the Snapraid dev. [propaganda] Snapraid master race. [/propaganda]

2. Btrfs uses the RAID terms for the sake of easy layman understanding, but what it actually does is not really a RAID X, it is the "thing that RAID X does, but at the filesystem block level".
https://btrfs.wiki.kernel.org/…RAID_and_data_replication
also ZFS works at block level, but is less flexible.

Here is the translation of the RAID terms into the actual name of the thing implemented:
- RAID 0 == striping (works)
- RAID 1 == mirroring (works)
- RAID 10 == mirroring AND striping (works, no duh!)
- RAID 5-6 == striping (works) AND parity (unstable). A RAID5-6 is just a "RAID0 with 1-2 distributed parity" after all.

Since it is doing things on its own, it can do weird wizardry like this already http://jrs-s.net/2014/02/13/btrfs-raid-awesomeness/
(RAID1 across 4 wildly different drives, half of the total space of the array is available, which is EPIC WIN, no way around it)
mdadm will just make the array as big as (half) the smaller drive size.
ZFS is also unable to do it without some (possibly dangerous) hacks. https://tentacles666.wordpress…ons-on-mixed-sized-disks/
aufs is a program that does a similar thing, although not at the block level and not RAID1.

Due to this trickery it also can migrate the same array from single to double parity or back to no parity or change to mirroring or whatever, even on a live filesystem (let's ignore for a moment that parity code is unstable), running a rebalance that moves the data around the drives to match the new settings.
This is not possible with ZFS afaik, let alone with anything else really.

The reason is that the plan was to make this eventually all user-selectable (mirror, stripe, parity) and drop the RAID names. Thankfully the guy got an answer from the dev as I don't remember where was the old one I read ages ago.

3. the guy in the blog post shows a read comprehension failure, probably caused by a severe case of "is it done yet" syndrome.
His link about "the answer here", this is the dev speaking http://www.spinics.net/lists/linux-btrfs/msg38533.html

> That, along with a bunch of other features, is on the longer term
> roadmap and will likely eventually be implemented. Actually, the
> discussion involves a quite flexible plan where number of
> redundancies/parities/strips-per-strip are all configurable along
> different/independent axes.

> I wouldn't recommend expecting it any time soon, however, as btrfs
> features have repeatedly taken far longer to implement and become stable
> than originally predicted.

4. if there is someone that needs this stuff are companies. It's just horribly complex so it is taking ages. Throwing money at a problem that needs brains isn't particularly faster than just using brains.

5. 80% of people working at kernel are employed by someone, so yeah, linux is and has ever been focusing on corporations best interests, totally normal and expected. http://www.linuxfoundation.org…-linux-development-report
In 2012 it was 75%, seems to be rising.
That's the power of open source. Uniting companies and end users under the same project.

EDIT:clarified the raid5/6 description above.

davidh2k · 19. Mai 2015

Zitat von bobafetthotmail

A RAID5-6 is just a "RAID0 with 1-2 parity" after all.

One might say that, but thats not how it technically works. Technically this only applies to a RAID4 which is no longer used.

vs.

Greetings
David

bobafetthotmail · 20. Mai 2015

Zitat von davidh2k

One might say that, but thats not how it technically works. Technically this only applies to a RAID4 which is no longer used.

I did not specify where parity was, both RAID4 and RAID5/6 would fit that description.

RAID4 has all parity on a single drive (which is kinda dumb and causes performance issues on writes), RAID5/6 have parity (single or double) distributed over the whole array.
But that's still parity, even if split over the whole array.

Although you are right, it's a bit unclear. A more accurate term would have been "distributed parity", fixing the above.

BTRFS... Oh well there goes that idea.

chente 8. November 2021

Jetzt mitmachen!