Live data from Hacker News

The Future of ZFS in FreeBSD

lists.freebsd.org

91–100 of 102 posts

Re: The Future of ZFS in FreeBSD

#91
post #62

Earlier quoted context omitted.

And? How's this relevant?

I mean, there's unlikely to be any official support of zfs on Mac and the fact Apple developed apfs recently could mean there's less appetite for community to port and support zfs on Mac.

>could mean there's less appetite for community to port and support zfs on Mac.

Eh? The community port and support already happened, years ago. I made the move myself from ZEVO once Spotlight support got mainlined but even that was a while ago and it already had a ton of great features before that. It is a small scale effort compared to Linux or FreeBSD of course, but it has kept up pretty darn well and is pretty solidly developed at this point. I push it pretty hard on my Macs and it's been pretty reliable, though there are definitely edge case oddities that can be found. You can also see the smaller scale of the effort in areas like the wiki not being fully up to date, or that booting off of it still is rough. Even so it's pretty solid at this point and hits all the core features including encryption.

Long term the big risk of course is that Apple will shut off all user low level access to their drives via T-series chips in Macs, since they don't actually give hardware owners the ability to use their own keys there. Ideally this would be illegal but I doubt any movement will be made on that in the US at least in the near future. Even so given that Apple up until recent has still been selling brand new Macs without it macOS itself will likely support running on those systems for a long time to come (Apple still officially supports running the existing version even on 8 year old MPs, granted with compromises but those had pretty fundamental divergences from modern firmware too). O3X is still pretty nice in the mean time.

Re: The Future of ZFS in FreeBSD

#92
post #89
post #40

Earlier quoted context omitted.

So Bryan Cantrill (CTO) and all the former Sun eng. will abandon SmartOS @ Joyent?

The rumor is that the decision was made above that level.

Any links/sources you could point towards, even unofficial rumors?

Re: The Future of ZFS in FreeBSD

#93
post #2

TL;DR FreeBSD will rebase its ZFS code from Illumos to ZFS on Linux (ZoL).

If the ZFS FreeBSD code are going to be taken from ZoL, what's the difference of use ZFS on FreeBSD and GNU/Linux?

Hopefully very little! With work on a windows port, os x support, and emerging encryption support - we might finally have a modern, nice, solid cross platform read-write-safe fs beyond fat32!

Encryption support should be on 0.8 (next) release:

https://github.com/zfsonlinux/zfs/milestone/12

Re: The Future of ZFS in FreeBSD

#94
post #22
post #9

Hope this puts to rest the claim that zfs on bsd is better maintained and integrated than zol!

> and integrated Considering one of thse comes default the base system and the installer can install to it, has jail(8) integration, etc etc and one of them is an addon which will never be merged to the main kernel (which is only a kernel), and because of this, will likely never be directly supported by the main linux distribution vendors, I'd say the jury is still out on this piece.. lack of base system integration…

> will likely never be directly supported by the main linux distribution vendors

Zfs is front and center for lxd on Ubuntu - and about as "supported" as can be?

I just can't wait for crypto support to really land in open zfs - would make it even easier to use for external drives (now encryption needs separate support, geli on bsd, dm-crypt/luks on Linux). And using zfs as a volume manager would make things in general easier and less complicated.

Re: The Future of ZFS in FreeBSD

#95
post #39

Earlier quoted context omitted.

> It also sounds like FreeBSD also lacks the resources to maintain an implementation of something like ZFS, which is ironic since not too long ago it seemed like one of the marquee features they had that Linux didn't. 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…

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

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

#97

Earlier quoted context omitted.

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

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?

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

#98
post #91
post #62

Earlier quoted context omitted.

I mean, there's unlikely to be any official support of zfs on Mac and the fact Apple developed apfs recently could mean there's less appetite for community to port and support zfs on Mac.

> could mean there's less appetite for community to port and support zfs on Mac. Eh? The community port and support already happened, years ago . I made the move myself from ZEVO once Spotlight support got mainlined but even that was a while ago and it already had a ton of great features before that. It is a small scale effort compared to Linux or FreeBSD of course, but it has kept up pretty darn well and is pretty s…

I’m not terribly afraid of Apple doing that move. With Core Storage, Apple already has abstracted away low level storage access years ago. Even if Core Storage was mandatory (which it isn’t), O3X runs perfectly fine on top of Core Storage either with or without ZFS encryption. O3X will continue to run happily as long as block-level storage access remains built into macOS. And it will because APFS is a very young filesystem, which depends on block-level access; it took Apple a decade to build APFS from scratch so there’s no way for Apple to get rid of this dependency without throwing APFS away and starting from scratch.

But what if Apple simply built APFS into one of the next generations of T-series chips so it can physically deny block-level access to software? Not going to happen: Apple needs APFS to work not only with built-in storage but also with external USB drives, RAM disks, DMGs, sparse bundles, and so on. This means APFS needs to remain in kernel space, and kernel code will continue to have block-level access, and so will O3X and all of its features.

Re: The Future of ZFS in FreeBSD

#99
post #97

Earlier quoted context omitted.

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?

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.

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.

Re: The Future of ZFS in FreeBSD

#100

Earlier quoted context omitted.

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

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?

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.
Post reply on HN