FreeNAS with Raspberry Pi. Is It Possible?

[jgreco]

Jeff is compiling testing results of PCIe cards that could be pluged into RP4 IO board. See Raspberry Pi PCI Express device compatibility database. Most relevant to this thread is IO Crest 4 Port SATA III PCIe x1 with Marvell 9215 that fully works with driver and currently tested IBM ServeRAID BR10i / LSI SAS3082E-R SAS RAID controller.

The ServeRAID BR10i is a first generation SAS 3Gbps controller that cannot handle disks greater than 2.2TB. The Marvell AHCI controllers are known to be generally flaky, with variations between the specific models that are too numerous to bother keeping track of.

If you can manage to find something that supports an LSI 2008 card, and can then solve the ethernet controller problem, maybe there's a starting point in there somewhere, otherwise you are basically just asking for fate to come and smite you.

 

[ilmarmors]

To be clear - I'm not trying to port TrueNAS to Raspberry Pi, I just provided additional information relevant to the initial question and replies. Computer world is quickly changing - what wasn't possible yesterday, might be possible tomorrow. It doesn't make sense to try port FreeBSD based TrueNAS to ARM platform anyway. If somebody really want TrueNAS, then porting Linux based TrueNAS SCALE might be easier path in the future.

Meanwhile, if somebody really want to experiment with Raspberry Pi, then I found following option (haven't tested anything, use at your own risk):
* Dual/Quad SATA HAT for Raspberry Pi 4 / Rock Pi 4. https://wiki.radxa.com/Dual_Quad_SATA_HAT
* Penta SATA HAT for Rock Pi 4. https://wiki.radxa.com/Penta_SATA_HAT

You can try to configure NAS manually or install OpenMediaVault. You might need to jump some hoops (manual mdraid setup) because those SATA hats are USB bridges, and as I understood from video review latest OMV version doesn't allow creating arrays from USB disks via GUI.

SATA HATs support up to four drives on Raspberry Pi 4 or Rock Pi 4 - http://linuxgizmos.com/sata-hats-support-up-to-four-drives-on-raspberry-pi-4-or-rock-pi-4/

Full Setup Quad SATA Hat for Raspberry Pi 4 NAS Review - https://www.youtube.com/watch?v=Eix0PCB0byQ

 

[Constantin]

Given the innate capabilities of the current Raspberry Pi platform, I suggest using it as intended - For example, as a cheap media server for data you don't care about losing or getting corrupted. For that use case, it is absolutely great. I run a time machine vault on a RPi 4 with the three kid accounts on it so I can keep their laptops 100% off my private network. I back them up periodically but I would not cry a tear if I lost that data.

TrueNAS / FreeNAS / SCALE / whatever is targeting a very different market. First and foremost, to me, the hardware requirements and the complexities involved with installing TrueNAS are justified by ZFS and its many data-integrity benefits. One layer down are all sorts of protocols, permissions structures, etc. that allow for a incredibly flexible installation. All sorts of use cases can be covered very reliably, especially if you stick to recommended hardware platforms / add-ons.

Once you venture out of the protective forest of Intel and AMD-based options and decide to start planting new saplings in ARM-land, etc. you are literally on your own. Why further increase your chances of pool destruction by stacking the odds against yourself? Crummy HBAs, insufficient or non-ECC RAM, all those factors basically reduce the achievement of running TrueNAS on a Rpi to a mere curiosity: no doubt, a technical achievement, perhaps a stepping stone to something greater in the future, but certainly not a good solution for anything other than scratching an intellectual itch.

OMV makes a lot of sense on limited hardware platforms because its scope is far more limited than what TrueNAS tries to be. Ditto for bcache, Netatalk, and so on. RPi can be tailored to do all sorts of limited tasks really well and do so at a price point that TrueNAS may not be able to touch. However, once you get into server-land and you expect the flexibility, reliability, etc. of a production server, RPi has little to no role with its current capabilities, no matter how much lipstick you apply.

I'd love to see ARM come to the SOHO market, especially for storage-oriented solutions like the SuperMicro X10SDV-2C-7TP4F, which offer oodles of high-quality storage interfaces, a fast NIC, a couple of PCIe lanes for future expansion, etc. A ARM solution could offer even better performance at fewer Watts and with less heat. However, there is the pesky chicken/egg problem with hardware that even AMD-based solutions have to contend with. (Note the relative dearth of AMD-based motherboards at Supermicro and elsewhere even though AMD is nominally compatible with Intel) Custom solutions for cloud providers are a bit out of reach for the most of us.

Anyone have a couple of million of USD burning a hole in their pocket and a high appetite for risk? Then put together a kick-bum team of hardware developers, bring out something like a SuperMicro X10SDV-2C-7TP4F that can use ECC RAM, offers 2+ PCIe lanes, etc and then pay the big $$$ to the likes of iXSystems to port TrueNAS to that platform. It's not going to be easy and you haven't even started to address the fundamental challenges of consumer acceptance, awareness, etc. Maybe the folk at Kickstarter will be willing to burn their excess cash this way?

I prefer giving excess money to the FreeNAS project, at least there I have a much higher possibility of benefitting those whose lofty shoulders I get to stand on.

 

[lei3E]

OMV makes a lot of sense on limited hardware platforms because its scope is far more limited than what TrueNAS tries to be.

There is a ZFS plugin for OVM (openmediavault-zfs)

GitHub - OpenMediaVault-Plugin-Developers/openmediavault-zfs: OpenMediaVault plugin for zfs

OpenMediaVault plugin for zfs. Contribute to OpenMediaVault-Plugin-Developers/openmediavault-zfs development by creating an account on GitHub.

github.com

 

[Constantin]

Stitching together a configuration that can run ZFS doesn't mean it will actually perform as you seem to expect. ZFS has been ported to all sorts of platforms. What it's supposed to achieve on them is a different question, especially when the hardware support for critical aspects of ZFS is missing. (solid HBA like those from LSI, sufficient ECC RAM, etc.)

It's like putting a 2020 Bosch ECU on a 1908 Ford model T car. So you installed a battery, powered up the ECU... the spark ignition timing could potentially never be better... but wait, the knock sensor is missing... as is the MAF... as is the modern ignition coil system, fuel injection, etc. By the time you retrofit all the missing add-ons that allow a Bosch ECU to do it's magic, you're still stuck with a Model T engine (albeit one with perfect ignition timing). It's a great curiosity to take to the local coffee and cars meetup and impress your gearhead friends... but other than that... it's still a Model T... don't expect miracles!

If "simple" media vaults are what you're after and a RPi is a design requirement by all means go for OMV and add ZFS support. At best, the machine will transfer at 50MB/s (large files & SSD), it will not protect your data from some forms of corruption, and 8GB of RAM (at best) will likely present its own set of challenges for anything more than a few users. AFAIK, everything multi-disk in rPi land works over USB via port multipliers, with their well-documented driver / HW errata issues impacting pool data.

For the time being, a better performing, lower cost option is to buy a used server-grade Intel motherboard and potentially get all the benefits of TrueNAS/ZFS, not just a subset and the illusion of data integrity. Low power configurations are also readily available, so that's not a gating factor either. But even server grade hardware and a sensible config for your use case is no match for all the probabilities out there so you better have a good backup plan no matter what.

 

[Teeps]

I eventually built a 6 x 5TB 2.5" drive NAS using an ODROID-H2 and modified their Type 1 Case so it would hold everything neatly. After I discovered that the RealTek network driver must be upgraded to the one in FreeBSD (or you will crash under any moderate network activity), the system is now rock-solid. **Very** happy with the reliability of the ODROID-H2, and the size and price didn't hurt either!

I found this thread because I'm brainstorming the absolute minimum hardware requirements for a 1 or 2 disk replication target. Basically the little baby synology form-factor.

I'm admittedly a noob still after years of playing with this stuff, but I'm thinking that if it's not running ZFS then I would need to reply on an extensive rsync all the time versus the lighter-weight ZFS replication features.

This ODROID setup looks really solid at first glance (thanks for the link) - is there anything I'm missing about using this to roll my own ZFS replication target that would require minimum power and thermal considerations?

 

[ChrisRJ]

@Teeps , whether the approach you sketched out makes sense, will depend on your requirements. Replication is usually in the game because people want additional protection of their data. If that is also the driver for you, then the options should be weighed against that goal.

 

[Teeps]

@Teeps , whether the approach you sketched out makes sense, will depend on your requirements. Replication is usually in the game because people want additional protection of their data. If that is also the driver for you, then the options should be weighed against that goal.

Yes, that's correct, the goal is an additional redundant copy of my data. Initially this would be in my apartment next to the main NAS. I don't need a full-fledged freenas server - I already have one - I just want a regularly-synchronized, second local copy of my data with the smallest overhead possible.

 

[Constantin]

I'd also consider hosting a backup pool in a separate enclosure, using a server-grade eSATA connection (i.e. not a JMicron port multiplier!).

Not sure what eSATA solutions meet the minimum performance requirements that the likes of @jgreco and @Chris Moore know all about, but it might enable you to create a external pool with even less overhead than the ODroid solution. More importantly, it saves you the headache of porting ZFS to a unsupported platform and you may also benefit from more RAM (preferably ECC), higher speeds, using your own CPU, and so on.

 

[Chris Moore]

eSATA

I used eSATA when I expanded my first NAS (or was it my second) from 4 drives to 8... I was using an old Dell T3500 workstation for my NAS and it was out of drive bays... I used it for a couple years. I found that eSATA became unusable, if I recall correctly, when we went to version 9.10. Something in the drivers changed and the eSATA port multiplier hardware that had been working just wouldn't do the thing any more. That is when I invested in SAS controllers and I have not looked back.

 

[jgreco]

The eSATA port multiplier solutions that work reliably on FreeNAS are few and far in between. You need a chipset that correctly supports it and also works with the FreeBSD driver, and then also a port multiplier that wasn't engineered by AsiaCo BackAlley Silicon Ltd. It's too bad, too, because many of the semi-affordable "hobbyist" class arrays out there could be options for FreeNAS if they worked well.

 

[Constantin]

There is that and sometimes it also makes sense to have two enclosures. One for the cpu, boot drives, slog, etc. and another chassis to hold the disk drives. Each can be optimized for its task.

My server chassis is gargantuan and maybe 1/2 full. The Q26 is much more volumetrically efficient but won’t accommodate a flex-atx sized motherboard. Even a duplicator chassis for 5.25” drives fitted with two 4-wide or 5-wide 3.5” hot swap bays could be interesting. But the connection back to the NAS is the conundrum / area of concern.

 

[Teeps]

A tiny eSATA "side car" does sound like an effective solution (if the appropriate, compatible hardware still exists), but I am still curious about the smallest/lightest possible (2x3.5" disk) independent node that could be a replication target over the network. I realize I didn't put that in my first requirements post. Y'all are so literal, which I appreciate. Forces me to think more clearly ;) Thanks for the discussion.

 

[kiriak]

is a SFF PC small enough?

if yes
there are a few of them that can easily take 2 3.5 drives,
like HP Z230, it can be found quite cheap as used, can have ECC RAM depending on the CPU, it is quiet and of low consumption, and you would have he added benefit of running TrueNAS on the replication target also.

 

[Teeps]

I'm already using the U-NAS 8-bay chassis. I suppose I should have just looked at them first

U-NAS HSC-201 2-Bay Home Server Chassis with Power Supply

U-NAS HSC-201 is a 2-Bay Hot-Swappable Home Server chassis with 150W 1U flex power supply.Choosing a color: Red or Space Grey. Please specify the color in "Customer note" when purchasing it. You pay $129.99 per unit when you use the coupon code 10off201!

www.u-nas.com

TrueNAS micro coming up...

This is also a cool chassis design, albeit only 2.5" drives on this one. https://www.supermicro.com/en/Aplus/system/Embedded/AS-E301-9D-8CN4.cfm

Anyways.. thanks for humoring the divergence from Raspberry Pi

 

[kiriak]

U-NAS 2-Bay box looks good,
but for almost the same size,
you can have the 4-bay HP Microserver Gen 10 Plus.

 

[Constantin]

Just be careful about heat management. Not familiar with the uNAS or micro server series but adequate cooling can be a real issue in these small form factors.

Too often, design and cost considerations minimize cooling fans / passages / openings to the point where scrubs will roast the drives in their own juices.

 

[Teeps]

Just be careful about heat management. Not familiar with the uNAS or micro server series but adequate cooling can be a real issue in these small form factors.

Too often, design and cost considerations minimize cooling fans / passages / openings to the point where scrubs will roast the drives in their own juices.

Indeed, it seems most NAS case manufacturers just want to make cheap little drive ovens

This led me to do a bit more digging and find this great thermal-forward design (is that a term? :)

It's the little brother of the 3D printed NAS chassis already mentioned here previously. It seems this NAS side of the market has some catching up to do with the gaming chassis side of the SFF community. I'd love to see something with the ventilation of this chassis and the build quality of the Ncase M1.

Here's another clever mod of this same designer's 3D files

 

[BAAC]

Hello everyone,

I hope you will not mind my asking this noob question. I read and understand from this Forum that TrueNAS Core / FreeNAS do not support RBPi because they are essentially not compatible with the ARM architecture per se. Is that correct? I just would like to make sure that the fact an ARM version of FreeBSD is being developed ...

Index of /ftp/snapshots/arm64/aarch64/ISO-IMAGES/

... does not fundamentally change that incompatibility. Assuming that FreeBSD is installed on a Pi, would you please confirm that installing TrueNAS Core / FreeNAS on that system is still not an option?

Thank you very much, in advance, for your attention and reply.

 

[jgreco]

... does not fundamentally change that incompatibility. Assuming that FreeBSD is installed on a Pi, would you please confirm that installing TrueNAS Core / FreeNAS on that system is still not an option?

FreeBSD 13 has a reasonably usable ARM64 port, the first (in my opinion) that might be suitable for general use. I've had some trouble with it on a bare metal ARM platform, but it can be made to work swimmingly well as a VM on ESXi-on-ARM, with some caveats.

Unfortunately, FreeNAS/TrueNAS requires a crapton of memory, and also storage. The largest Pi out there right now is 8GB of memory, which would *barely* meet minimum FreeNAS requirements, and there is no way to attach hard drives to it. (No, USB isn't a valid option.)