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...