FreeNAS with Raspberry Pi. Is It Possible?

[BAAC]

Thank you very much for taking the time to read and answer my query. With the important caveats you mentioned and should one wish to test FreeNAS/TrueNAS on an 8 Gb RBPi running FreeBSD, would there happen to be a step-by-step install guide or sticky I could follow? Am I to use TrueNAS Core' or Legacy FreeNAS' repository?

 

[Ericloewe]

You would have to adapt the TrueNAS build process to build an ARM version and see what breaks.

 

[BAAC]

You would have to adapt the TrueNAS build process to build an ARM version and see what breaks.

Thank you! Will try and find relevant tutorials online. Cheers!

 

[Constantin]

Good luck. Getting all that to compile would be quite the achievement. Perhaps pair it with a external disk enclosure in JBOD mode?

I would not trust it with important data on account of hitting the trifecta of marginally-supported stuff, ie non-standard CPU with little RAM, using a USB interface to talk to the external enclosure, and a JBOD port multiplier in said enclosure.

 

[Arwen]

@BAAC - I agree with @Constantin's comments, most of us use TrueNAS for the reliability of both the OS and data storage.

Unless you have software experience with FreeBSD & ZFS, you are better served by using your Raspberry Pi with Linux and it's native RAID, volume manager and file systems. Compared to FreeBSD, Linux on Pi probably has millions times more power on hours than does FreeBSD on Pi.

(Of course, my 3 Linux computers, desktop, media server and laptop all use ZFS... but, hey, I support my own computers. And backup, backup, ... and did I mention backup?)

 

[ChrisRJ]

@BAAC , why do you want to run TrueNAS on a Raspberry Pi?

 

[Constantin]

Why did Mallory try multiple times to climb Everest? “Because it’s there!”

even better, a failure to compile / operate will only cost you a few hours of life vs. running out of oxygen at the top of the world.

 

[BAAC]

@BAAC , why do you want to run TrueNAS on a Raspberry Pi?

Thank you all for taking the time to provide me with your inputs: much appreciated! My intention was to build a DIY NAS featuring a userfriendly GUI on a systemd-free distribution or OS - hence my interest for FreeBSD as a linux alternative and TrueNAS as a solution based on such an OS - and also avoid Intel / AMD CPUs as much as possible for being the mainstream notoriously backdoored hardware they are. I am aware of the more accessible OMV alternative on RBPi but it requires systemd as far as I know. Arwen's advice is right: I am clearly out of my depth here. And I fully get the SBCs like the RBPi hardly meet TrueNAS's requirements if at all and that they would not make reliable backup solutions anyway. I just felt like giving it a shot for the sake of experimenting.

 

[Constantin]

I am unconvinced that any of the ARM microprocessors are any less prone to being penetrated in one way or the other. The various approaches that have been used successfully against amd and Intel are not limited to these platforms.

the pi was not designed as a secure processor board the way that the Sony playstations were for example. And yet the “secure” Sony motherboard was eventually cracked anyway.

 

[Patrick M. Hausen]

I am unconvinced that any of the ARM microprocessors are any less prone to being penetrated in one way or the other. The various approaches that have been used successfully against amd and Intel are not limited to these platforms.

They are limited to platforms that do out of order execution. This is the big lie of contemporary computing. We still teach programming even at university level as if the control flow was exactly as written down by the code. The mental model is still that of a PDP-11.

 

[Constantin]

Hah. Worked on one of those in high school, a VAX750 PDP-11. Good times, struggling with the Reel-to-Reel magnetic tape machine to perform backups. Fun how they used a vacuum to keep the tape tension where they wanted it. The machine was decommissioned shortly thereafter and sold for scrap to a student who put it in his basement.

Agreed re: out of order execution. It's one way to take advantage of multiple cores even if the programmer just used a single-thread programming approach, right?

To think that iTunes still cannot rip more than 1 CD at a time or update the metadata associated with a iTunes file faster than 1 file at a time. Or the vast parts of Excel that still cannot take advantage of multiple cores, like data tables (of all things....).

 

[Patrick M. Hausen]

Agreed re: out of order execution. It's one way to take advantage of multiple cores even if the programmer just used a single-thread programming approach, right?

Absolutely. It is what chip manufacturers came up with to make single threaded in-order code run faster while pretending nothing had changed. While C and Unix have had a tremendous positive impact in terms of abstraction and models and a better understanding of the OS to hardware interface, they also sealed what can be successfully brought to market as an API.

Graphics cards show that we (humanity, software developers, computer science as a profession) can deal with high parallelism, strict in-order execution, and just new programming models. It (to my knowledge) just never happened in the area of the general purpose OS.

I abso..inglutely love Unix. But I think we must abandon the mental model to make some real progress. The sooner the less painful. Multithreading while not "easy" isn't particularly hard, either. It's hard in C and POSIX.

 

[Constantin]

How timely a thread. Here is a example of Apple’s latest M1 chip being vulnerable because Apple didn’t want to implement a standard Arm chip feature. Can’t be fixed, it’s baked into the silicon and out of reach of the OS. Good luck with the Pi Project, @BAAC I’m rooting for you.

 

[darkmode]

Nice I just discovered this thread. I am also mildly interested in a ARM64. The journey would be interesting since my other ARM project builds have lower memory requirements than its x86 counterparts. I'm curious as to how the memory requirements might change for a TrueNAS Core build.

Also note that the Raspberry Pi CM4's have up to 8GB ECC memory.

 

[jgreco]

The journey would be interesting since my other ARM project builds have lower memory requirements than its x86 counterparts. 'm curious as to how the memory requirements might change for a TrueNAS Core build.

FreeNAS needs RAM for both the middleware (*cough* bloatware) and for ZFS ARC and TXG groups. You might save a little memory on the middleware, but the ARC caching requirements are going to be the same.

 

[sretalla]

I'm not sure the jury is out on ECC RAM... I see arguments saying it might be, but no definitive answer.

In any case, I think there's little serious consideration of running a NAS OS on a platform that offers almost nothing in terms of reliable connectivity to disks.

And then there's the ARM CPU... no support from that perspective either. (although with SCALE, maybe more chance than with CORE... if disk connectivity suddenly improves, raising the real interest)

 

[jgreco]

I'm not sure the jury is out on ECC RAM... I see arguments saying it might be, but no definitive answer.

ZFS has some ability to detect certain kinds of corruption within non-ECC systems, but you really do need ECC for full end-to-end protection. This affects the contents of ARC in particular, which are not independently protected, so a read-update-write quick cycle is unlikely to be affected by ECC, but a read-((sit-in-ARC-for-a-{day,week,month}))-update-write long cycle means that the unprotected ARC contents that have experienced corruption are written out to the pool, undetected, WITH A NEW AND VALID CHECKSUM.

In any case, I think there's little serious consideration of running a NAS OS on a platform that offers almost nothing in terms of reliable connectivity to disks.

That's strictly a Raspberry Pi thing, not an ARM thing in general. There is no particular reason that an ARM platform could not use an LSI HBA (other than the driver never having been ported), or have high quality SATA AHCI ports added, other than the fact that the Pi is viewed as an extremely inexpensive platform where bare minimums are preferable to control cost.

There are already lots of NAS platforms, and have been for years, that use SATA controllers on an ARM platform.

And then there's the ARM CPU... no support from that perspective either. (although with SCALE, maybe more chance than with CORE... if disk connectivity suddenly improves, raising the real interest)

How so? FreeBSD does support ARM. The main problem with FreeBSD is that the number of ARM adopters isn't that high, so there tends to be a larger number of people hacking on Linux ARM. On the other hand, Linux has the tragic GNU "free software" copyleft license, which extorts product developers into releasing their source code. This is something of a disincentive. BSD, by way of comparison, has the classic true free software "copycenter" license, which is very friendly towards product development.

I do wonder if iXsystems may continue development of Core with an eye towards backporting Scale features back to FreeBSD over the long term, because there is a lot of freedom for them to be selling their platform. Fifteen years ago, ZFS needed to run on big expensive massive honkin' servers, where an 8GB four core server was thousands of dollars all by itself. By comparison, today you can get a Raspberry Pi 4B 8GB for less than a hundred bucks which is easily the equal on compute/memory. This is working to offset the "heavyness" aspect of ZFS, so an inexpensive ZFS-based NAS is actually fairly realistic.

So, many years ago, one of the things that launched Linux from quirky UNIX-like project to modest success, and stifled BSD was the USL lawsuit in the early 90's.

The thing is, the GPL might still end up being the undoing of Linux, as companies like Synology and Ubiquiti are frequently accused of GPL violations over their use of Linux or other GPL projects. One of the nice things about FreeBSD would be that you could build a NAS or WAP on FreeBSD without the GPL licensing concerns. iXsystems would be well positioned to take advantage of that, having a ten year head start on almost everyone else.

 

[sretalla]

ZFS has some ability to detect certain kinds of corruption within non-ECC systems, but you really do need ECC for full end-to-end protection.

I was referring to the Pi having ECC or not, not the need for it to do ZFS right. (of course ECC should be used).

That's strictly a Raspberry Pi thing, not an ARM thing in general

Pi is the subject of the thread, so that's exactly what I was talking about.

How so? FreeBSD does support ARM.

You've got me on that one... although iX has previously said there's no interest in going down that road (their minds can always be changed by better hardware... but unlikely that will be a Pi).

I was indicating that I thought it would be more likely that Scale would be adapted for ARM rather than Core... but it's all in the hands of iX, so purely speculation.

 

[jgreco]

Pi is the subject of the thread, so that's exactly what I was talking about.

Fair enough, except that you went on to generalize about FreeBSD ARM support. "Platform" could plausibly be defined as a specific thing like "Raspberry Pi", though it is also commonly used to refer to the hardware platform (as in "uname -m" which is defined to be the type of the current hardware platform).

 

[Constantin]

Platform-hopping is not that unusual in the consumer space. Apples APs went through all sorts of platforms starting with the CISC 486 in the design they licensed form Avago to various flavors of RISC. I have no doubt that cost, heat, and performance were drivers in all this. Ditto re: switching from 680xx to PowerPC to Intel to Axx on the desktop side. High-volume OEMs can afford to change their minds re: processors / architectures.

I doubt this is the case with iXSystems. They don’t have the scale to justify significant processor departures, even if good compilers take care of the bulk of the work. There are so many dependencies to track down and adjust, it’s not just a brain transplant. Given Intel and AMDs adequate CPU and I/O performance, I’d suggest focusing the resources at iXSystems on fixing extant bugs and adding new features, not adding new platforms unless a really compelling reason presents itself.