@Devin_Kusek Hello and welcome to the Rockstor community.
Glad you like what we are doing. To address the issue of ZFS on linux and consequently Rockstor I’d like first to provide a little context:
You have already hit on the dubious licence under which ZFS is distributed and there is still much contention as to the legitimacy of distributing ZFS capabilities within a linux distribution. The CDDL is not known to be a good fit with GPL projects. Sorry but not a strong point for me so hopefully others can fill in more.
The taks of intergrating ZFS within Rockstor’s UI is not quite as straight forward as it at first may seem, this is due to btrfs being a generation on from ZFS by having block pointer re-write capability, something that is generally acknowledged by the ZFS developers as a feature that will never exist in that FS. It is something that the original ZFS developers had originally planned to add but it is now no longer possible to retro fit. The up-shoot is of course that ZFS is now considered maturity (within it’s current capabilities) and btrfs, especially in the raid 5/6 area is not. Of course btrfs is much younger as well. But nevertheless this capability lends an extraordinary flexibility to btrfs that is pretty much un-matched by any other existing COW file system. Rockstor directly benefits from this flexibility and it’s user interface is consequently ‘allowed’ to be flexibly by the same token. Introducing the same capabilities as we currently have whilst supporting ZFS is in some/most cases extremely non trivial whilst in others is actually impossible (ie raid level change). ZFS and btrfs are different organisms; although both share the rare COW nature.
I’m personally not interested in working on ZFS in Rockstor integration as I am of the opinion that we would always be playing catch up. Especially given that ZFS, even with the recent (note recent here) openZFS initiative, is not native to linux but to BSD (at least now). The ZFS on linux / openZFS project is having to integrate BSD ‘look-a-like’ systems within the linux kernel in order to ‘bolt-on’ ZFS capability to linux. Virtually every other fs in linux works differently and are integrated in a different way to how ZFS works with the linux kernel. This is a very significant component of the ‘hail ZFS on linux’ speak on the internet that is some how forgotten. I have only ever heard this mentioned by the Suse folk. So even though the on-disk-format and layers used to access it will be shared the ‘custom’ way it works with the linux kernel will be linux only. Hence the always playing catch up component. I personally think that ZFS will always belong more to FeeeBSD than to linux and I prefer to be working towards where the puck is going than where it has been.
Please excuse the potential rant nature of the above but also be aware that our very own Rockstor lead @suman had initially considered Rockstor to be based on ZFS and has been a ZFS contributor but ultimately went with btrfs. This had lead to an enormously flexible base upon which we can simply enact capabilities and ui components that non technical users simply expect (‘oh I’ve changed my mind re raid level’ or ‘Ill just add another disk to my array’). Also from the very ground up Rockstor is designed around btrfs’s capabilities. The vast majority of it’s functions would have to be re-written and or blocked / or otherwise explained differently in every interface were we to entertain ZFS as a ‘native’ storage format within Rockstor.
Obviously seemingly nothing in software is regarded as impossible (though this does rather deny the unsolvable arena of problems entirely) but I am strongly of the opinion that what Rockstor has achieved thus far is very much down to a focus on supporting a single FS as native. But it is also a recognised weakness as the world also contains partitions (Rockstor favours whole disk) and other file systems and by way of acknowledging this I have myself put quite a considerable amount of time into extending our disk, and in the future hopefully our filesystem, capabilities. However that does not include supporting ZFS as a btrfs counterpart within Rockstor. I also think that were we to introduce ZFS as a btrfs counterpart (which it is not) that it would severely complicate Rockstor’s interface and essentially ruin it’s advantage over every other NAS UI I have seen. We gain a lot from our btrfs focus and avoid the ‘everything and the kitchen sink’ approach that renders pretty much all other NAS UI’s as overly complex. I am particularly take by the apparent simplicity we are able to present by our focus and given human resources are always limited there are of course concerns of what is achievable. I would say that such an introduction would put us at least several years behind and would possibly loose us some key contributors.
Development is always a tricky game especially in the open as much work has to be put into preparing for the future while also serving current users. I think that Rockstor makes for a good (and improving) balance and as we see the btrfs dev folks marching steadily onward my hope is that Rockstor will in turn keep step with making these otherwise esoteric and exotic capabilities available in a super user friendly and accessible way.
To address your initial difficulties, (rather than those to come) re ZFS integration within Rockstor, it may help to appreciate that Rockstor is essentially CentOS 7.3 (1611) based (although the installer is still 7.2 (1511) based) and on top of this we run a much much newer kernel lifted straight from the elrepo ml (main line) kernel repository. I think that is the difficulty you are facing here as your reference from the text you used indicates the default kernel version of 3.10 rather than our current version of 4.10.
From you post I was not able to assess if your current unfamiliarity was with the linux OS in general or with Rockstor in particular :[quote=“Devin_Kusek, post:1, topic:3162”]
Im guessing because Im new to this OS that Im missing something.
[/quote]
If you could provide more context it should help with our (forum members) ability to help guide your efforts at an appropriate level. If you are prepared to suffer an inevitable Rockstor UI breakage then there is no reason at all that you can’t use Rockstor as the basis for you experiments, as long as you understand that it may well be more complicated than just using a standard server class linux distribution due to the specific customisation elements involved in Rockstor the distribution (though these are predominantly confined to btrfs related systemd scripts and mount behaviour). But the UI is very much tailored and written with btrfs in mind and ZFS is not by any means a drop in replacement, each has core capabilities that the other does not. Ie ZFS has zvols (a zfs backed block device) where as btrfs has no counterpart (currently anyway).
Don’t by any means be put off by my rather wordy and opinionated post in response to your very legitimate and welcome input, and all contributions have always been welcome. There are many members on this forum who are far more knowledgeable than me (probably most of them 
), however I do have a passing familiarity with Rockstor’s current workings and am busy hopefully making them a little bit more capable each day. Prior to my involvement with Rockstor I also used FreeNAS in multiple locations over a number of years. It is pertinent I think that they seems to have recently suffered some growing pains with their corral effort: such technology change elements within a project can be very time consuming and potentially very disruptive.
Hope that helps and lets also hope we get some more contributors to this thread.