Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

⁠Btrfs has been deprecated in RHEL

access.redhat.com

Post reply on HN
Print view View original

201–210 of 352 posts

Re: ⁠Btrfs has been deprecated in RHEL

#201

Post by amorphid »

jorrizza wrote: post #182

Strange decision, as systemd-nspawn[1] specifically mentions and supports btrfs as a CoW filesystem for its containers. And as far as I understand, systemd is primarily developed by Red Hat employees. So either they'll add support for CoW alternatives, or they'll remove btrfs support from systemd-nspawn all together. [1]: https://www.freedesktop.org/software/systemd/man/systemd-nsp...

There's nothing which prevents you from creating an empty block device file, putting btrfs on that, and mounting it.

Re: ⁠Btrfs has been deprecated in RHEL

#202

Post by feld »

josefbacik wrote: post #183

People are making a bigger deal of this than it is. Since I left Red Hat in 2012 there hasn't been another engineer to pick up the work, and it is _a lot_ of work. For RHEL you are stuck on one kernel for an entire release. Every fix has to be backported from upstream, and the further from upstream you get the harder it is to do that work. Btrfs has to be rebased _every_ release. If moves too fast and there is so muc…

The problem is that Redhat and others are refusing to challenge the norm and break away from the "freeze the release; backport fixes" mantra.

Stop backporting fixes. You're forking the codebase.

Ship exactly what upstream provides.

Teach upstream projects how to do better release engineering if they're abandoning major releases to early or breaking API/ABI in a minor release.

Stop backporting fixes. You're forking the codebase.

edit: also stop incorrectly backporting security fixes and creating new CVEs. Seriously. Stop it.

Re: ⁠Btrfs has been deprecated in RHEL

#203

Post by pgaddict »

jeltz wrote: post #113
pgaddict wrote: post #107

Earlier quoted context omitted.

I find the suggestion that the technical issues are caused by the CoW design a bit strange. Sure, making the filesystem CoW-based means there are some inherent costs, but it allows the filesystem to implement some interesting features (e.g. snapshots) in a more efficient way. For example if you want to do snapshots with ext4/xfs, you'll probably do that using LVM (which you can see as turning the stack into a CoW). I…

Didn't one of your benchmarks show that nodatacow on Btrfs resulted in a major performance improvement? But that might just show an issue with Btrfs's CoW implementation rather than CoW in general.

Yes, I've done some tests on BTRFS with nodatacow, and it improved the performance and behavior in general. Still slower tha XFS/EXT4, but better than ZFS (with "full" CoW).

But as you mention, that does not say anything about CoW filesystems in general. It merely hints the BTRFS implementation in not really optimized.

FWIW while I do a lot of benchmarks (both out of curiosity and as part of my job, when evaluating customer systems), I've learned to value stability and predictability over performance. That is, if the system is 20% slower, but provides stable and predictable behavior, it's probably OK. If you really need the extra 20% you can probably get that by adding a bit more hardware, and it's cheaper than switching filesystems etc. (Sure, if you have more such systems, that changes the formula.)

With EXT4/XFS/ZFS you can get that - predictable, stable performance. With BTRFS not so much, unfortunately.

Re: ⁠Btrfs has been deprecated in RHEL

#204

Post by feld »

gigatexal wrote: post #187
ars wrote: post #175

Earlier quoted context omitted.

Use mirror raid and have mdadm do a full disk compare/check every month (this is the default on Debian). Additionally use smartmontools and configure it to do a short self test each night, and a long self test (i.e. full disk read) each week. This will catch/flag errors early, which mdadm will then detect.

Or just do raidz6 in ZFS and call it a day.

Actually it's better to just do mirrors. Avoid RAIDZ at all costs if you care about performance and the ability to resilver in a reasonable amount of time.

Re: ⁠Btrfs has been deprecated in RHEL

#205

Post by feld »

jacquesm wrote: post #84
justin66 wrote: post #24

I am as happy as anyone that XFS is finally getting the position of honor it deserves on enterprise Linux (something like 15 years later than it should have, grumble grumble) but it doesn't really take the place of what btrfs was trying to do. Only ZFS is in a position to do that. I wonder if there are any plans for supporting the native port on RHEL.

I have one machine running XFS but if that one is representative then I won't be installing XFS anywhere else and would happily discourage others from using it. It is terribly slow when doing some fairly common operations when you have a large number of small files.

You have to tune the parameters at filesystem creation time if you care about small file performance. It was designed for large files.

Re: ⁠Btrfs has been deprecated in RHEL

#206

Post by pgaddict »

gcp wrote: post #185
pgaddict wrote: post #107

Earlier quoted context omitted.

I find the suggestion that the technical issues are caused by the CoW design a bit strange. Sure, making the filesystem CoW-based means there are some inherent costs, but it allows the filesystem to implement some interesting features (e.g. snapshots) in a more efficient way. For example if you want to do snapshots with ext4/xfs, you'll probably do that using LVM (which you can see as turning the stack into a CoW). I…

> it allows the filesystem to implement some interesting features (e.g. snapshots) in a more efficient way. Interesting features are worthless when reading and writing data is prohibitively slow. Or when there are documented cases where updating a file in random-access manner can cause its storage requirement to balloon to blocks^2.

Are you suggesting that's a problem with CoW in general, or with BTRFS implementation specifically?

I would say ZFS works extremely well (at least for the workloads I care about, i.e. PostgreSQL databases, both OLTP and OLAP). I know about companies that actually migrated to FreeBSD to benefit from this, back when "ZFS on Linux" was not as good as it's today.

Re: ⁠Btrfs has been deprecated in RHEL

#207

Post by admax88q »

feld wrote: post #202
josefbacik wrote: post #183

People are making a bigger deal of this than it is. Since I left Red Hat in 2012 there hasn't been another engineer to pick up the work, and it is _a lot_ of work. For RHEL you are stuck on one kernel for an entire release. Every fix has to be backported from upstream, and the further from upstream you get the harder it is to do that work. Btrfs has to be rebased _every_ release. If moves too fast and there is so muc…

The problem is that Redhat and others are refusing to challenge the norm and break away from the "freeze the release; backport fixes" mantra. Stop backporting fixes. You're forking the codebase. Ship exactly what upstream provides. Teach upstream projects how to do better release engineering if they're abandoning major releases to early or breaking API/ABI in a minor release. Stop backporting fixes. You're forking th…

I think you're underestimating the stability that such practices provide for enterprise. This is what people pay Redhat for.

Not all upstreams are interested in doing release engineering. There are non zero costs to doing it. It can eat up time that can be spent on bug fixes and features, or even make it too costly to change direction if a certain approach to implementation is proving more difficult than it should be.

Look at the Linux kernel. The only reason there is a stable kernel series is because Greg K-H decided it was important enough. He was unable to convince any other developers to go along with it, and eventually the decision was "if you want to support it, then you can do it."

Do you consider the stable kernel series a fork of the codebase? Should everyone be running the newest kernel every release despite the plenty of regressions that appear?

Kernel developers are not interested in making every change in such a slow and controlled manner as to avoid any regressions. And it works for them. They get a lot of stuff done, and come back and fix the regressions later.

Re: ⁠Btrfs has been deprecated in RHEL

#208

Post by ajross »

feld wrote: post #202
josefbacik wrote: post #183

People are making a bigger deal of this than it is. Since I left Red Hat in 2012 there hasn't been another engineer to pick up the work, and it is _a lot_ of work. For RHEL you are stuck on one kernel for an entire release. Every fix has to be backported from upstream, and the further from upstream you get the harder it is to do that work. Btrfs has to be rebased _every_ release. If moves too fast and there is so muc…

The problem is that Redhat and others are refusing to challenge the norm and break away from the "freeze the release; backport fixes" mantra. Stop backporting fixes. You're forking the codebase. Ship exactly what upstream provides. Teach upstream projects how to do better release engineering if they're abandoning major releases to early or breaking API/ABI in a minor release. Stop backporting fixes. You're forking th…

If upstream releases were doing better release engineering in the way you mean then there would be no money to be made shipping RHEL as a product.

Re: ⁠Btrfs has been deprecated in RHEL

#209

Post by tw04 »

cyphar wrote: post #132
ge0rg wrote: post #75

Earlier quoted context omitted.

I think this is a political move disguised as technical move I think there are solid technical reasons to discourage Btrfs use, just to quote from the official wiki [0]: > The parity RAID code has multiple serious data-loss bugs in it. It should not be used for anything other than testing purposes. Now I don't know if this issue has been addressed already, or which kernels are affected, but the fact that there is a p…

The particular bug that sparked that warning was fixed a while ago, but as a precaution against "btrfs ate my data" stories they've removed the ability to create btrfs-raid from the CLI tools (you can still use md RAID with btrfs but you lose most of the benefits of btrfs that way).

Which benefits are those? Both synology and qnap have the ability to detect and correct bitrot doing btrfs on top of mdraid.

Re: ⁠Btrfs has been deprecated in RHEL

#210

Post by thehardsphere »

feld wrote: post #202
josefbacik wrote: post #183

People are making a bigger deal of this than it is. Since I left Red Hat in 2012 there hasn't been another engineer to pick up the work, and it is _a lot_ of work. For RHEL you are stuck on one kernel for an entire release. Every fix has to be backported from upstream, and the further from upstream you get the harder it is to do that work. Btrfs has to be rebased _every_ release. If moves too fast and there is so muc…

The problem is that Redhat and others are refusing to challenge the norm and break away from the "freeze the release; backport fixes" mantra. Stop backporting fixes. You're forking the codebase. Ship exactly what upstream provides. Teach upstream projects how to do better release engineering if they're abandoning major releases to early or breaking API/ABI in a minor release. Stop backporting fixes. You're forking th…

Taking this to its most ludicrous extreme, everyone should use Arch, and anyone who can't should... what? Not use Linux?
Post reply on HN