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

181–190 of 352 posts

Re: ⁠Btrfs has been deprecated in RHEL

#181

Post by IgorPartola »

Wicher wrote: post #177
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.

Disk A and disk B both contain file SomeFile. On disk B this file has rotted. When reading the file SomeFile into memory, the read will be distributed among the disks (for performance reasons) (and it will probby need to span a multiple of the stripe size). Ok, file is read into memory, including the bitrotted part from disk B. Now we write the file blocks back - as one does. Voila! Both disks now contain the bitrot.…

Moreover, even if you don't read the file, and the bit rot is discovered during the monthly compare, at least on Linux the disk that is considered correct will be chosen at random. So you need at least three disks to have some semblance of protection. Have you guys seen many laptops that come with three or more drives?

Just use ZFS. Even on a single disk setup you will at least not get silent bit rot.

Re: ⁠Btrfs has been deprecated in RHEL

#182

Post by jorrizza »

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...

Re: ⁠Btrfs has been deprecated in RHEL

#183

Post by josefbacik »

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 much work being done that you can't just cherry pick individual fixes. This makes it a huge pain in the ass.

Then you have RHEL's "if we ship it we support it" mantra. Every release you have something that is more Frankenstein-y than it was before, and you run more of a risk of shit going horribly wrong. That's a huge liability for an engineering team that has 0 upstream btrfs contributors.

The entire local file system group are xfs developers. Nobody has done serious btrfs work at Red Hat since I left (with a slight exception with Zach Brown for a little while.)

Suse uses it as their default and has a lot of inhouse expertise. We use it in a variety of ways inside Facebook. It's getting faster and more stable, admittedly slower than I'd like, but we are getting there. This announcement from Red Hat is purely a reflection of Red Hat's engineering expertise and the way they ship kernels, and not an indictment of Btrfs itself.

Re: ⁠Btrfs has been deprecated in RHEL

#184

Post by [deleted] »

erikb wrote: post #98
jmspring wrote: post #10

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.

In enterprise installations people only install software that they can receive support for. So the biggest server farms probably all run something like RHEL or SLES. Of course for private usage it's a little ove rthe top. But RH also offers solutions there. There's an upstream OS with all the cool stuff: Fedora. And a downstream OS that is just as stable as RHEL but free: CentOS (not sure if I get the name right. The…

[deleted]

Re: ⁠Btrfs has been deprecated in RHEL

#185

Post by gcp »

pgaddict wrote: post #107
gcp wrote: post #73

Earlier quoted context omitted.

As for the significant technical issues, one thing is the core decision to make it a CoW system, which has fundamental performance issues with many workloads that are exactly those used in the server space. You can disable CoW, but you lose many reasons to use btrfs in the first place if you do. When I gave up on it there were also fundamental issues with metadata vs data balancing, not-really-working RAID support, a…

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.

Re: ⁠Btrfs has been deprecated in RHEL

#186

Post by binaryphile »

ars wrote: post #175
stargrazer wrote: post #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 so…

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.

"Never go to sea with two chronometers; take one or three."

- adage cited in the Mythical Man Month

Re: ⁠Btrfs has been deprecated in RHEL

#187

Post by gigatexal »

ars wrote: post #175
stargrazer wrote: post #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 so…

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.

Re: ⁠Btrfs has been deprecated in RHEL

#188

Post by croon »

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.

Sure, but the issue could be configuration, drive, interface, etc. It's impossible to speculate in, but what we know is you have trouble with one machine, and it's the only one that has used XFS. It's unfortunate, but likely a coincidence, or at least unrelated to XFS at its core.

I've been using XFS for 10 years without the issues you seem to be having.

Re: ⁠Btrfs has been deprecated in RHEL

#190

Post by appleflaxen »

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…

thanks for this context; i read this thread previously and had no idea of the "why" behind the news item. great comment to understand better.
Post reply on HN