Hacker News Reader

> it feels to me like there is a persistent & vocal small group of people who seemingly either have some agenda that makes them not wish to consider BTRFS

Look here is the problem. The BTRFS people declared multiple time that it is stable. For a few years it was repeatably 'BTRFS' is stable now if you use it in such an such a away.

But then it destroyed a drive.

Then it a few years later and now it was actually stable.

But then it destroyed data again.

I know what they are saying about themselves but unfortunately the project has simply lost credibility with a lot of people. File system should be developed to be stable first and then slowly add features never being unstable. They shouldn't still regularly destroy peoples data after years of years of development.

While at the same time ZFS has been basically stable since early days, many developers at Sun switched their root drives to ZFS before it was even officially released. It never had years and years of routine instability.

> Few other file systems seem to face anywhere near as much criticism,

Where few file system claimed they were stable for years while routinely losing data. The file system has one job first and foremost, don't destroy users data.

This is not a conspiracy, this is simply the reality that tons of people have lost data because BTRFS repeatably claimed stability when it wasn't.

Its now another couple years later, likely this wouldn't happen again. But that after all these years they still haven't managed to get RAID 5/6 fully working doesn't exactly scream confidence. So me and I assume many others simply have lost confidence in the project and the approach they take to the development.

If a filesystem looses your data, you never use it again.

Kirk McKusick creator of UFS/2

Netflix has been using ZFS in production for many years now. Unnamed research companies are using ZFS moving PB's of data. NetApp is FreeBSD based and was on the forefront of what we now call ZFS. I'm totally biased, designed many production critical systems with ZFS at it's core in one way or another. The power of ZFS send and receive function is tremendous to say the least, it beats any file based synchronizing methods.

Send/Recv and snapshots by far my favorite features, I keep snapshots of my root drive on my NAS so if my main m2 drive dies in my desktop, i can just boot a live cd and send/recv to my new drive and reboot and i'm back where i left off.

I also keep a clean copy of an installed debian install snapshot on my NAS so i can just send it to new machines rather than run through the whole setup. works great.

Snapshots & send-receive are my favorite BTRFS features too! I too love snapshotting Debian installs & send'ing them to new machines for atomic updates, or to build live usb images. I've been using Pottering's "Revisiting How We Put Together Linux Systems" naming system for my subvolumes, and that's worked fairly well[1]. I even did some fiddling around with enhancing Debian-live to load btrfs into ram a while back, so I could atomic update, de-mount the boot drive, &c[2].

Oh you are talking about ZFS, aren't you. ;)

Playing the "who came up with it first" game doesn't particularly interest me. Again, it feels like a spirit of competition when to me, that seems like a bad spirit: we should be cooperative & boosting each other. We're both open source, we're both trying to make civilization possible & to share greatnesses.

[1] http://0pointer.net/blog/revisiting-how-we-put-together-linu...

[2] https://github.com/rektide/debian-live-boot

>we should be cooperative & boosting each other.

Is that why you sound like a sour apple?

I'm sour because it feels like zfs folks in particular have it in for btrfs and it's very tiring. there's so many OSes which default to btrfs that there's be some real modern evidence if there were problems but we are constantly dogged by massive negativity.

>OSes which default to btrfs

No just two Gnu/Linux distributions:

openSUSE/SLES and Fedora

And SUSE (SLES) tells you (strong recommendation) to use btrfs just for the OS (for data XFS, just like RHEL) and just in a mirror configuration.

Look i work since ~forever with SLES, and if you operate it in mirror mode (just os), don't touch it and just make snapshots i never had problems. But i HAD complete data-loss with btrf many times when i did for example a defrag and re-compress, those are native btrfs-tools, and that is not acceptable to me. The Filesystems is THE place in a OS where errors like that are not acceptable (to me).

>Netflix has been using ZFS in production

User of freebsd myself but that is BS, Netflix uses freebsd and UFS2 on the openconnect device.

https://openconnect.netflix.com/en/

You watch youtube about netflix they state clearly that they use ufs.

I "think" it's that one

https://www.youtube.com/watch?v=veQwkG0WdN8

Microservice-backend is linux/aws

We UFS for content serving, and a mix of UFS and ZFS for boot/log/config filesystems.

We use UFS for content because we rely on zero-copy async sendfile for our high performance video serving data path. When using ZFS, sendfile is not async, and because ZFS uses ARC rather than the page cache, it requires a copy from ARC to network with ZFS, so its yet ready for our high performance workload.

We don't use RAID at all.

>ZFS for boot/log/config filesystems.

Thanks for clarification, so can i assume that bectl/adm is in full swing?

One guess I can make for the "hate" BTRFS gets is probably because everyone loves their data and doesn't expect to "fight" with a file system to get access to it.

E.g. Sailfish OS is perhaps the only mobile OS I know that uses / used BTRFS in production (and they adopted it nearly 6-7 years ago!). And some of its users have had issues with BTRFS in the earlier versions - https://together.jolla.com/questions/scope:all/sort:activity... ... in fact, I too remember that once or twice, we had to manually run the btrfs balancer before doing an OS update. For Sailfish OS on Tablet Jolla even experimented with LVM and ext4, and perhaps even considered dropping BTRFS. (I don't know what it uses for newer versions of Sailfish OS now - I think it allows the user to choose between BTRFS or LVM / EXT4).

Most users consider a file system (be it ZFS or BTRFS) to be a really low-level system software with which they only wish to interact transparently (even I got anxious when I had to run btrfs balancer on Sailfish OS the first time worrying what would happen if there was not enough free space to do the operation and hoping I wouldn't lose my data). Even on older systems, everybody frustrated over the need to run a defragmenter.

Perhaps because of improper expectations or configurations, some of the early adopters of BTRFS got burnt with it after possibly even losing their precious data. It's hard to forget that kind of experience and thus perhaps the "continuing hate" you see for BTRFS - a PR issue that BTRFS' proponents needs to fix.

(It's interesting to see the progress BTRFS has made. Thanks to your post, I may consider it for future Linux installations over EXT4. Except for the hands-on tinkering it required once or twice, I remember it as being rock-solid on my Sailfish mobile.)

Suse uses btrfs in production for the root filesystem, and they have done so for years.

https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha...

And I get why (snapshots are wonderful), but opensuse, albeit tumbleweed, is also the only OS I've had lose its root filesystem and force me to reinstall. Some of us distrust btrfs for a reason.

(Details: Corrupted filesystem, happened twice, ~2019 IIRC, on a single disk system so not even touching the RAID code, first time couldn't repair, second some didn't try. Hasn't happened again and wasn't just a checksum error so I doubt that hardware is at fault but could be wrong.)

I've lost data in BTRFS setups each of the three times I've given it a try over the course of 6 or so years. Root drive just became unrecoverable. These are all single disk setups

Meanwhile I've been running ZFS for close to the same time and have never lost anything.

I get it's an anecdotal view point but that's a very hard reputation to rebuild for BTRFS.

I really just don't care about anecdotal data bits like this, especially when these attempts were tried probably 8+ years ago under who knows what conditions. How long ago did you give up btrfs, how long has it been, since your 6 years of trying it?

I think you may have unearthed the problem with btrfs. I know little about file systems and I know it might eat my data.

If the btrfs failed for you, you’ll remember and likely won’t try again. I had that experience with a now defunct hard drive maker. After the second replacement one failed I vowed never again.

They probably should rename it.

Counter anecdotal view point, I've been using BTRFS over the last 4 years now on multiple drives and multiple systems. No data loss has occurred.

If it was so bad that nobody had positive anecdotes it would have to be nightmarish. It's like a car models reliability. A bad model new off the line is still liable to have years of trouble free usage just fewer on average. The difference between reliable and unreliable is the difference between 2 small negative probabilities over many iterations.

> BTRFS has proven remarkably stable for a while now. A decade ago that wasn't quite as absolutely bulletproof, but today the situation is much different.

When I did a fresh install of Fedora 33 on my primary workstation 3 months ago, I had exactly the same rationale for sticking with the default BTRFS selection. "I'm sure it has come quite a long way since I last tried it, I would like to have some of those features, I know there are some large production installations now, and the fact that it's the default in Fedora is a sign of confidence from the community."

After 2 months of use, I ended up with a corrupt filesystem in the middle of my work day and could not find any way to recover from it other than to do a full reinstall and restore my files from a backup. This was on a single NVMe drive in a system running a few small VM's, a browser, a chat client, and a few terminals. Thankfully I only lost a day's worth of work, but that's the last time I install BTRFS on any of my personal systems.

> [...] it feels a bit odd that BTRFS is such a persistent target of slander & assault.

My experience is obviously anecdotal (as are all individual experiences), so I won't be surprised if you dismiss my comment like you did nullwarp's comment. But "slander & assault" just seems like a weird way to dismiss all critics of BTRFS at once, as if everyone is out to get BTRFS. Filesystems have a thankless job. Do it right, and most users will never even think about it. But lose a user's data once, and you've likely lost that user forever.

> A number of big names use BTRFS, including Facebook. I have yet to see any hyperscalers interested in ZFS.

ZFS is excellent for large arrays of spinning disks, but if you're using a bunch of fast SSD's, performance really sucks. There is a lot of lock contention contributing to that which isn't noticeable on slower devices. I can't speak to FB's environment, but if they're managing a large number of SSD's like most hyperscalers, then ZFS would probably get ruled out based on performance comparisons.

I think there were at least 2 - 3 cycle where BTRFS declare itself as good and stable only to have people experiencing yet another Data Loss.

So once they are burnt, they wont come back.