I know that Facebook is investing heavily in btrfs right now, but to be frank, I don't see the point. Whereas on ZFS, like any application that uses fixed block sizes, virtualization and databases _may_ require some alignment tuning to avoid a read-modify-write cycle, and ZFS works without fuss from that moment on. Any write-intensive applications grinds the filesystem to a halt until you disable the copy-on-write functionality for that file specifically, making it so snapshots, etc., are ineffective and the FS stops tracking the changes that would make them possible. btrfs fares far worse and requires much more tuning than a generic ZFS installation.Ī great example is that if you ever try to run a database or a large virtual machine on a btrfs mount, you'll quickly become acquainted with chattr +C for "nocow". While it's competitive on paper and there are several meta-arguments in its favor (being in mainline, for example), the cold hard facts just don't stack up. Yes, this is similar to my fairly recent experience with btrfs. It has the potential to be really good, and I want it to be good, but I don't believe it's there yet. In the meantime, I'm using ZFS on a variety of FreeBSD boxes with a variety of workloads (including one running more VMs than its RAM should support) and it's been rock solid.Īt this point it will be a long time before I give Btrfs another look.
I haven't played with the send/receive stuff, but it seems like a great solution for backups. In particular, OpenSuse's snapper has saved me countless hour of work. This is all disappointing because some of the things Btrfs enables are awesome. I can't recall exactly what happened to cause it, but I'm pretty sure I didn't do anything exceptional with the computer - I think I rebooted it from the GUI while it was doing a scrub in the background, but that's just a guess. One day it somehow got itself into a state where it would hang when mounting the filesystem read/write, but it would be fine if it was mounted read-only. I also have a laptop running OpenSuse Tumbleweed with Btrfs. Machines that use Btrfs root but do most of their work on NFS volumes don't seem to experience this issue. Anecdotally, this seems to be a problem when there is a lot of writing going on with the volumes. This is an ongoing issue, but I'm not in the team responsible so I don't know what they're doing with this. The solution in every case was to move that filesystem onto a non-Btrfs volume. At some point they get into a state where the weekly Btrfs scrub process hangs the machine for hours at a time. This happened within the last four months.Īt work, we have a number of machines using Btrfs. Rebuilt the VM but used XFS instead of Btrfs, it was rock solid. I had a VM running OpenSuse Tumbleweed - I know, rolling release, don't expect stability, etc - and it would consistently freeze after being up and unused for a few days. I've been burned by Btrfs enough times to avoid it.
0 kommentar(er)
