SUSE pledges endless love for btrfs, says Red Hat's dumping irrelevant

SUSE has decided to let the world know it has no plans to step away from the btrfs filesystem, and plans to make it even better. The company's public display of affection comes after Red Hat decided not to fully support the filesystem in its own Linux. Losing a place in one of the big three Linux distros isn't a good look for …

[Voland's right hand]

RHEL is playing silly buggers

BTRFS costs more in terms of CPU than the EXT family, but you get working de-dupe as well significant gains on flash and hybrid drives.

The de-duplication alone makes it worthwhile at least for me.

In any case, RHEL regularly declares that it will not support something with some fanfare just to climb down a few years later. Nothing new here, move along.

[seven of five]

Re: RHEL is playing silly buggers

By the time RHEL returns to btrfs suse will have a "new bestest ev0r" filesystem choosen as the eternal default... mid 2018 or so. From ext to Reiser to btrfs, they had nearly every filesystem ever written as a default once.

[Anonymous Coward]

Re: RHEL is playing silly buggers

"From ext to Reiser to btrfs, they had nearly every filesystem ever written as a default once."

True and I've used them all in SUSE systems with good results over the years. Including Btrfs for several years now.

[CAPS LOCK]

Yes, well lets just hope that the love between RedHat and Microsoft doesn't mean a move to...

...NTFS.

Sorry about topic drift here, I've been having an 'interesting' time with Win 7 just lately.

[nijam]

Unfortunately, Red Hat seem to suffer a kind of chronic, low-grade NIH-ness, which militates against btrfs.

And of course the flip side is that they're gung-ho about a stuff they've put into Linux themselves, no matter how unnecessary or even ill-advised.

[Alan Brown]

"which militates against btrfs."

There's a mitigating factor: btrfs is _far_ from production-ready and there are other, working FSes which do what it claims to do already.

[herman]

Is there another FS for Linux with deduplication that works?

[Orv]

I looked at dedup under ZFS, and concluded the massive memory usage and the fragility made it not worth it. Is the calculus any better under btrfs?

[Anonymous Coward]

Good!

Now how about systemd, SUSE ? Do you really want to go where RH is pushing ?

[chasil]

Oracle - the ZFS/BtrFS connection

Oracle launched the development of BtrFS and supports it in their Red Hat clone.

https://docs.oracle.com/cd/E37670_01/E37355/html/ol_btrfs.html

Oracle controls the licensing for ZFS, and is actively preventing it from from reaching Red Hat.

Oracle has issued XFS patches (toward dedup), and is likely extremely familiar with Red Hat's position.

https://blogs.oracle.com/linuxkernel/upcoming-xfs-work-in-linux-v48-v49-and-v410%2c-by-darrick-wong

Red Hat has removed BtrFS to compromise Oracle's clone.

I am guessing that Red Hat wants either a) Oracle to contribute more to Red Hat for BtrFS support (in terms of cash, code, or both), or b) Oracle to release ZFS under a compatible license.

Oracle distributes a "Red Hat-compatible kernel" which might now be stripped of BtrFS. There are likely ways around that, but it forces a divergence which is to Red Hat's liking.

[AdamWill]

Optional

"even if, as was the case with this decision, Red Hat was never a big contributor or fan of btrfs."

This is not accurate. SUSE's graph actually shows that Red Hat *was* a big contributor to btrfs from 2009 to 2012; Red Hat is the darker red that comes second from the top in the bars. It looks like in 2011 and 2012 RH was one of the largest contributors.

As I've written elsewhere, the story of RH and btrfs is basically that we were indeed quite enthusiastic about it initially (as those numbers show), then we got less enthusiastic about it and tailed off contributions and future plans for it correspondingly.

[Anonymous Coward]

I think RH bet for neither of your options. RH recently bought Permabit, so dedup and compression should be available for current storage stack soon. ZFS/BTRFS management layer should be replaced with stratisd and udisk projects.

Instead of developing something "new" they opted to improve current stack (CoW for XFS) and add new features (Permabit) to achieve same or similar result but with stability provided by years of testing of current solutions.

[[e-mail]]

Yeah sounds like RedHack. Same ones that gave us the ever crashing systemd ....