Hacker News Reader

Comment by Shalle135 | Hacker News Reader

Is there any specific reasons to run btrfs over for example ext4? You can create/shrink/grow pools, create encrypted volumes etc by using LVM.

It all depends on the application but in the majority of cases the io performance of btrfs is worse than the alternatives.

Redhat for example choose to deprecate btrfs for unknown reasons while SUSE made it it’s default. The future of it seems uncertain which may cause a lot of headache’s in major environments if implemented there.

View on HN

Redhat and SUSE (SLES) are both enterprise environments, so at every level, they have to choose one tech stack to go all-in on (i.e. to train their support staffs on), and then discourage their customers from using the others. (“Deprecating” a component, for such orgs, means that some of their customers are now stuck with it, and they’ll continue to support those customers in their use of it, but they certainly won’t support new customers using it.)

The fact that one enterprise-support provider went all-in on Btrfs, while another didn’t, basically tells you that the choice is pretty arbitrary. If no enterprise-support provider used Btrfs, then I’d be concerned.

The enterprise provider that actually develops btrfs continues to support btrfs, and one enterprise provider that doesn't stopped supporting it.

People treat RH stopping support of btrfs as some sort of death knell for it. Meanwhile all the btrfs users are confused why RH's opinion should matter at all when they weren't that involved with developing it in the first place.

As an opensuse user, btrfs has saved multiple machines from botched updates by letting me revert to the snapshot from right before the update was applied (opensuse's update tool automatically takes snapshots before and after updates).

Red Hat used to be heavily involved in Btrfs development. In fact, they are present in a huge chunk of its development in the first few years. But their developers were hired away by Facebook, leaving Red Hat with nobody who work on Btrfs regularly. That's the underlying cause for why they stopped supporting it. Hiring someone to work on Btrfs takes time and effort that they don't have a reason to spend right now.

> Redhat for example choose to deprecate btrfs for unknown reason

According to Josef Bacik, RH deprecated btrfs because he was the engineer in charge for Btrfs and had left the company.

https://news.ycombinator.com/item?id=14907771

I've also been running btrfs (on CentOS7) for about five years on my home NAS.

One advantage is it detects bit rot -- and you can scrub the disks once a week looking for the bad blocks.

I also like the inline compression.

I run at RAID1 and the only issue I had was several years ago there was a bug about freeing allocations so occasionally the filesystem would be full but not full.

Docker on btrfs can benefit from fs supported layers. It's fantastic!

I avoid LVM because trying to install with it always seems to break things, either making the install fail or breaking later during an upgrade. And I mean on normal-ass distros like Debian and Ubuntu, not anything odd, and not even with "fancy" features like disk encryption involved (I can only imagine the mess that'd introduce).

Then again I avoided Grub for years because I found it fiddlier and more breakage-prone than LILO, so possibly I'm just an idiot and/or jinxed when it comes to new things in Linux.

For me, killer feature is transparent compression, I work with a lot of numerical data in Postgres, and running it over btrfs is the only viable way to compress it.

Also, who uses btrfs in production? I only heard Facebook is using it somewhere but never read about others. Why is Facebook using btrfs yet there seems to be no publicity to make it more popular for external contributions.

Reply on news.ycombinator.com