On Thu, Apr 6, 2017 at 5:01 PM, David Sommerseth <[log in to unmask]> wrote: > I would never run btrfs on *any* production server, regardless of > currently available kernel versions. Because it is not deemed ready > for production yet. For testing I would be willing to experiment with > it, as there I can tolerate data loss. But never ever in production. It's being used in production at Facebook and in Oracle Linux and SUSE Linux. I don't know how SUSE does it but Oracle Oracle has kernel and kernel-uek packages. The kernel package is the same as SL's and the kernel-uek package provides a more recent kernel that goes hand-in-hand with the more recent btrfs tools. >> But the "kmod" release of ZFS seems to work well enough. I do have to >> disable automatic kernel updates, but that may be wise in some >> configurations anyway, YMMV. > > By all means, if you feel confident you will get the needed help > sorting out issues you hit on ZFS, go ahead. I would never do that, > even for ZFS. Once Red Hat enabling ZFS on a kernel where it is native > in the upstream kernel, not being labelled tech-preview - that day I > will consider ZFS for production. If btrfs reaches this stage earlier, > then I will consider btrfs instead. As I said in a previous email, zfs isn't going to be in-tree (unless, of course, Oracle changes its license...). Other than having installed Ubuntu on btrfs twice in a VM and played around with it, my knowledge of btrfs comes from [log in to unmask] Two things stand out from those threads. The btrfs developers seem to be more interested in adding features than in stability (in the words of committed btrfs users; more interested in features doesn't mean that stability is ignored) and, except for one or two kernels where there were regressions, every new iteration seems to bring better stability. > For me, the safest option _now_ is mdraid + LVM + XFS/ext4. Which > combined is somewhat closer (but not directly comparable) to the > features I like in both btrfs and ZFS. In addition, I know and > understand the toolset needed for mdraid + LVM + XFS/ext4 fairly well, > so I don't have to spend much extra time figure out the tooling if > something bad happens. But I'm also not going to spend time learning > btrfs/zfs tooling until it begins to be ready for production use. Not quite. Unlike btrfs, zfs is stable but it doesn't fulfill your in-tree criterion...