Hacker News Reader

Comment by zfsthroway1 | Hacker News Reader

Btrfs is used on millions of production servers (Facebook...) and can essentially solve the same storage problems that ZFS was designed to solve, using similar principles (CoW...). Btrfs deservedly got a bad wrap for many years because it had unacceptable bugs, but they seem to have finally quieted. SUSE ships and supports Btrfs for its enterprise Linux, and even Red Hat made it the default fs for Fedora. Also, Oracle can't sue you for using Btrfs, whereas Oracle has refused to have a lawyer send Linus a letter saying Oracle won't sue people for using ZFS on Linux, despite Linus' request to Oracle for such a letter saying its OK.

View on HN

Comments like yours come up whenever anyone dares discuss ZFS or FreeBSD. Sure, you can use Btrfs, xfs, ext4 or whatever the hell you want on Linux if you want. Nobody is trying to take away your toys. But Linux is already dominant -- you don't need to convince people to use Linux. FreeBSD, however, doesn't get attention it deserves. Hence why threads like these occasionally pop up.

And for what it's worth, ZFS development pre-dates Btrfs. You can make all the arguments for Btrfs that you want but ZFS is still the vastly more mature filesystem out of the two. Hence why the few examples people can come up with regards to Btrfs usage are companies with the resources of Facebook (as opposed to ZFS which is used by companies large and small).

btrfs is used by orgs like facebook in a very limited way, and afaik not for big multi-disk storage pools with raid-style devices like ZFS is generally used.

btrfs is still very rough for things like raid5/6 (where you want to prioritise available capacity), and unfortunately there are lots of reports of recent corruption (even on single disk FSes) every time we have a thread about it on HN. I'm one of those people with recent experience of corruption with btrfs + compression.

ZFS isn't flawless, and the license situation means distribution is more awkward on Linux - except for Ubuntu, who have a different view to other distros on what is allowed with it legally. This means that root on ZFS is a real pain on many distros, and possibly not something you should really do, but ZFS has really solid multi-disk pool support & working + battletested support for things like RAIDZ.

But this isn't linux, this is FreeBSD. The license issues with CDDL & GPL don't apply here, so FreeBSD has native ZFS support. It works well (especially in 13, where it's up to date with the main OSS OpenZFS work), and the installer will quite happily assist you with root on ZFS.

I'm surprised to learn that btrfs still has corruption issues, even for simple cases. It's been in development for 12 years already; I wonder what the factors behind this are?

It's disappointing :(

I'd love to use btrfs on root on linux, and I try it on my home server and VMs reasonably often (and this is a xeon + ECC etc, and when I use ZFS/xfs/ext4 I don't get FS issues). I keep finding it's often still fragile unfortunately (and snapshotting is still painful compared to ZFS!).

Conversely, I haven't had a single btrfs issue on my home server, which has gradually expanded from a 2x2TB RAID1. New disks get added to the pool via 'device add' and off we go. That's one of the biggest reasons why I use btrfs, it lets me turn storage into a large generic pool instead of individual partitions and drives, and it's very flexible when combining drives of different sizes.

The only issue I did have was a bad ASM1061-based SATA controller, which would corrupt data in weird ways, throw up alignment errors, generic I/O errors, all kinds of issue. That can hardly be blamed on btrfs.

Because it was a RAID1 pool and a checksumming filesystem, I could switch the affected drive to a known good SATA controller and correct all of the corrupted data, to bring everything back in line. I found it very robust and undramatic. I strongly assume it would have worked more or less the same on ZFS, but ZFS is less flexible when adding disks (have to add new separate vdevs instead of integrating individual drives), so I stick with btrfs.

Don't buy ASM1061-based SATA controllers. At the very least, get something Marvell-based, or an LSI-based SAS controller in IT mode, if you want to get fancy.

Yeah, I notice some people have very different experiences. It's odd.

For me it's a mix of NVMe drives, SATA SSDs on Intel SATA, or SATA SSDs on LSI SAS HBAs (in IT mode).

It doesn't seem to be pinned to specific hardware, sadly - and the exact same hardware works fine with zfs/ext4/xfs.

It would be tempting to chalk it up to marginal storage controllers and/or memory or even flaky power supplies. I've seen all three result in very weird and hard to diagnose issues, which presumably a more critical and checksumming filesystem is simply better at sussing out than a more old-fashioned FS like ext4 or XFS.

But from the impression of the type of hardware you're running, I highly doubt that is the case. And of course ZFS would be affected, too.

I agree - but in cases of marginal hardware I'd expect to see more strange issues than just specifically FS corruption with btrfs.

At one point it was limited to if I was using compression, but using compression was the major reason I wanted btrfs for that use rather than ext4/xfs.

> And of course ZFS would be affected, too.

In theory, yes. But one of the design goals of ZFS was to be resilient against faulty hardware. On paper that seems an impossible task but I've seen first hand just how impressive it is where I had a faulty raid controller which would randomly disconnect HDDs but only under heavy load. It took weeks to debug this -- it was so bad it actually caused Solaris to crash (which made fault diagnosis all the harder). I then switched to FreeBSD, which was a little more stable so enabled me to get a little more meaningful diagnostics and when I realised what the fault was, I was amazed I hadn't actually lost any data. At one point the fault was so bad it completely trashed the superblock but FreeBSD's ZFS tooling meant I could recover that superblock and the entire outage took all of 10 minutes.

On the flip-side, the few times I've used btrfs I've either been left scratching my head at the confusing tooling, or pulling my hair out because of data loss. On one system, the storage pool -- which literally just consisted of one HDD and no clever raiding -- reverted itself by 6 months. I was an early adopter of ZFS and never ever experienced so much as a blip despite running it on hardware that really should have caused ZFS to go tits up. Yet Btrfs would get it's knickers in a twist on stable hardware.

I get my stories here are purely anecdotal but I her the same kinds of stories crop up over and over again from other people too. So I find it very hard to take Btrfs seriously as a ZFS replacement. But then given ZFS is an older and more mature project and ZFS already works pretty damn well, I also question why anyone would want a replacement to ZFS when they could just use ZFS.

> But then given ZFS is an older and more mature project and ZFS already works pretty damn well, I also question why anyone would want a replacement to ZFS when they could just use ZFS.

Basically just licencing. The great irony is that btrfs was started by Oracle (not sure if they're still involved) before they acquired Sun. A relicensing effort to GPL would probably be better, but, you know, Oracle.

I argued in the past that OpenZFS should have contributors sign a small CLA which permits relicensing to GPL to prepare for this nonetheless, it's a small effort and could save a lot of effort later.

Your experience with a faulty controller mirrors the issues I experienced with the faulty ASM1061 controller; unstable and flaky under load.

Recovery was quite undramatic once the affected disks were put on a known stable controller. Btrfs-check followed by a scrub got everything back in order.

And btrfs gives me one thing that ZFS can't do (yet): a completely flexible RAID1 storage pool where I can add and remove disks as I want, the only limitation being that no one disk can be larger than half the total pool size. For me, this flexibility is a killer feature.

I worked a bit with SLES (the enterprise suse), they use btrfs as root (snapshot feature), but the HARD recomendation from them is:

-Use btrfs JUST for the OS (just use mirror if you have to) nothing else..don't change any switch, don't defrag...don't touch it with the exception of making and restoring/deleting snapshots.

-Use XFS for Data

I suspect they wrote thousands of lines of code "Agile" style, without nearly enough upfront design. Now there is too much code to rewrite and it's too hard to change. I would be more sympathetic if it just lacked functionality, but instead the marketing claims all these features that are likely to eat your data. IMHO, it's an example of where open-source and the "bizarre model" failed to deliver.

I guess there's a reason redhat dropped to support btrfs.

I guess only facebook and suse are big users.

I tend not to rely on what facebook does with its software stack. Even by looking at what they release as open source, it's usually "works for me" and not tailored for general public and I think it's in their culture not to care about other use than for themselves.

It's hard to think it's a good proof that btrfs is ready for everyone just because facebook is using it.

Oracle cannot sue anyone for using ZFS, thanks to the patent protection clause in CDDL.

Reply on news.ycombinator.com