Consider licensing ZFS as optional add-on
I realize I'm stepping off the cliff here but I have used ZFS on Solaris and BSD and find its capabilities quite awesome. It's not too far behind what I have with NetApp filers. Btrfs, on the other hand, seems quite far behind and though I would be pleasantly surprised if it reaches production grade by RHEL7, I'm not going to hold my breath.
Given Red Hat's weight in the industry, perhaps it can convice Oracle to either GPL ZFS or at least reach reasonable licensing terms for Red Hat customers who wish to purchase such an option. Orace is, after all, copying RHEL for it's own Unreakable Linux.
I can see benefit to using it, perhaps others would too. ZFS snapshots, deduplication, and compression alone are awesome features. If not, I'll enjoy the lonely island I found after falling off that cliff.
Responses
There are 2 projects which are dedicated to bringing ZFS to Linux:
- http://zfs-fuse.net -> Which uses a (pretty slow) FUSE implementation
, but is quite far in terms of features.
- zfsonlinux.com -> Which uses a kernel module, is fast, and since the latest beta, has filesystem support.
Probably, if Redhat wants to include ZFS in the distribution, there should be a choice made between these 2 projects.
Hi,
ZFS is licensed under the CDDL and that is incompatible with the GPL v2 that is used by the linux kernel.
Have a look at https://secure.wikimedia.org/wikipedia/en/wiki/Common_Development_and_Distribution_License to understand it.
CU
Jens
Pro
678 points
"Wouldn't an explicit licensing deal between Oracle and Red Hat permit the former to sell an add-on module to its customers who are willing to pay for it to use ZFS legally (and under support) on RHEL? I'm sure it's not that easy and might not only be cost-prohibitive to Red Hat customers but also something Red Hat would be unwilling to approach Oracle about." -- Patrick Young
Although I cannot answer for Red Hat, considering Oracle's "approach" to Red Hat, this really isn't an option Red Hat has an option to explore at all.
E.g., anything of value, and not already GPL, Oracle hordes for distribution and support via the Oracle Technical Network (OTN) only. And even in the case of GPL, Oracle will only officially certify/support if it is distributed via the OTN with an active subscription.
This is the reality of Oracle, beyond it's stance on community in general. No one is going to solve this, not Red Hat, not IBM, not anyone. This is how they operate, even outside the community. Keep that in mind. ;)
As others have commented, we have no plans to bring any version of ZFS into RHEL. Not the FUSE based version or the in kernel version (which has an incompatible license).
What we are doing is working aggressively with the upstream file and storage world on multiple fronts:
* adding ease of use commands for existing file systems on top of LVM (ext4 & xfs)
* working on btrfs aggressively, both by helping lead development and contributing to testing
What would be much more interesting to those of us in the file system team is what exact use cases you like, what you look for in terms of commands and of course feedback on both btrfs and the upcoming "fsadm" interface for existing file systems.
Thanks!
Guru
2135 points
I'd rather see BTRFS worked on to get up to production-ready level by RHEL7.
I would like to see functionality like NetApp's SnapMirror / Snapvault functionality, either at the volume level (LVM, DM), or at the filesystem level (btrfs).
With SnapMirror, a volume gets snapped and the diff between this and the previous snapmis replicated to a remote system and applied there. In case of failure, the data on (one of the snaps) from the replicated machine can be used. It is also possible to replicate snapshot's back from the destination to the source machine.
Snapvault uses the same basic method, but for backup purposes, to offload retention by moving snapshots to a remote system.
Red Hat
Pro
534 points
Would like to see this for local file filesystems regardless of the storage infrastrcuture or would you prefer to leverage back-end tools like NetApp's if they were present and available?
Sorry for the late response. What I would like to see is that a clear choice is being made on where to put functionality (and effort): on LVM / DM level or on filesystem level. It seems to me a lot of duplicate work is being done where the same functionality is being implemented both at the volume level and on the file system level.
My preference is mostly implementing functionality on the volume level. My perfect feature list would be:
- Thin Provioning. This is already worked upon and a TP on RHEL6.3
- Snapshotting. The new implementation with nested snapshotting is also TP in RHEL6.3
- Deduplication. On the block level. choice between inline or post-proces
- Replication. There is DRBD and ELVM, but there are some references on the Net on Device Mapper Remote Replication Target from Heinz Mauelshagen (a RedHat employee), with cool features like fan-out and cascading replication.
-
HSM functionality, auto tiering blocks between devices based on user defined policies
-
Caching (where ie a SSD or RAMFS device can work as a block level cache for ie a SATA device)
-
Lossless Compression.
Together with Gluster this functionality would make RedHat a serious contender against the overpriced enterprise storage vendors.
BtrFS would be a much better choice than ZFS.
Because?
Red Hat includes BtrFS as a tech preview
Oracle use Btrfs in their production Oracle Linux products
SUSE includes BtrFS in their SLES 11 SP2 as production ready
ZFS is CDDL and BtrFS is GPL
Not true. If Oracle use it, probably in a Lab maybe. Oracle owns ZFS technology. And use ZFS on all their storage offerings, their appliances. it's all over the place. Been on SunOS and Solaris since the sparcstation days, and started adopting ZFS when first it came out with s10, and went to production in just a year, and never seen brtfs running on any of the Sun products, or even heard oracle officially uses it, ever...
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.