> illumos' imminent death
Rumours of our death are, of course, greatly exaggerated.
Re:The Future of ZFS in FreeBSD
by Teknoman117 on Thursday December 20, 2018 @12:59AM
(#18722802)
I just wish the ZFS could be more tightly integrated into Linux than it can (due to licensing). Would be nice to not have two implementations of a crypto system, a raid parity computation system, block caching, allocation, etc. Oh well...
I hear you, especially on the block caching. ARC just does not interact well with FreeBSD's native block cache either.
Re:The Future of ZFS in FreeBSD
by Teknoman117 on Sunday December 23, 2018 @10:05PM
(#18750000)
The thing that really annoys me (if there is a way to fix this, please, comment) is that for zvols, whenever you read or write them, the blocks end up in both the ARC _and_ the Linux Page Cache.
is it just licensing? Doesn't it do its own thing in the vfs layer and perhaps others in a way that it wouldn't be accepted upstream either way?
Re:The Future of ZFS in FreeBSD
by Teknoman117 on Sunday December 23, 2018 @10:03PM
(#18749996)
It does do various things which the Linux kernel maintainers don't like (particularly how tightly integrated all the components are, something something "rampant layering violation"). While getting ZFS in-tree would be a godsend, I don't mind building as an out-of-tree module, just that it would be nice if didn't duplicate so much functionality.
I don't see any reason ZoL couldn't stub out their own CDDL implementations and invoke Linux functions directly, where they are a suitable replacement. The problem is almost always going to be that ZFS was designed for Solaris and adapting it to use Linux APIs is non-trivial. The code duplication bothers me less than the page cache duplication / cache reclaim logic integration.
Re:The Future of ZFS in FreeBSD
by Teknoman117 on Sunday December 23, 2018 @10:00PM
(#18749985)
It's not just to reduce the amount of ZoL specific work.
If I understand correctly, the developers were saying there are specific parts of Linux where anything using them is considered a derivative work, and therefore even distributing source would be a violation of GPL. An instance of this is the crypto layer that was added in recently with the native dataset encryption. SPL actually reimplements this logic because the ZoL maintainers claim they can't use the Linux crypto subsystem without violating GPL.
There's no contradiction here. FreeBSD was never the primary contributor to (Open)ZFS (it was an Illumos thing), but we had the resources to make it a first class citizen on FreeBSD at a time when Linux wasn't doing that (mostly for licensing reasons).
It seems like the Linux world has gotten over the licensing problem one way or another, and at the end of the day Linux has something like 100x-1000x more developers to bring to bear at the problem. So between that, and illumos' imminent death, ZoL is the active upstream. FreeBSD is happy to benefit from the ZFS improvements in ZoL, especially given the collaborative spirit we've seen from the ZoL team so far. If anything, kudos to the ZoL folks for the huge amount of effort they've put in over the last handful of years.