On 06/04/17 21:17, Konstantin Olchanski wrote:
>> ... until ZFS is native in Linux ...
>> ... My meaning of "native" is that it is included in the upstream Linux
>> kernel, not a side-loaded product/project/kernel module.
> 
> At least for BTRFS, "native" seems to be a bad thing. The BTRFS version that comes
> with el7 is quite behind the current development version and unlike the "non-native" ZFS,

Perhaps you should re-read my previous mail [0] where I warn against
comparing btrfs against any other stabilized file systems?

Yes, ZFS is probably closest to btrfs on the feature whitepaper.  But
btrfs is not bleeding edge on EL7, partly due to the reasoning in the
other mail [0]; it is currently not really ready for proper production.
Several features are even disabled to reduce the risk of data loss even
further.  To my knowledge, btrfs is still a technical preview in RHEL 7 [1].

Red Hat won't introduce the latest and greatest upstream changes in an
enterprise distribution, especially not on a fresh and new file system.
And yes, 4 years since the on-disk format is labelled stable _is_ very
fresh.  Again, the "Technology Preview" label means:

   "However, these features are not fully supported under Red Hat
    Subscription Level Agreements, may not be functionally complete,
    and are not intended for production use." [2]

And as a reference point, I've also heard people bragging about openSUSE
shipping btrfs by default too.  But again, they have also disabled most
of the unstable features - which are the one which makes it a real
alternative to ZFS.

[0]
<https://listserv.fnal.gov/scripts/wa.exe?A2=ind1704&L=scientific-linux-users&F=&S=&P=15675>
[1]
<https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/ch-btrfs.html>
[2] <https://access.redhat.com/support/offerings/techpreview/>

> BTRFS is not packaged for easy installation into "my" linux. I guess I could run el7
> with a "non-native" kernel. (but how is that better than running "non-native" ZFS).

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.

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

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.


-- 
kind regards,

David Sommerseth