Live data from Hacker News

⁠Btrfs has been deprecated in RHEL

access.redhat.com

151–160 of 352 posts

Re: ⁠Btrfs has been deprecated in RHEL

#151
Considering the size of disks now-a-days, the chance of bit rot is high. And (I don't have the original source) on SSD, bit rots probability is higher still. So... ZFS and BTRF have meta-data as well as data checksumming. From what I've read, XFS may have metadata checksumming, but not on the data side of things.

I consider checksumming important. Do others? What is the solution? What other file systems offer that sort of capability?

Snapshotting is a second go-to function. Particularly when it is integrated into the LXC container creation process. (There was a comment elsewhere here which said LXC is on it's way out.... huh? what?)

Re: ⁠Btrfs has been deprecated in RHEL

#152

Well I used btrfs as a root filesystem for quite a while, until I realized it was pig slow for sync() -- I mean, it would take AGES to do and apt-get upgrade for example. I ended up having to do some tasks using 'eatmydata' [0] to make it all better, risking filesystem corruption in trade for speed. Also, at the time, there was no functioning fsck. So I moved back safely to ext4 and never looked back! [0]: https://ww…

apt-get upgrade syncs so often that 'eatmydata' gives a noticeable speedup pretty much everywhere (I got into the habit of using it for ext3/4) I don't get why apt syncs so often - isn't the main point of log-structured file systems their ability to recover after a crash or powerloss? If so, why should you need to sync more than one every ten seconds or so?

apt doesn't assume that you have a reliable filesystem. It assumes that you might crash at any moment, and it would be really important for you to have a consistent view of what packages are installed when you reboot.

Re: ⁠Btrfs has been deprecated in RHEL

#153
post #118

Earlier quoted context omitted.

"Need" as in "will you use it?". I played around with snapshots once and never really used them. So i clearly don't have a need for them on my laptop. Journaling on the other hand helps data safety a lot and i think it's not overly complex. I've had data loss happing in the past before journaling, but never again since then. So, wouldn't i need CoW for even better "data safety"? Maybe, but since i've never experience…

> "Need" as in "will you use it?". Well, many of us have experienced a botched system package upgrade or two. If the file system supports snapshots, then the package manager could automatically ensure fully atomic package upgrades. That should be reason enough, I should think. Re: The data loss issue: Yes, I've actually have XFS completely throw away a file system upon a hard power-off + boot-up cycle. (This was ages…

Good point. I'm using Debian as my Desktop for many years. I don't remember a "botched" system package upgrade in the last 5 years, but i've probably learned over years how to handle dpkg/apt.

The atomic updating is a very interesting topic and the reason why i find ostree/guix/nixos very appealing. Note that neither ostree nor guix or nixos make use of filesystem snapshots, afaik. OSTree even documents why it won't use filesystem snapshots: https://ostree.readthedocs.io/en/latest/manual/related-proje... Debians dpkg does not use snapshots as well.

So, it's a definitely a nice-to-have, but not something i need, because i can handle dpkg/apt much better then i could handle filesystem internals.

That's sort of the point: I don't want the complexity in the filesystem, but i am fine with it in userspace. I can use snapshots on filesystem level. Or i can use other backup tools in userspace. While it's certainly neat that the filesystem can do that, i'm perfectly fine with handling backups on another level.

Another example: It's certainly neat that there are a bunch of distributed filesystems (which by the way have A LOT of complexity and often can't handle all workloads you would expect from a filesystem). But i'd rather use either an S3-like network storage or build a system that scales well without relying on Ceph/Gluster/Quobyte/etc.

For example, in a hypothetical distributed system i'd rather use Cassandra and distribute data over commodity hardware then use Ceph. I'd rather handle problems with data persistence/replication on the cassandra level then debugging on file system level. Especially, when Cassandra has a problem i'll most likely be able to access all data atleast on the filesystem level. When my filesystem is borked, i'm in a much worse situation.

Re: ⁠Btrfs has been deprecated in RHEL

#154
post #110

Earlier quoted context omitted.

… for which Oracle owns the copyright.

I can't see that the copyright matter here. What matters is the license. Oracle can't unlicence what Sun code is already part of OpenZFS.

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't realise that these crappy patent suits in the background prevent all sorts of really basic stuff, like the fact most things now bounce through a cloud server (like Facetime) because there's a patent troll for peer-to-peer communications. And it's causing total waste as a result :( It also seems likely that prevented facetime becoming an open standard as Apple original promised. This is only 1 example though.

Re: ⁠Btrfs has been deprecated in RHEL

#155
post #30

It's OT but how many people actually use RHEL? Or CentOS (more likely). I'm not a fan of systemd, but have really loathed CentOS/RHEL compared to Debian/* for years.

The E stands for "Enterprise", so there's a hint about the target audience. You can get support for a 10 year old RHEL version after you entangle it to your stuck in time IT infra :)

It seems like "Enterprise" is synonym with "Technical debt"

Re: ⁠Btrfs has been deprecated in RHEL

#156
post #97
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...

There's a fairly simple reason for that which is that ZFS (and btrfs to some extent) are almost literally "ACID" databases. They do alot of the same double-writes and other safe behaviour the database is also doing. Those have a penalty and you're doubled up.

There are various guides around for tuning ZFS and database servers to try reduce that duplication, for example you can disable the InnoDB double write buffer because ZFS guarantees you don't need it. You also need to tune recordsize to match the database page size so that you don't accidentally create large multi page blocks.

Re: ⁠Btrfs has been deprecated in RHEL

#157
post #38

I think this is a political move disguised as technical move oracle pays the developers of btrfs [0] redhat hates the guts of oracle, since oracle released oracle linux, which is a clone of redhat enterprise (based on centos) so, redhat wants to cripple btrfs and hurt oracle. However, btrfs is my favorite FS, been using it on my home computer and backup drives for at least 6 years, before it was included in the kerne…

> However, btrfs is my favorite FS, been using it on my home computer and backup drives for at least 6 years, before it was included in the kernel, love the subvolumes, snapshots, and compression; never had issues with it . Slightly off topic. I chose btrfs as my main filesystem recently on a system running Ubuntu/Xubuntu. I have done some research on backing up (with the advantage of snapshots) but it looks like the…

performance during snapshot creation/deletes (presumably mostly the deletes) is one of the reasons I personally stopped using btrfs on my desktop. Now using ZFS root (with Ubuntu devel).

I had auto hourly snapshots and sometimes when it deleted one my entire system would hang for a few seconds and occasionally 10s of seconds.

Having said that I do suspect that might be partially related to also using ecryptfs on top, but still.

Re: ⁠Btrfs has been deprecated in RHEL

#158

Considering the size of disks now-a-days, the chance of bit rot is high. And (I don't have the original source) on SSD, bit rots probability is higher still. So... ZFS and BTRF have meta-data as well as data checksumming. From what I've read, XFS may have metadata checksumming, but not on the data side of things. I consider checksumming important. Do others? What is the solution? What other file systems offer that so…

> on SSD, bit rots probability is higher still

Do you have a source for this? So far I believed that bit-rot rates are pretty similar.

Re: ⁠Btrfs has been deprecated in RHEL

#159

Earlier quoted context omitted.

RPM-based distros make up maybe 10 % of the Linux installations these days, so we should not overstate RedHat's influence.

RHEL makes up maybe 99.9% of the Linux enterprise installations these days, so we can't overstate RedHat's influence.

Number of installations is not also necessarily a good metric. Red Hat is a very large company with a lot of money and and a lot of employees working on upstream Linux projects and driving their direction.

There are not that many companies doing the same. Which is why they have a lot of influence over the direction of things.

Re: ⁠Btrfs has been deprecated in RHEL

#160
post #152

Earlier quoted context omitted.

apt-get upgrade syncs so often that 'eatmydata' gives a noticeable speedup pretty much everywhere (I got into the habit of using it for ext3/4) I don't get why apt syncs so often - isn't the main point of log-structured file systems their ability to recover after a crash or powerloss? If so, why should you need to sync more than one every ten seconds or so?

apt doesn't assume that you have a reliable filesystem. It assumes that you might crash at any moment, and it would be really important for you to have a consistent view of what packages are installed when you reboot.

But ext3 and more advanced filesystems have been around for almost twenty years now... it seems an odd assumption that your filesystem is unreliable on any machine that isn't completely ancient (is anyone still using ext2, for instance?)
Post reply on HN