FreeNAS & TrueNAS Plans - 2020 and Beyond!

[ornias]

I'd suggest not being like that about it. iXsystems has been a primary driving force behind ZFS on FreeBSD for many years, and just because the underlying codebase for OpenZFS is changing to ZoL does not invalidate the contributions that have been made by FreeBSD over the years. Without FreeBSD having taken the lead in integrating and developing ZFS for many years, it is likely that the community wouldn't have had such exposure to ZFS, and it's quite likely that ZoL would not have come to pass.

I said it's not a good reference about the CURRENT (actual maybe wasn;t the right choice of wording) state of OpenZFS/ZoL development, because that discussion is not done here. The forum for OpenZFS development is either Github, the Mailinglist, Leaderships meeting etc.

Dan referred to a announcement post on a forum thats not directly (!) involved with ZFS development from 2017. I tried to point out that a link to the github or leadership meeting is A LOT more usefull.

There is no need to be disrespectful in this manner towards the forum. If you don't think the forum is relevant, please feel free to troll elsewhere.

There is also no need to strawman me and also no reason to call me names like troll.
I never said IXsystems input was irrelevant. I never said the contributions from BSD where irrelevant.

I never intended to troll anyone and afaik my previous posts where also not indicative of someone who is only here to troll.
So I think when it comes to "uncalled for" attitude, You and I both have some issues ;)

 

[jgreco]

I said it's not a good reference about the CURRENT (actual maybe wasn;t the right choice of wording) state of OpenZFS/ZoL development, because that discussion is not done here. The forum for OpenZFS development is either Github, the Mailinglist, Leaderships meeting etc.

Dan referred to a announcement post on a forum thats not directly (!) involved with ZFS development from 2017. I tried to point out that a link to the github or leadership meeting is A LOT more usefull.

That's your opinion. In mine, it doesn't seem to matter. The ZFS universe is moving once again down a rocky road towards more unificiation, and the efforts of a number of development teams, not all of whom share the same goals, are likely to continue to shape the future of ZFS more than "leadership." Those of us who have been in the ZFS community for awhile have seen any number of "leaders" announce major and minor features and then watched as they remained vaporware. I'm sufficiently cynical that I don't believe most of what I hear until there's production-grade code and it's integrated into releases. It doesn't matter where the "news" comes from.

This forum is closely tied to one of those development teams, obviously, and the specific influences it has on ZFS has changed over time, and of course there is some amount of viewing issues through rose-tinted glasses, etc., but generally the members here with a deep interest in ZFS development are reasonably well informed.

There is also no need to strawman me and also no reason to call me names like troll.
I never said IXsystems input was irrelevant. I never said the contributions from BSD where irrelevant.

I never intended to troll anyone and afaik my previous posts where also not indicative of someone who is only here to troll.
So I think when it comes to "uncalled for" attitude, You and I both have some issues ;)

No, difference is, I'm a moderator and I'm asking you to please not be like that. If you're here arguing about the relevance of this forum to ZFS, I see that as trolling, and I'm telling you that it is unnecessarily inflammatory and that I'm asking you not to do it. I did not call you a troll, it was conditionalized. Please take offense only if you were intending to troll, otherwise please take it as notice that it could be taken as trolling by other readers. Lively discussion is of course encouraged.

 

[ornias]

That's your opinion. In mine, it doesn't seem to matter.

Thats your opinion. The fact is that the primary development discussion about this feature has not been here, thats what I was refering too. That doesn't mean no relevant discussion takes place here, but it's kinda useless refering to years old announcements when there is an actual discussion going on somewhere else.

"leadership" was not something I tried or am willing to discuss (I think we both agree thats irrelevant), it was just what the monthly VOIP meeting I was refering to is called.

I'm sufficiently cynical that I don't believe most of what I hear until there's production-grade code and it's integrated into releases. It doesn't matter where the "news" comes from.

I think we all agree there, as I refered to earlier, most features get announced and still take 2-4 years(!) to get into any production ready shape.

No, difference is, I'm a moderator and I'm asking you to please not be like that

The fact you are a moderator, doesn't mean I was wrong. It just means I have to do like you ask ;)

Please take offense only if you were intending to troll, otherwise please take it as notice that it could be taken as trolling by other readers

No offense taken, notice taken. ;)

 

[Yorick]

Allan Jude made a few valid remarks about vdev topology changes and why this feature although in high demand is probably last on the list. Listen to the latest episode of BSD now for that: https://www.bsdnow.tv/340

I listened to that, and that was specific to "Block Pointer Rewrite", and reshaping the way data is distributed. Typically reshaping is something I'd think you might want across multiple vdevs, and to an extent people might want it when expanding a raidz.

So, the "last feature to ever be added" is Block Pointer Rewrite, not raidz expansion.

"ZFS wants written data to be immutable" makes sense to me. I think that's why in an expanded raidz, new data will use the new width, and existing data still uses the old width. There is a reflow going on, but no change to the data+parity width for existing data.

This is one of those ZFS-isms. If you really really need to reshape, send and receive. Given that "expand a raidz by 1 disk" is likely to be SOHO not Enterprise, I don't see a performance bottleneck in an expanded raidz, even without send/receive.

As for raidz expansion, from what I can see, what's missing is more people to test it, and to write better automated tests for it. That seems open to contributions.

Should this raidz discussion move to the proper thread for it, though?

 

[DDark]

Hello guys,

I am using FreeBSD/FreeNAS for some years now as Desktop/NAS, and to be honest, your decision to port FreeNAS/TrueNAS to linux makes me really sad. It sounds like a betrayal for me, as FreeBSD was always a solid and reliable platform with the best ZFS support beside Solaris. And instead of give your strenght to extend your BSD experience, you simply switch to Linux as many others do/did before. You say you keep on FreeBSD, but I do not trust that statement. Maybe you will see that it was not your best choice as there are many other competitors of linux NAS, anyway, no reliable ZFS there. And Btrfs... is not worthy to talk about IMHO.

 

[Patrick M. Hausen]

Who said FreeNAS would be ported to Linux?

 

[colmconn]

Who said FreeNAS would be ported to Linux?

Kris, in post #3 of this thread. Porting stuff to Linux is well documented in JIRA.

 

[Patrick M. Hausen]

We're specifically making all the portable bits (middleware and UI) able to run on other OS's for future product(s). Right now we're working to port it to Debian 11 (Bullseye)

"middleware and UI" is not "FreeNAS/TrueNAS"

 

[DDark]

"middleware and UI" is not "FreeNAS/TrueNAS"

You just have to start somewhere.

 

[Patrick M. Hausen]

@Kris Moore Could you clarify current plans with respect to switching to Linux, please?

 

[ornias]

@Kris Moore Could you clarify current plans with respect to switching to Linux, please?

He has already did:

Next, we’re going to be hard at work in 2020 to make our 12.0 code portable across multiple OS platforms. The middleware at the core of FreeNAS is already pretty portable today, and we want to start extending its reach. This also allows us to work on some new and exciting software products, complementary to FreeNAS, without disturbing or compromising the stability or reliability users depend on.

ERGO:
Replacing would mean: "going from BSD to Linux", which wouldn't be "multiple OS platforms" and would also not be "extending its reach" nor would it be " complementary to FreeNAS" ;)

Maybe you will see that it was not your best choice as there are many other competitors of linux NAS, anyway, no reliable ZFS there.

TrueNAS Scale (the Linux Technical Preview) is based on the same ZFS code as TrueNAS Core and is currently considered to be just as reliable. There is no kernel guarentee from the Linux Kernel team, but ZFSonLinux and OpenZFS aren't looking to be integrated into the Linux kernel anyway.

That being said, the ZFSonLinux and the ZFSonLinuxonFreeBSD (combined into OpenZFS2.0) have a pretty good trackrecord inadapting to kernel changes from both BSD and Linux already for years.

 

[zizzithefox]

Linux is now the main development platform for OpenZFS. It means that iXsystems customers need an alternative if FreeBSD encounters difficulties to stay on the train. Therefore, porting FreeNAS to Linux is a wisdom choice.

Well the fact that something is developed on platform X doesn't mean that X is the best platform for deploying it. IMHO, the right place to develop ZFS on Linux is the Linux kernel. Since this ain't probably going to happen as per Torvalds' not that unreasonable motivations.... I just think a better reason would be virtualization (bhyve... sigh), hardware support, interoperability with other os/fs, better support for containers and convergence.

Personally I will always prefer to have ZFS in the kernel, no matter the platform. Jeez... I would love to have that in Windows too.

 

[tvtue]

I suppose that's fair. As long as there is nothing actively preventing the current Ugly Hacks from working (in a completely-unsupported-you're-on-your-own fashion of course) then it's not a downgrade.

Hi, what are those ugly hacks? Can you list them?
cheers
timo

 

[HoneyBadger]

Hi, what are those ugly hacks? Can you list them?
cheers
timo

Enabling FC on FreeNAS has been covered as recently as 11.1 in the Resources section:

Fibre Channel on FreeNAS 11.1u4

There are a few cobbled guides for setting up fibre channel LUNs from version 9.x. I have tested a few things and found one shortcoming on the guides. they leave your LUNs exposed via iSCSI as well as fiber channel. Here I will provide a method...

www.ixsystems.com

I don't know offhand if there's a more recent guide for 11.2 or 11.3

With regards to enabling HA on FreeNAS I haven't seen anything recent enough to merit mention, as it was always fragile. If you're after a homemade ZFS HA solution, you're likely much better off building from scratch rather than trying to force it into an appliance that wasn't intended for it.

 

[tvtue]

Thank you HoneyBadger for your reply. Indeed I am out for a ZFS HA solution. And my thought was if I could enable it somehow by some commands I maybe would have been able to see and learn how it works. So you say it's better to use anything (Linux or FreeBSD) to build this from scratch. In terms of learning it, that may be even better but it takes longer probably. Thanks again and have a nice day all, timo

 

[headshotsofchicago]

Just a quick "hello" to the boards. Looking forward to engaging.

Jim

 

[cephyr]

can't wait to see freenas gui on debian
great for docker and VM's :)

 

[hescominsoon]

Just to clarify, FreeNAS as it exists will continue on FreeBSD for 12.0 and beyond. This will be bringing some of the same software-base to Linux to unveil some new products that are Linux-based in the coming months. If you currently are happy with FreeNAS as it sits today, you can expect to keep updating it on BSD going forward.

considering the continued "windowfication" of Linux via SystemD the day(if it occurs) that freenas moves away from BSD will be the day FreeNAS goes out of my tool box...I hope that day never comes.

 

[Yorick]

considering the continued "windowfication" of Linux via SystemD

That’s the distro and the desktop (GNOME, more often than not), not the Linux kernel. Void Linux, as one example, is very much not systemd, it uses runit.

Don’t blame the kernel for what distros do.

Arguably, sysvinit didn’t cover some use cases people really wanted covered. Systemd wasn’t the only option; it’s the one that got adopted. And, that’s not really relevant to TrueNAS Scale unless and until you find that it did adopt systemd, as well. Then, maybe, rail :).

 

[hescominsoon]

i know the difference between the kernel and not..however systemD is in the majority of distros..it's hard to find a distro easily that is not running systemd. There's a few..but int he end systemd is eating everything except the kernel....