Red Hat Appears To Be Abandoning Their Btrfs Hopes

[gbcox]

on the other hand, SUSE supports it fully and the shapshotting makes life easy to go back when updates fail. Now, I have done a few opdates without the need of rolling back and the painful part is that, where it's needed a few times -- RHEL, you don't have the possibility :-(

It doesn't matter what SUSE does or doesn't do. It isn't ready for use on RHEL.

[waxhead]

The biggest problem I've had with BTRFS is the ext4 convert utility. Failed on me every. single. time. without exception. Lost a home workstation upgrading debian 7 stable to 8 stable, lost a ubuntu xfce variant laptop upgrading to BTRFS for after upgrading versions, lost a ubuntu server version upgrading after upgrading versions.

The two systems I have started as single disk BTRFS with compression have not given me many problems but given how unstable the file system is when using the built in upgrading tool it makes me question its reliability. So bad that I noticed a while back the upgrade tool is even marked as troublesome on the wiki but the convert utility doesn't say a darn thing during upgrade like the fact that it might nuke your data. Wonder how many people have been burnt in the last few years using the supposable safe ext4 to BTRFS convert utility that is described as super simple and stable when from my experience it has never been very stable.

Well what can I say. We converted a multi terrabyte ext4 filesystem to btrfs without any trouble at all. I have *only* done this once, but that was on a recent kernel.
If you have a btrfs filesystem that originate form Debian 7 (kernel 3.2) you are not exactly at the "stable" side of things.
Btrfs was from my experience (as well as the debian btrfs page) ok from and including kernel 4.4 or so. So from my point of view you have been toying with an experimental filesystem so stuff like this are expected.

Yes, parts of btrfs is still experiemental, but other parts are quite stable. Remember to have backups when playing with experimental stuff. People seem to forget about that and if you follow the ext4 mailing list there is a lot of scary stuff there too so again backups is a pretty good idea if you value your data!

[starshipeleven]

It -will- be written in rust and python. And knowing RH it will be GPLv3. And thank god too. We're finally getting to an age where people are realizing C stopped being effective 30 years ago. Compute architectures just simply put, don't look or act anything like C. They haven't for the past 30 years or more. Get over it and learn something modern please.

Yeah, because "computer architectures" totally "look or act like" any kind of high-level language like Rust or even crappy (performance-wise) and even-higher-level interpreted script languages like Python (aka a more powerful Bash).

While still technically a high-level language, C is the modern day "assembler", anywhere you really need performance you use it (and add assembler where you really really need it only). Stratis is a wrapper, so it's not going to be doing a lot of performance-intensive jobs.

Seeing Rust in use is sure nice, but let's not get overboard.

[PuckPoltergeist]

That isn't an official Redhat statement. That is from a Btrfs developer who hasn't worked at Redhat since 2012

And who is still in contact with his former colleagues.

- and even he admits that Btrfs "isn't ready for Redhat's customer base." I would think that if Redhat believed that Btrfs was the best solution for their customers they would have invested resources in it's development. They did not. All you need do is look at the Btrfs development history and connect the dots.

They have decided between employ a developer for a filesystem and employ the maintainer of another. Btw. at this point, Red Hat put massive effort into XFS already, way more than into btrfs. The decision looks easy to me.

[PuckPoltergeist]

Still after the proposed fix to make the testcase's disk space utilization better, Edward Shishkin asked about whether the developers could provide any "sane upper boundary" for nodes with low utilization but unsurprisingly, they didn't. No guarantees.

https://lkml.org/lkml/2010/6/21/127

This mail and the following

[duby229]

Yeah, because "computer architectures" totally "look or act like" any kind of high-level language like Rust or even crappy (performance-wise) and even-higher-level interpreted script languages like Python (aka a more powerful Bash).

While still technically a high-level language, C is the modern day "assembler", anywhere you really need performance you use it (and add assembler where you really really need it only). Stratis is a wrapper, so it's not going to be doing a lot of performance-intensive jobs.

Seeing Rust in use is sure nice, but let's not get overboard.

Which wasn't even my point at all, but you're right. You make it sound like that's a good thing, but not really.

[gbcox]

And who is still in contact with his former colleagues.
They have decided between employ a developer for a filesystem and employ the maintainer of another. Btw. at this point, Red Hat put massive effort into XFS already, way more than into btrfs. The decision looks easy to me.

I am in touch with many former colleagues from various companies also... that doesn't make me a spokesman for their companies. That doesn't mean he's wrong... but it also doesn't mean he is correct or has all the facts. Not sure what you are talking about employ... if you are saying that they have assigned resources for XFS and Stratis, yes I would agree. My point is that it's quite obvious that Redhat doesn't believe Btrfs is the best strategy for their customers. If they did, they have a funny way of showing it.

[chithanh]

https://lkml.org/lkml/2010/6/21/127

This mail and the following

I only see how Edward Shishkin again pushed his question for formally guaranteed boundaries on disk space utilization (https://lkml.org/lkml/2010/6/30/377) and not getting this question answered in any direct way.

[waxhead]

It -will- be written in rust and python. And knowing RH it will be GPLv3. And thank god too. We're finally getting to an age where people are realizing C stopped being effective 30 years ago. Compute architectures just simply put, don't look or act anything like C. They haven't for the past 30 years or more. Get over it and learn something modern please.

I think you are wrong. 30 years from now C will still exist (but probaby in a more modernized form). The shiny modern languages will probably rust away (!!). I may be wrong but I think I am right. History have shown that C remains.... I guess we'll have to wait and C

[PuckPoltergeist]

I only see how Edward Shishkin again pushed his question for formally guaranteed boundaries on disk space utilization (https://lkml.org/lkml/2010/6/30/377) and not getting this question answered in any direct way.

Last paragraph in the mail I've quoted. Explanations are in the following mails.