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

271–280 of 352 posts

Re: ⁠Btrfs has been deprecated in RHEL

#271

Post by pgaddict »

jeltz wrote: post #97
dijit wrote: post #86

Earlier quoted context omitted.

You're joking, surely. XFS has outperformed EXT4 in almost all "high" use-cases in my experience and testing: Large files (500GB~) or many small files (128k files * 2,400,000 or so). EXT4 under those loads is comically bad. BTRFS is also terrible at this, only XFS and ZFS are good at handling it.

On the other hand on database workloads, for example PostgreSQL, XFS and EXT4 are about equal these days. ZFS (at least on Linux) and Btrfs are both clearly slower on those workloads. Here is one benchmark, but I have seen plenty of similar benchmark results for PostgreSQL showing the same thing: https://blog.pgaddict.com/posts/postgresql-performance-on-ex...

I partially disagree with the claim that ZFS is slower than ext4/xfs. It is, but only as long as you don't use ext4/xfs on top of LVM to get similar snapshot capabilities etc. Then ZFS starts to win.

So if you only need a plain filesystem, ext4/xfs are great and you will get better performance.

If you need/want snapshots, e.g. to do backups that way, it makes sense to look at ZFS.

Re: ⁠Btrfs has been deprecated in RHEL

#272

Post by josefbacik »

pgaddict wrote: post #255
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…

I think a natural follow-up question is "Why Red Hat does not have engineers to support btrfs?" That is, if the lack of engineers is a symptom, what is the cause? I'm pretty sure, had RH wanted they could either hire or assign engineers to maintain the btrfs code, take care of patches from upstream, etc. So why didn't that happen? I wonder what is your opinion on that. I see a bunch of possibilities (not necessarily…

All this talk about Oracle is just plain stupid. Oracle doesn't control anything, the community does. One core developer still works on Btrfs from Oracle, the vast majority of the contributions come from outside Oracle.

Now as to

> "Why Red Hat does not have engineers to support btrfs?"

You have to understand how most kernel teams work across all companies. Kernel engineers work on what they want to work on, and companies hire the people working on the thing the company cares about to make sure they get their changes in.

This means that the engineers have 95% of the power. Sure you can tell your kernel developer to go work on something else, but if they don't want to do that they'll just go to a different company that will let them work on what they care about.

This gives Red Hat 2 options. One is they hire existing Btrfs developers to come help do the work. That's unlikely to happen unless they get one of the new contributors, as all of the seasoned developers are not likely to move. The second is to develop the talent in-house. But again we're back at that "it's hard to tell kernel engineers what to do" problem. If nobody wants to work on it then there's not going to be anybody that will do it.

And then there's the fact that Red Hat really does rely on the community to do the bulk of the heavy lifting for a lot of areas. BPF is a great example of this, cgroups is another good example.

Btrfs isn't ready for Red Hat's customer base, nobody who works on Btrfs will deny that fact. Does it make sense for Red Hat to pay a bunch of people to make things go faster when the community is doing the work at no cost to Red Hat?

Re: ⁠Btrfs has been deprecated in RHEL

#273

Post by pinewurst »

riffraff wrote: post #12
josteink wrote: post #3

Deprecated? In favour of what? Will Redhat too (like Ubuntu) start shipping ZFS?

I am curious as to the same. The document says > Red Hat will continue to invest in future technologies to address the use cases of our customers, specifically those related to snapshots, compression, NVRAM, and ease of use. but it's unclear what this means exactly.

Like their Permabit acquisition: https://www.redhat.com/en/about/press-releases/red-hat-acqui...

Re: ⁠Btrfs has been deprecated in RHEL

#274

Post by cryptonector »

4ad wrote: post #169
lathiat wrote: post #154

Earlier quoted context omitted.

Correct, Oracle would be in a position to do exactly that. Whether they do or not is another story but thats a pretty big liability. Given they are discontinuing Solaris and all-in on Red Hat Enterprise Linux I can't help but wonder why they don't do more with ZFS on Linux and therefor wonder if the NetApp patent suits or some other patent suit is preventing them from doing anything in the background. Many people don…

> Given they are discontinuing Solaris Oracle is NOT discontinuing Solaris. This FUD must die. https://news.ycombinator.com/item?id=14865237

This may be true, but when Oracle killed OpenSolaris, my non-Sun/Oracle friends wrote off Solaris and moved off it.

Killing OpenSolaris, and talking up SPARC so much, made people think that a) Larry just wants to vendor lock them, b) doesn't care about x86 support because it makes vendor lock-in harder for Oracle, c) the OpenSolaris derivative community will not be able to compete with Linux. So everyone has grudgingly accepted that Linux is it for the enterprise Unix market.

I hate this as much as you do. I I'm not sure that Oracle could turn this impression around at this point. To begin with it would have to restart OpenSolaris, and that might not be enough. OpenSolaris greatly helped Sun overcome resistance to Solaris, but it only went so far, so Oracle will have to do even more work to make Solaris' future bright.

This blog post is as relevant today as ever: https://blogs.oracle.com/bmc/the-economics-of-software

(And yes, it's STILL hosted at blogs.oracle.com. I'm almost afraid of mentioning it: who knows, it might get removed if Oracle execs notice it.)

Re: ⁠Btrfs has been deprecated in RHEL

#275

Post by chasil »

jsmthrowaway wrote: post #27
myrandomcomment wrote: post #21

Earlier quoted context omitted.

As a general rule if the end customer was finance/bank their Linux flavor was RedHat (someone to yell at when it broke). Other tech companies / web types it was Ubuntu. This was my experience in over 4 startups where these were are end customers. Your mileage may vary.

CentOS is extremely popular among startups. It lets you directly use RPMs, which many software publishers distribute on their own (not the case for debs, often), and gives you an upgrade path to buy RHEL when you want someone to yell at and not throw away all your automation. I’m not trying to start a flame war here (honest), but among most “usual web” ops folks I know, the opposite of what you’re suggesting seems to…

Oracle Linux is the only direct upgrade path for CentOS (afaik).

A full reinstall is required to move from CentOS to RHEL. Oracle has a procedure to directly convert CentOS, RHEL, and Scientific Linux into a supported Oracle Linux system.

KSplice is the most common reason why this conversion is required and mandated. If downtime can no longer be tolerated for upgrades to openssl/glibc/vmlinuz, this is the only available path.

Re: ⁠Btrfs has been deprecated in RHEL

#276

Post by cryptonector »

belorn wrote: post #251
Nokinside wrote: post #227

Earlier quoted context omitted.

Neither license forbids mixing with other licenses. As long as the demands of both are met, they can apply to the same source code. >If you are following the conditions of CDDL, you are violating the GPL. Basic binary logic. Relationship between licenses can be transitive but not commutative. As far as I know CDDL allows using with code under GPL but GPL does not allow using code under CDDL. CDDL copyright owners hav…

If CDDL has no issue with GPL conditions, then follow the GPL and everything is fine. CDDL has this text: "Any Covered Software that You distribute or otherwise make available in Executable form must also be made available in Source Code form and that Source Code form must be distributed only under the terms of this License" So you take some CDDL code, and some GPL code, and you put that whole new source code tree un…

CDDL is per-file.

Re: ⁠Btrfs has been deprecated in RHEL

#277

Post by chasil »

cjbprime wrote: post #268
chasil wrote: post #261

Earlier quoted context omitted.

Oracle has essential control of both "nextgen" filesystems that should be used in Linux - as Sun, they developed and licensed ZFS, and they are the chief contributors of BtrFS. Their refusal to release ZFS under a license that is compatible with the GPL is keeping it out of Red Hat's distribution. This move by Red Hat must be seen as a provocation of Oracle, to force either greater cooperation and compliance in produ…

Oracle is not the "chief contributors" of Btrfs. If anyone is, it's Facebook. Chris Mason (the btrfs creator) worked for Oracle. He left in 2012. > This move by Red Hat must be seen as a provocation of Oracle I doubt it.

A thousand pardons - I am mistaking "initially designed" for current control.

https://en.wikipedia.org/wiki/Btrfs

"... initially designed at Oracle Corporation for use in Linux."

Re: ⁠Btrfs has been deprecated in RHEL

#278

Post by fanf2 »

jacquesm wrote: post #149
croon wrote: post #145

Earlier quoted context omitted.

> I have one machine running XFS but if that one is representative > Creating a new directory entry on an idle machine with plenty of CPU and memory takes seconds, ditto deletions. I think your answer lies in your premise then. It's not representative.

10's millions of files should have been the ideal use case for XFS, that's why I installed it in the first place. This was for the 'reocities.com' project and by the time I realized what the problem was most of the import had already been done so I let it run to completion but it makes updating the project a real PITA.

Your performance problem reminds me of this dentry cache performance failure https://sysdig.com/blog/container-isolation-gone-wrong/

Re: ⁠Btrfs has been deprecated in RHEL

#279

Post by willglynn »

usefulcat wrote: post #193
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.

Yes it can detect errors, but it can't continue to function correctly (read: return the correct data) because it doesn't know which copy of the differing data is damaged because it doesn't have checksums. Moreover, if it doesn't always read both copies of the data (which it may well not, for performance reasons), then you have the possibility of silently propagating damaged data to all mirrors in the case that damage…

Yep. "What happens if you read all the disks successfully but the redundancy doesn't agree?" is a great question.

Mirrors and RAID5: there's obviously no way that `md` software RAID can help, since it doesn't know which is correct. What about RAID6 though? Double parity means `md` would have enough information to determine which disk has provided incorrect data. Surely it does this, right?

Wrong. In the event of any parity mismatch, `md` assumes the data disks are correct and rewrites the parity to match. See "Scrubbing and Mismatches" section in `man 4 md`:

https://linux.die.net/man/4/md

If you scrub a RAID 6 array with a disk that returns bad data, `md` helpfully overwrites your two disks of redundancy in order to agree with the one disk that's wrong. Array consistent, job done, data... eaten.

Re: ⁠Btrfs has been deprecated in RHEL

#280

Post by chasil »

josefbacik wrote: post #272
pgaddict wrote: post #255

Earlier quoted context omitted.

I think a natural follow-up question is "Why Red Hat does not have engineers to support btrfs?" That is, if the lack of engineers is a symptom, what is the cause? I'm pretty sure, had RH wanted they could either hire or assign engineers to maintain the btrfs code, take care of patches from upstream, etc. So why didn't that happen? I wonder what is your opinion on that. I see a bunch of possibilities (not necessarily…

All this talk about Oracle is just plain stupid. Oracle doesn't control anything, the community does. One core developer still works on Btrfs from Oracle, the vast majority of the contributions come from outside Oracle. Now as to > "Why Red Hat does not have engineers to support btrfs?" You have to understand how most kernel teams work across all companies. Kernel engineers work on what they want to work on, and comp…

Oracle certainly controls the license for ZFS.

Release under a compatible license would likely see a ZFS kernel module appear in EPEL immediately; Red Hat would likely replace XFS with ZFS as the default in RHEL8 were this legally possible.

Oracle supports BtrFS in their Linux clone of RHEL. It certainly appears that Red Hat is swallowing a "poison pill" to increase Oracle's support costs (and I'm surprised that they have not swallowed more).

http://docs.oracle.com/cd/E52668_01/E54669/html/ol7-about-bt...

With these new added costs, Oracle might find it cheaper to simply support the code for the whole ecosystem (CentOS and Scientific Linux included). Given the adversarial relationship that has developed between the two protagonists, an enforceable legal agreement would likely be Red Hat's precondition.

Otherwise, BtrFS has been mortally wounded.

Post reply on HN