Enterprise-strength FreeBSD-based TrueNAS releases v13.0 BSD vendor iXsystems has released the latest version of its FreeBSD-derived Network Attached Storage (NAS) OS, TrueNAS 13.0. The company now offers three separate OS products. Two are based on FreeBSD 13: TrueNAS CORE, which replaces FreeNAS, and the commercial TrueNAS Enterprise, available on the company's storage hardware. …
"Over the decades, it's employed many notable Unix luminaries..."You can say that again, they currently have one of the key OpenZFS developers (Ryan Moeller, "freqlabs") on the payroll. It's a great way to give back to the community and make sure that all your company's itches are being scratched at the same time. More companies should do that.
For very basic, personal needs - a home NAS with a few users - that's true. You just need the hardware that FreeBSD doesn't complain about. The minimum specs are really for entry-level business systems. They may not help you much if you find issues and run an "unsupported" configuration. Of course if one starts to add jails, VM, plugins, or one does expect very fast performance the hardware matters.
One thing I find "irritating" for a home NAS is that mounting an external USB disks to copy data to (or snapshots) there is unsupported and some "trickery" is required. The regard USB unsuitable for the purpose, although USB 3.x is far faster and better than previous versions for data transfers. Once again a business should implement a better backup process, but for home users making copies on a USB disk is still better than making no copies, and not everybody can run two NAS, or have an always on separate machine to make the copies to an attached disk.
It's useful to have a second NAS that can read the primary NAS contents and maintain copies of everything via rsync and configured so that it cannot be seen on the network. So if Ransomware invades the network you can just clean everything and restore the main NAS contents from your "invisible" backup which has maintained a complete private backup.
Sure, but not everybody can afford, has space, or simply wish a second NAS and could simply like to copy the NAS contents to separate external disks to be kept offline and offsite so if a ransomware strikes, or another issue, there are copies. I agree this is not a fully resilient solution, but for many people it would still better than no solution and everything just on the NAS.
The reason the USB is not reliable enough looks quite quaint today - for the use outlined above.
Frankly today I believe external disks, especially SSD ones, to be more reliable than optical supports, especially re-rewriteable ones. I'm experimenting with M-Discs for long term archiving of photos and some documents, but I'll know the results only after enough years - if I will still find readers <G>
Anyway the issue is that TrueNAS basically doesn't support any device which are not its ZFS arrays but for importing data. So basically you can't simply mount any external device and copy that to it easily, then remove it and store it in secure place.
Frankly it looks to me that the USB "issue" is just an excuse to try to sell more iXsystem devices because users need to rely on duplication/snapshot shipping among them. In reality at work is where I have less issue to let my Veeam system backup SMB shares. I won't relay there o a single attached USB disk for several reasons.
For home users the situation is usually different.
The reason the USB is not reliable enough looks quite quaint today - for the use outlined above.
I've been booting FreeNAS / TrueNAS from mirrored USB sticks (in an adapter like this plugged into the motherboard for some years now and had my first USB stick failure just a couple of weeks ago. I was using Sandisk drives.
Not sure why the failure - as I understand it, FreeNAS boots from the stick and then runs from RAM, all bar a periodic "scrub" of the boot device. Easy fix - bung another USB stick in there.
Oh no. Flippin' new stick is about 200k smaller than the old stick (though both say "16GB" on the packaging) so TrueNAS refuses to resilver. I'm going to have to re-install from scratch (I did buy two new sticks, not just the one), which is a bit of a hassle as the initial installation stages need a keyboard and monitor attached, and my box is headless in a cupboard.
Obviously it's still working fine from the remaining old stick, and as there is no info on the stick - and I have backups of the configuration - even if the thing dies, the data is safe, but what should have been a few minutes to identify and swap the dead stick and a few more minutes to resilver (and then repeat for the other stick, which I was going to do pre-emptively) has turned into a bit more of a job.
Other than that, love the thing. Not entirely sold on the re-brand, and the shift to Linux does strike me as the beginning of the end for the BSD version. Now that ZFS is available and stable on Linux, the main reason for sticking with BSD has mostly gone, and as noted in the article Linux brings other benefits. I can't imagine iX maintaining two completely separate products which do nearly - but not quite - the same job for very long.
M.
I've heard it said that instead of allocating the whole disk (or stick) to ZFS, create a partition a few Meg smaller than the total capacity, and then allocate that.
This gets around the problem you just highlighted where different drives don't have the exact same blocksize.
Yes network storage is a stand alone function, however that function places no exclusive demands on the underlying hardware to be a single function device. If users are happy with the data throughput provided by a VM based NAS as opposed to a dedicated solution* then all the other advantages of VMs are very nice to have.
For home users building one larger VM host using the extra cash that otherwise would be spent on NAS hardware will likely provide quite an uplift to the CPU core count & RAM and/or provide a high spec dedicated disk controller benefiting all VMs.
I replaced my physical NAS last year with the long term aim of reducing it to backup status when I get around to replacing the VM host I've been using for eight years (RAM is now at Mobo limit and CPU usage is generally cruising in the teen %s)
* lack of dedicated hardware will be offset to some extent by the 'network' links being internal to the VM host.
TrueNAS has historically had problems with certain hardware configurations running it in a VM means I simply don't have to worry about it. Say TrueNAS is updated and then refuses to boot I then have to reinstall TrueNAS and set up all my virtual machines again, this way I simply revert the drive image as I take a snapshot before I do an upgrade.
Mainly I don't want to run two servers and TrueNAS for running VM's is not a nice experience for example you can't import drive images or create a network solely for you're VM's to communicate on or in need of bridging them to allow them LAN access. Installing a new VM doesn't exactly smooth sailing either and there's a lack of options available to you when setting them up.
If you want to bond your network interfaces well... good luck you can only do it through the web interface and if it fails you have to revert everything and hope that this time it works as you expected a nightmare.
So I use Debian as the host OS as networking is easy so I have bonded nics and bridging set up enabling me to put VM's into vlans as well. VM's sit on a pair of nvme drives formatted with ZFS. I'm running a Ryzen 3700X with 64GB ECC RAM on a Asrock Rack X470D4U motherboard for reference. Nvme drives are in the PCI-E x16 slot bifurcated (x4x4x4x4)
I should add drive performance is not impacted from being in a VM the drives are on a SAS controller passed through, so the VM is in direct control of the SAS controller same as it would be if it were installed on the bare metal.
Been considering TrueNAS for a new NAS for a while now, tried out the older versions in a VM just for a trial run, will have to give this new version a look.
I've currently got an old NAS running OMV, on a now rather ancient HP micro server, only capacity for 4 disks, the CPU is rather underpowered, and I'm constantly at around 90% full.
I've looked at purpose built NAS systems, but they always seem too limited, or too costly for what you get etc.
So was thinking of just building essentially a regular PC, i.e. case with lots of drive bays, ATX etc, and just stick TrueNAS on it. Although I'll probably move to a 6 disk array minimum, rather than my current 4 disks (limited by the current HP hardware).
Once built, I'll possibly look at repurposing the old system as a pure secondary backup system, that only connects to the primary NAS as needed.
rather ancient HP micro server, only capacity for 4 disks
I'm running TrueNAS on a rather ancient HP Microserver too - but I got round the disk limit by buying an Icybox external RAID enclosure and connecting it to the server via an E-SATA card.
Works like a charm (apart from the fact that the HP's power switch is a bit flaky and it sometimes spontaneously turns itself off..)
I did think about doing something similar, as mine also has an eSATA on the back, but I'm hitting CPU limitations.
The CPU is an old AMD Turion @ 2.2GHz, which is basically an ultra low power mobile CPU.
As an example I can't really use server side compression (on by default) for my automatic backups (via UrBackup), as it was taking triple the time to run, due to the server CPU running 100%. The system also struggles with other operations as well.
I'm also wanting to run VMs and other services, that I currently run on my main PC, but that means I have to leave the main PC running at times, or shut down the VMs. No way the Turion could cope with that work load. So I want something with a bit more oomph.
I'm considering building an AM4 based system, as I'm planning on doing a CPU upgrade in my current PC anyway, which would mean I'd have a spare Ryzen 3800X.
Myself, I went with nas4free (think they rebranded as XigmaNAS some time ago) for reasons that I can't even recall (sometime afrer the fork from FreeNAS happened) and the upgrade worked flawlessly. Slightly different approache between iXsystems and Xigma as they each went in slightly different direction.
Touch wood, has worked flawlessly without any issues on HP MicroServer (old N36L IIRC) booting off of internal USB stick. I did add intel dual port gigabit card to the MicroServer which improved network throughput and reliability.
So was thinking of just building essentially a regular PC, i.e. case with lots of drive bays, ATX etc,
One thing to be aware of - if you have never previously used ZFS - is that it has a slightly idiosyncratic way to handle physical storage, and if your storage needs are growing you need to be aware of this.
For example, on a QNAP device at work (doesn't use ZFS), once the 4x1TB discs (in RAID 6 giving 2TB online) had grown too full, we had two options - either add another (say) 2x1TB discs and add them to the array, giving 4TB online, or swap the 1TB discs - one at a time - for 2TB discs, ending up with 4x2TB and (again) 4TB online.
ZFS gives you the latter option, but not the former, which bit me at home because when I built my system, for space reasons I used 2½" drives in a 4-in-a-5¼" slot caddy. You can't get NAS-type 2½" discs bigger than 1TB (WD Red, for e.g.)* so I was reduced to expanding using the best "laptop" drives I could find.
This is only really a problem for users on a budget - adding two new drives to an existing array for expansion is far cheaper than swapping out all four for bigger ones, or adding a new array of four (which ZFS can then "pool" with the existing array). It's hard enough spending £60 or £70 on a single disc to replace a failed one, let alone buying four at the same time!
M.
*in fact, 2½" spinning rust is getting thin on the ground in general :-/
Thanks for the tips.
Always pros and cons to consider.
I read this article on Arstechnica a while back, as an intro into ZFS.
I've also messed around with ZFS in various incantations via VMs (including earlier versions of TrueNAS/FreeNAS), but just using standard virtual drives, not hardware pass through. But this was just to play around with vdevs, zpools etc.
Expanding existing pools does seem to have restrictions.
It's not recommended as far as I know to mix vdev configurations, such as in your example (i.e 4 disks initially, then add 2 later on), and I think you're limited to having to use the same raid mode (z1, z2 etc) each time for additional vdevs within the same pool, which also of course also restricts the minimum number of drives you can add at a time.
So there are definitely restrictions to consider, much less flexible than other RAID options as you mention.
As a test I created a zpool with 4 x 1TiB drives, as z2, giving me ~1.83TiB available after formatting etc.
I then added a new vdev to the same zpool, this time using 4 x 2TiB (*) drives, again z2, giving me 5.63 TiB available in total after formatting due to both vdevs being combined within the pool.
Personally, as my data is fairly segregated by function, I'd probably just create a new pool with the four (or however many) new drives, and migrate specific data to the new pool, rather than continually growing a single pool. Again pros and cons of course.
Cheers
* Emulating getting larger size drives at some later date.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
