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