What is the future of TrueNAS CORE?

[Ericloewe]

I think it's a meaningful selling point for servers sold for the traditional file sharing role. Given the emphasis on making SMB work well, I imagine those make up a sizeable piece of iX's sales.
Also, keep in mind that it's a selling point, not strictly something customers need to do immediately after buying.

 

[morganL]

I completely agree, and actually this scenario was more or less what I had in mind. My point is: How many of those systems will make ixSystems any money?

Thanks for the concern, but obviously iX considers this.

We are already seeing paying users migrate from 13 to SCALE for storage-only apps. Services like syncthing, rootless administration, FIPS-level encryption are enabled due to SCALE on Linux. There will be more of these.

The current deficiency of SCALE is not storage-only use-cases, its jails.

 

[Ericloewe]

rootless administration

That one's not a Linux thing, though, it was a long-standing request that was just never implemented in Core.

 

[Johnny Fartpants]

In my experience in enterprise small bits and pieces such as VMs and/or containers are either run in the cloud or will be run in the cloud in the not-too-distant future. The area where cloud makes little to no sense is large scale storage and this is currently an area where TrueNAS excels. It seems to me that focusing one’s product on such a small area of the enterprise market makes little commercial sense. Companies that have already moved large amounts of data to the cloud are now trying to find a way back to On-Prem due to spiralling OpEx costs and this will continue to become a huge marketplace. Therefore, I personally would focus most of my attention on continuing to build the most advanced and reliable storage systems I can. Clearly to the average home user having the ability to run Apps on your NAS is cool and very helpful however is this alone going to bring financial stability long-term to the company that maintains the product we all love? I’m personally not against SCALE because its Linux and not FreeBSD however I am nervous about the future and if SCALE will be able to match the many years of stability we have seen and grown to trust in FreeNAS/TrueNAS CORE over many years.

 

[morganL]

I’m personally not against SCALE because its Linux and not FreeBSD however I am nervous about the future and if SCALE will be able to match the many years of stability we have seen and grown to trust in FreeNAS/TrueNAS CORE over many years.

We agree that CORE 13.0 is very stable...... now that its at U6.1. However, each release has to go through a maturation cycle to get there. CORE is more stable because we moved more of the innovation to SCALE and focussed on 13.0 stability.

SCALE inherits much of the same code - OpenZFS, Samba, TrueNAS middleware. Linux is new to TrueNAS, but frankly it is very mature, well tested, and the driver support is better.

I think we'll find that SCALE stability matches CORE later this year for storage-only use cases.

 

[Davvo]

CORE is more stable because we moved more of the innovation to SCALE and focussed on 13.0 stability.

I do not fully agree with this statement, but that's a topic that has been discussed plently already with marginal results.

Linux is new to TrueNAS, but frankly it is very mature, well tested, and the driver support is better.

Right. Any news about the ARC limit fix? Or has it already been released and I didn't notice?

I think we'll find that SCALE stability matches CORE later this year for storage-only use cases.

Hope so, I have nothing against SCALE. Linux on the other hand... kek. ^.^

 

[LarsR]

Any news about the ARC limit fix? Or has it already been released and I didn't notice?

Fix will be in Dragonfish by default, but there was a post a couple of weeks ago with instructions on how to set it in cobia. My arc sits at ~48GB of 64 without problems.

 

[winnielinnie]

Fix will be in Dragonfish by default

Due to the differences of ZFS/memory-management on FreeBSD vs Linux, will increasing the ARC limit on Linux (i.e, SCALE) have an unintended consequence of more swapping?

 

[Whattteva]

Does it have the same upper limit as CORE though? My ARC now sits at 55.6/64 GiB. Would like it higher, but services are taking up 5.6 GiB. Not sure why it's taking so much. I don't run anything other than NFS, SMART, SMB, and SSH. I'm pretty sure I could configure a vanilla FreeBSD 14.0 with those same services and have it take far less memory. I'm guessing CORE runs a few other things under the hood.

 

[winnielinnie]

The middleware and UI could even be made a port to install on top of a stock FreeBSD.

I'd wager this would require zettarepl to be made into (and maintained as) a FreeBSD port as well, since it makes up a huge component of TrueNAS as an appliance.

 

[Patrick M. Hausen]

It is not? OK, I will fix that ...

 

[Ericloewe]

I know this is a FreeBSD vs Linux thread, but zettarepl vs. zrepl. Fight.

 

[winnielinnie]

zettarepl vs. zrepl. Fight.

Refereed by Sanoid?

 

[Patrick M. Hausen]

What's zrepl?

Regardless, zettarepl is on github, it's written in Python, it works on and officially supports FreeBSD, so creating and submitting a port should be trivial. If I hit any road blocks, I'll let you know.

Upstream, upstream, upstream, ...

 

[Juan Manuel Palacios]

Why? TrueNAS CORE is on github - it's open source. BSD licensed. Everything and the kitchen sink. We just need to find a team that doesn't start promising then loses steam within weeks. And we need to agree among developers about the direction and the first steps.

My personal idea:

• Fork - just do it.
• Agree on a name - no idea if FreeNAS is trademarked by iX and if yes, if they are willing to let it go. OpenNAS? Whatever.
• Understand the build process, familiarise myself so I can reliably build the status quo into a release.
• Now work starts: identify all local modifications they made to the FreeBSD source tree, judge if they are necessary, if possible undo them and find a different solution.
• The goal is to get a clean reliable build on a stock FreeBSD release - just put the "XY-NAS" on top.
• Same for the ports tree. One example I am aware of: they modified the collectd port. It delivers many more metrics compared to the stock FreeBSD one. What I do not understand: WHY THEY NEVER UPSTREAMED THAT?
• Once we can build "XY-NAS" on a stock FreeBSD and stock FreeBSD packages, switch from 13.2 to 14 or even 15, fix breakage until you get a clean build again.
• Then - and only then - think about new features, UI improvements etc.

My personal mantra when building on top of open source projects: never - at all costs - keep local modifications. Upstream everything. EVERYTHING. When my developer colleagues ask for a piece of software like - lately - phpfpmtop that does not exist on FreeBSD I create a port and submit it for inclusion in the ports tree. Picture Steve Ballmer's "dance monkey" but instead of "developers, developers, ..." go "upstream, upstream, upstream ..."

That's me. That's how I think open source should be done.

Kind regards,
Patrick

Hey @Patrick M. Hausen! As I've said before, I'm a developer with almost two decades of experience, mostly around web (PHP, hating Python passionately, but I do know how to hold my breath if necessary) and DevOps, but also some low-level OS tinkering, C, UNIX, lots of shell experience, networking, etc., and especially lots of love for FreeBSD (ironically, more and more over the last couple of years as CORE is being put out to pasture).

I also have experience from a while ago in open source and project coordination, from the time when I participated in MacPorts, even if that was many years ago and without much open source work, if any, since that time. All in all, I agree wholeheartedly with your vision here, and would love to participate in this initiative as much as I can, as time permits. Even though I use my TrueNAS CORE installation mostly from the command-line, and wouldn't bat an eye at the prospect of moving to vanilla FreeBSD plus a private collection of config files and scripts for my NAS & home lab needs, I would indeed appreciate the GUI surviving, so I definitely think this is a worthy pursuit.

Please feel free to ping if you're doing some type of project coordination and you'd like me to participate!

 

[Juan Manuel Palacios]

FreeBSD, Bastille, Ansible ... hey, even iocage exists and "just works" if you want to migrate your TrueNAS jails to stock FreeBSD. Migrating to more active and better architected Bastille can be done afterwards.

I'd so love to replace iocage with BastilleBSD on TrueNAS CORE!

I just wrote a couple of private application-agnostic iocage plugins for my deployment needs, and the process of extending them to customize them to specific applications was painful and underwhelming! I was longing for the Dockerfile-like layered and extensible approach, without of course jumping ship to Linux, and BastilleBSD is by far the cleanest solution for that type of programmatic jail construction usage.

 

[Juan Manuel Palacios]

Understood. That's why if I was to fork the project I would undo all the enterprise features and try to create a clean and working build on top of a stock FreeBSD. For single server without HA only, but with up to date jails, bhyve, ZFS etc.

The middleware and UI could even be made a port to install on top of a stock FreeBSD.

Again, 100% on this approach!

 

[Whattteva]

I'd so love to replace iocage with BastilleBSD on TrueNAS CORE!
I was longing for the Dockerfile-like layered and extensible approach, without of course jumping ship to Linux, and BastilleBSD is by far the cleanest solution for that type of programmatic jail construction usage.

Yeah, I like Bastille's templates with "Bastillefile" approach. Simple and sane syntax not unlike the shell commands except with targeting and some macros support. It also does not rely on having ZFS, so you can use it with UFS as well.

 

[Kris Moore]

Due to the differences of ZFS/memory-management on FreeBSD vs Linux, will increasing the ARC limit on Linux (i.e, SCALE) have an unintended consequence of more swapping?

Not expected. Expecting behavior to remain the same on either platform.

 

[Juan Manuel Palacios]

Yeah, I like Bastille's templates with "Bastillefile" approach. Simple and sane syntax not unlike the shell commands except with targeting and some macros support. It also does not rely on having ZFS, so you can use it with UFS as well.

I actually appreciate how iocage handles jails and ZFS datasets (filesystems & clones), and would love for BastilleBSD to do something similar (does it? Not too sure), but I agree that having ZFS should not be a requirement for a jail manager.