FreeNAS & TrueNAS Plans - 2020 and Beyond!

[joeschmuck]

Any chance iX could start releasing end of life dates six to twelve months in advance of stopping security updates to versions? For example, I have a lot of production kit running 11.1-U7 and although I keep hearing 11.1 is coming EOL 'soon' it would be good to have a fixed date so that I can plan updates etc.
Thanks

Agreed

 

[Letni]

FC is an enterprise feature, we don't normally see it deployed outside of an enterprise environment.

I run home-lab at home.. Direct attached FC support on 4 GB QLE cards is a core component of my setup.

The existing (hacked) functionality is enough for the time being, but better dashboard reporting and LUN masking would be amazing.

 

[Yorick]

Thank you for the roadmap!

So far, FreeNAS version numbers are tied to FreeBSD version numbers. If FreeNAS 12.0 uses FreeBSD 12.0, I might skip that version and wait for FreeNAS 12.1, because reasons and Plex plugin. I’d like to someday get the /dev/dri stuff to work, and that will require a still-supported FreeBSD version I wager. FreeBSD 12.0 should go EOL sometime February/March. I understand FreeNAS backports security fixes.

Happily FreeBSD 11.3 looks to stay supported for quite a while.

 

[HoneyBadger]

LUN masking

Curious about how this is implemented in TrueNAS actually, since as far as I know ctld has no support for it. You can somewhat ape the end-result with NPIV but it's nowhere near as neat and tidy.

 

[HoneyBadger]

Let me clarify. There will be a combined / shared image. Those features are exposed only on our Enterprise platforms, and also still have a TrueNAS license key (for support purposed and to unlock it on that HW)

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.

 

[gsrcrxsi]

How is GPU passthrough to jails or VMs coming?

 

[velocity08]

Hi All

Just wondering if trim support is in 11.3?
Will this be ZFS 0.8?

have had a bit of search around and cant find any info (maybe im looking in the wrong place)

We are looking at building out a FreeNAS All SSD system and trying to address potential issues with SSD ware, will be using Samsung PM833 SSD Enterprise calss SATA drives 7.68 TB.

if anyone could point me in the right direction i would be extreamly greatfull.

""Cheers
G

 

[seanm]

Just wondering if trim support is in 11.3?
Will this be ZFS 0.8?

TRIM has been supported since FreeBSD 10:

Chapter 9. ZFS

It's one area where ZFS on linux (ZoL) is behind.

FreeNAS isn't switching to ZoL aka ZoF aka OpenZFS until 12.x I believe, certainly not 11.3.

 

[velocity08]

TRIM has been supported since FreeBSD 10:

Chapter 9. ZFS

It's one area where ZFS on linux (ZoL) is behind.

FreeNAS isn't switching to ZoL aka ZoF aka OpenZFS until 12.x I believe, certainly not 11.3.

thanks for pointing that out.
i was reading on the forum that the current trim implementation on FreeBSD was clunky or not very good but they failed to elaborate the issue/ why.

do you have any insight into this comment and to what they are referring ?

””Cheers
G

 

[KrisBee]

@velocity08 Slides/video on OpenZFS new TRIM implementation might throw some light on that. Go here for links: http://open-zfs.org/wiki/OpenZFS_Developer_Summit_2019

 

[HoneyBadger]

thanks for pointing that out.
i was reading on the forum that the current trim implementation on FreeBSD was clunky or not very good but they failed to elaborate the issue/ why.

do you have any insight into this comment and to what they are referring ?

””Cheers
G

I would imagine the perceived issue is largely related to the finicky behavior of LSI HBAs and their ability/willingness to pass TRIM commands to connected devices. In order for the HBA to expose/relay TRIM it expects the device to support "Deterministic Read Zero After TRIM" sometimes shortened to DZAT or RZAT.

See this KB for details: https://www.broadcom.com/support/kn...map-support-for-lsi-hbas-and-raid-controllers

But even with this properly configured, there were reports that the SAS2008 (the most popular controller) would still fail to pass the commands. So the opinion came to be formed that "TRIM was broken" when it was usually the fault of the controller.

There's also the issue that prior to SATA 3.1 the TRIM command wasn't able to be queued, so when a device got a TRIM command it would drain it's queue and block I/O until finished. And then when Queued TRIM was added in SATA 3.1, there were implementation issues that caused instability and potential data loss.

TRIM over SATA works great for the most part, UNMAP over SAS similarly well. It's when you try the most common "bunch of SATA SSDs behind an LSI SAS HBA" that the fun starts.

 

[velocity08]

I would imagine the perceived issue is largely related to the finicky behavior of LSI HBAs and their ability/willingness to pass TRIM commands to connected devices. In order for the HBA to expose/relay TRIM it expects the device to support "Deterministic Read Zero After TRIM" sometimes shortened to DZAT or RZAT.

See this KB for details: https://www.broadcom.com/support/kn...map-support-for-lsi-hbas-and-raid-controllers

But even with this properly configured, there were reports that the SAS2008 (the most popular controller) would still fail to pass the commands. So the opinion came to be formed that "TRIM was broken" when it was usually the fault of the controller.

There's also the issue that prior to SATA 3.1 the TRIM command wasn't able to be queued, so when a device got a TRIM command it would drain it's queue and block I/O until finished. And then when Queued TRIM was added in SATA 3.1, there were implementation issues that caused instability and potential data loss.

TRIM over SATA works great for the most part, UNMAP over SAS similarly well. It's when you try the most common "bunch of SATA SSDs behind an LSI SAS HBA" that the fun starts.

interesting, something that made sense to me from the forum slides re trim ZoL was the file system should be Participating in the trim process as it knows what blocks are actually free.

Is trim on Freenas something that’s automated or does it need to be run manually ?

 

[dasti]

Maybe... ;)

We're working on our next additions to the FreeNAS/TrueNAS family of storage software and will be using the same middleware and UI for much of it. More details in the coming months as we get things into shape in the R&D lab, but we're very excited for what's coming! Stay tuned!

that is a significant change in your strategy !
do you think you could compete with proxmox ?

 

[HoneyBadger]

interesting, something that made sense to me from the forum slides re trim ZoL was the file system should be Participating in the trim process as it knows what blocks are actually free.

Is trim on Freenas something that’s automated or does it need to be run manually ?

TRIM/UNMAP is automatic under FreeNAS, but it is of course dependent on the device presenting that capability to the ZFS filesystem.

 

[Philip Robar]

That would be Project Trident.

https://project-trident.org/post/os_migration/

I'm guessing that's what's being hinted at here in this post.

It's sad to hear that Trident is turning into "Yet Another" Linux Desktop. Without FreeBSD what's the point? What does Trident bring to the table that distinguishes it from the multitude of existing Desktops and window managers that already dilute Linux Desktop efforts? You should just shut it down now rather than making it wither away.

Phil

 

[Yorick]

This describes void as a Linux / BSD hybrid: https://itsfoss.com/void-linux/

BSD-like behavior on a Linux kernel. Which gets Trident what they needed: Regularly updated hardware support and regularly updated packages. musl libc and LibreSSL look promising.

That move makes sense to me. It allows Trident to focus on the desktop work, rather than wrestling with the underlying hardware support and package challenges.

 

[Philip Robar]

This describes void as a Linux / BSD hybrid: https://itsfoss.com/void-linux/

BSD-like behavior on a Linux kernel. Which gets Trident what they needed: Regularly updated hardware support and regularly updated packages. musl libc and LibreSSL look promising.

That move makes sense to me. It allows Trident to focus on the desktop work, rather than wrestling with the underlying hardware support and package challenges.

You're just repeating the Trident talking points without answering my questions. (And a Linux kernel with a BSD like behavior is even more pointless and misses one of the biggest reasons for choosing a BSD over Linux: A unified source tree from a single group.)

 

[Ericloewe]

Please discuss Trident in the appropriate section. Let's keep this about FreeNAS.

To be clear, you can mention Trident, compare with Trident and whatever, but let's not derail this.

 

[Philip Robar]

Please discuss Trident in the appropriate section. Let's keep this about FreeNAS.

To be clear, you can mention Trident, compare with Trident and whatever, but let's not derail this.

I looked for a Trident subforum and didn't find one.

 

[Ericloewe]

Not dedicated to Trident, but it practically is:

Related OS Discussion

Discussion for operating systems related to TrueOS.

www.ixsystems.com