TrueNAS Core will soon replace FreeNAS—and we test the beta - Ars Technica

sarungkeme.blogspot.com

Enlarge

Earlier this week, network-storage vendor iXsystems announced the release of TrueNAS 12.0-BETA1, which will replace FreeNAS later in 2020. The major offering of the new TrueNAS Core—like FreeNAS before it—is a simplified, graphically managed way to expose the features and benefits of the ZFS filesystem to end users. In the most basic environments, this might amount to little more than a Web front-end to ZFS itself, along with the Samba open-source implementation of Microsoft's SMB network file-sharing protocol.

Although this might be sufficient for the majority of users, it only scratches the surface of what TrueNAS Core is capable of. For instance, more advanced storage users may choose to share files via NFS or iSCSI in addition to or in place of SMB. Additional services can be installed via plug-ins utilizing FreeBSD's jail (containerization) facility, and the system can even run guest operating systems by way of FreeBSD's BHyve virtualization system—all managed via Web interface alone.

TrueNAS Core will be what FreeNAS is now—the free, community version of iXsystems' NAS (Network Attached Storage) distribution. End users—and system administrators who aren't looking for paid support—can download FreeNAS or TrueNAS Core ISOs directly from iX, burn them to a bootable optical disc or thumbdrive, and install them on generic x86 hardware like any other operating system.

We've been kicking the tires on early versions of TrueNAS Core since its announcement in March, and we see no evidence of any FreeNAS functionality slipping away behind "premium only" paywalls. The dividing lines between TrueNAS Core and TrueNAS Enterprise are no different than those between earlier versions of FreeNAS and TrueNAS itself.

Due to the sheer breadth of TrueNAS Core's offerings, we can't walk you through everything it's capable of in a single article. But we will hit the major highlights along the way—we'll install the distribution and set up a storage pool on eight physical disks, join TrueNAS Core to a Windows Active Directory domain, set up some file shares, and play with ZFS snapshot and replication facilities.

The user interface has come a very long way in the six years since our 2014 review of FreeNAS. The modern TrueNAS interface has been entirely rebuilt from scratch, along much more coherent lines. If you've tried and given up on old versions of FreeNAS, it's worth taking a second look at how far it has come.

Installation

• If these options seem overwhelming, installing and managing your own storage distribution may not be for you.

  Jim Salter

• Once you've decided to install, the next question is where you want the root and boot filesystem to go.

  Jim Salter

• This wasn't our first TrueNAS Core test run, so we're given the option to upgrade or install fresh. We chose the fresh install.

  Jim Salter

• FORMAT! EVERYTHING!

  Jim Salter

• Last chance to abort! It's a little odd that we're not told about the preference for "flash media" until the "oh no" screen, but okay.

  Jim Salter

• You'll need to set a root password before rebooting. There is no strength check here; if you want to use "poop" as your password, the installer won't complain.

  Jim Salter

• TrueNAS supports either UEFI or BIOS boot. Both modes worked on our Linux KVM virtual machine, and directly on the metal of the Storage Hot Rod.

  Jim Salter

• That's the whole install—pop the install medium out of the system and reboot.

  Jim Salter

The first-boot phase of a TrueNAS Core installation is the simplest OS installation we've ever seen. TrueNAS Core doesn't ask you to do the complicated stuff during the original installation; all it wants to do is slap the operating system onto a boot disk and have done with it. You pick a disk (or USB thumb drive) to act as the boot-and-root medium, set a password, and pick UEFI- or BIOS-style boot—that's it.

All of the interesting stuff—like configuring the rest of your disks as actual storage devices or creating and exposing network shares for them—happens later.

First boot

• This ASCII splash screen hangs around for five seconds; if it hasn't received input by then it falls through to a standard boot.

  Jim Salter

• The only thing most users will need to do at the text console is configure the network interface (which defaults to DHCP).

  Jim Salter

• You might think you'd WANT to "remove the current settings of this interface"—but if you do, it just returns you to the menu. So, uh, don't?

  Jim Salter

• Don't forget to configure your default route (and DNS) as well as the IP address, if you leave DHCP mode.

  Jim Salter

There isn't much to do on your first reboot after installing TrueNAS Core—little or no configuration is ever done at the physical machine. By default, the system will assign configurations to any live network interfaces by DHCP. If you don't want to issue a specific DHCP reservation for the TrueNAS system at your router, you'll need to manually set an IP address in the text-based menu here.

Once you've got your TrueNAS Core system living at its "forever IP address," it's time to walk away, sit down in front of the computer or mobile device of your choice, and browse to the TrueNAS Web interface to get the real configuration work done.

Web login and initial configuration

• If you're accessing TrueNAS by raw IP address, the way we are here, expect the broken lock icon in the address bar—you can't give an SSL certificate to an IP address.

  Jim Salter

• On your first login, you'll get a small, one-time splash dialog offering you links to documentation, forums, and optional paid support.

  Jim Salter

• When you expand the Storage menu on the left sidebar, the top entry is Pools. Here's where you'll assign your disks.

  Jim Salter

Once you sit down at another computer and pull up TrueNAS Core by IP address, you'll get a nocturnal-user-friendly Dark Web interface laying out TrueNAS's functions. There isn't a wizard to walk you through creating your first storage pool—you'll need to get through that solo—but it's not too hard. After expanding the Storage menu on the left sidebar, select Pools and click the "Add" button. This is where the fun begins.

• The most important, and easily overlooked part of this dialog—particularly if you have a ton of disks—is the free-entry text box "name". Don't forget to name your pool!

  Jim Salter

• See that big, inviting add vdev button? It likely doesn't do what you think it does—it's there for adding support vdevs, not storage vdevs.

  Jim Salter

• If you have a lot of disks, like we did, you'll likely need to scroll down to find the next crucial part of the create pool dialog—the "Data Vdevs" section. Click the blue right-arrow here to add the disks you checked above.

  Jim Salter

• You don't actually need to check any of these boxes, unless you want to remove disks you've already inserted. Note that raidz2 is selected by default—all we need to do here is click "Create."

  Jim Salter

• If you drop down the "vdev type" list, you get "stripe" and "mirror" in addition to RAIDz1, RAIDz2, and RAIDz3.

  Jim Salter

• TrueNAS really does mean "mirror" as in "one big mirror vdev" here, not a pool of mirrors. Note the estimated raw capacity: it's the same as a single disk.

  Jim Salter

• "Stripe" really means "make every one of these disks a singleton vdev," as you can see from the total capacity.

  Jim Salter

ZFS pool structure isn't that complex: a pool consists of vdevs, and a vdev consists of disks. Each vdev may be a RAIDz striped array, a mirror array, or a single disk. Unfortunately, most users aren't accustomed to thinking in multiple levels of organization and so conflate "pool" with "vdev" into a single, messy structure.

TrueNAS attempts to make life easier for those users without obfuscating the real structure of the system too badly. For the most part it succeeds, but it's still a bit of an adventure figuring out how the interface maps to the underlying reality on your first trip through. If you have lots of physical drives, the problems get a little worse—the "pool name" text box is visually understated, and since it sits above the list of drives, you might miss out on it entirely and wonder why TrueNAS refuses to validate your entry once you click "Create" at the bottom of the screen.

With our eight physical drives selected, TrueNAS defaulted to creating a single RAIDz2 vdev out of them—which is what most users will likely prefer. You can change this by clicking the vdev type and selecting RAIDz1, 2, or 3, or going with "Mirror" or "Stripe."

Selecting "Mirror" turns all eight disks into a single eight-wide mirror vdev—which probably isn't what users who click that selection with that many drives actually want, but we appreciate the literalness of it. The existence of "Stripe" soured us again a bit, as it's the one entry on the list that isn't a vdev type at all. Instead, it takes all selected disks and makes individual single-disk vdevs from them.

• After changing our selection back to RAIDz2, we're given a last chance to bail before nuking their partition tables and adding them to the pool as a new vdev.

  Jim Salter

• We haz pool! Yay!

  Jim Salter

• The gear icon off to the right exposes the option to add vdevs, scrub the pool, check its status, or export it.

  Jim Salter

Having explored all the vdev type options, we changed back to the default RAIDz2 and clicked Create. After one final confirmation, we had our storage pool—and options to export it, add vdevs to it, scrub it, check its status, or expand it.

To create my usual preference for pool structure—a pool of two-wide mirror vdevs—we would have needed to create it one vdev at a time, selecting only two disks and creating a mirror vdev, then using the gear icon here to return and add more vdevs until we were done. Similarly, we could have created two separate four-wide RAIDz1 or RAIDz2 vdevs this way.

Joining an Active Directory domain

• We're going to join a Windows Active Directory Domain here, which largely avoids the need to set up individual users on the NAS itself.

  Jim Salter

• Joining the domain is as simple as it can be—enter the AD domain name, a domain name and password with privileges to add a machine to AD, and check "Enable."

  Jim Salter

• Active Directory domain join completed in well under one second—so rapidly, we felt the need to check Active Directory Users and Computers to make sure it worked.

  Jim Salter

Joining TrueNAS to a domain allows you to take advantage of domain single sign-on (SSO). Instead of having to laboriously set up users on the NAS to match all the users on your network, TrueNAS can just consume the existing directory structure, which also avoids the need to update passwords on the NAS separately from the passwords on the users' PCs.

This, of course, requires that you have a Windows domain in the first place. For that, you'll need a copy of Windows Server running as domain controller, and you will need an actual domain set up and working prior to all this. You'll also need to make certain that the TrueNAS Core machine's DNS source is an Active Directory domain controller.

Assuming you have all those things, the domain join process in TrueNAS Core works lightning fast; it's enormously faster than joining an actual Windows PC to the domain. Well under one second after clicking "Save," we were joined to the domain—so rapidly that we went and checked Active Directory Users and Computers on the domain controller. Yep, there we were, all right!

Adding a new Samba share

• Adding an SMB share looks straightforward enough... but it's asking for a path, and we haven't created any datasets to actually share yet.

  Jim Salter

• I was very frustrated trying to figure out where to go to create a dataset. There's my pool. There's no "dataset" option under the storage menu, on the left. It's not in the gear icon, to the right. Where IS it?!

  Jim Salter

• Turns out that there's a hamburger menu off to the right, hidden until I horizontally scrolled. This won't be the case for most people browsing in full-screen mode, but it frustrated me for a good 15+ minutes.

  Jim Salter

• Once I found the hamburger menu, creating a dataset to map an SMB share to was easy enough.

  Jim Salter

• Advanced properties for the newly created dataset—such as ZFS recordsize—live here.

  Jim Salter

• I want to do some performance testing later, so I created several datasets with different recordsizes—here, TrueNAS is (quite correctly) warning me that if I create a 4K recordsize dataset, I'm not going to like how it performs.

  Jim Salter

It's easy enough to see that adding an SMB share is done from the Sharing menu on the left—but finding the dialog in which you create a dataset to share is a little more obtuse. It's under Storage—which is no surprise—but rather than having its own submenu there, it's inside a hamburger menu on the far-right side of your pool's name in the Pools submenu.

This created a particular problem for us, because our browser wasn't full-screen—we kept it at a relatively modest window size to make the screenshots easier to work with on the site. This unfortunately hid the hamburger menu for the pool on the wrong side of a subtly styled horizontal scrollbar, which led us to 10 or 15 minutes of frustrated tail-chasing before finally figuring out where the dataset creation menu was.

Once you're in there, creating datasets is simple enough. Just like ZFS itself, TrueNAS will default your datasets to a recordsize of 128KiB unless you ask it otherwise. We created a couple of datasets for performance testing later, with recordsizes of 1MiB and 4KiB, and TrueNAS (quite correctly) warned us that if we set recordsize so low on a pool with an eight-disk vdev, we wouldn't like how it performed. Thanks, TrueNAS!

• Now that we've got datasets created, it's easy enough to see them laid out in the Pools dialog.

  Jim Salter

• Now that we have datasets to expose, we return to the Windows Shares (SMB) dialog to create shares that can be mapped from the network.

  Jim Salter

• There are lots of options exposed for our new SMB share—of particular note, ACLs mean that file and folder permissions will map properly to Windows clients, and Enable Shadow Copies means that Windows clients will have the "Previous Versions" tab enabled in File Explorer when browsing TrueNAS.

  Jim Salter

• After we click "Submit", a dialog pops up for editing ACLs (Access Control Lists, aka file and folder permissions attributes).

  Jim Salter

• Just clicking "Save" isn't good enough—what TrueNAS gave us for defaults will need some modification before it's acceptable without an error being thrown.

  Jim Salter

• Without actually configuring the ACLs, we don't have write permissions on the share as seen from client PCs.

  Jim Salter

Creating a new share mapped to our dataset exposes some of TrueNAS's best "easy mode" functionality—Windows ACLs (Access Control Lists) work right out of the box, meaning that adjusting file and folder permissions from File Explorer on Windows Clients will just work. Trying to get this right on a Linux system is just plain painful, so this is an important feature and a positive differentiator for TrueNAS and other systems which offer it.

We can also see that Shadow Copies work by default—which means those same Windows Clients will have a Previous Versions tab enabled in File Explorer while browsing shares on the NAS, enabling them to self-serve and find copies of important files that they've lost or corrupted. Unlike the Recycle Bin, this applies for file changes, not just deleted files—so if you accidentally Ctrl-A highlighted an entire document, deleted the whole thing, and then accidentally saved over the original, you can go to Previous Versions to retrieve an intact copy.

Things got a little weirder once we submitted the share, unfortunately—rather than using a set of default ACLs that just work for most people, TrueNAS insisted on us actually creating ACLs. Without doing so, users have no write access to shares—and unfortunately, the ACL dialogs turned out to be pretty buggy.

• Our first try was just changing the existing ACL from the local "wheel" group to the domain "Domain Users" group.

  Jim Salter

• On closer inspection, the ACL permissions themselves also only allowed read privileges. So we'll need to update those as well.

  Jim Salter

• We only wanted a single set of permissions that covered all users, so we tried removing all permissions for the "everyone" ACL. Nope. Gotta delete that ACL instead.

  Jim Salter

• Beware the lurking "Apply" checkbox, whose function is to ignore your changes if left unclicked. I do not love this convention.

  Jim Salter

• Inherit is off by default... but if you don't turn inherit on, you can't proceed. OK...

  Jim Salter

• Here's another thing we got wrong initially—the important part isn't really who the Unix owning group is on the left, it's who the group is INSIDE the ACL, on the right.

  Jim Salter

• It took us a minute or three to get here, but we've finally got the right permissions on our share, and Domain Users can create and write files at will.

  Jim Salter

Getting the ACLs right is a bit of a chore in TrueNAS. The defaults aren't going to be usable for just about anyone, which means you'll need to dive in and create them manually. This wouldn't be so bad, but it's not entirely clear which parts of the dialog apply to the global Unix permissions and which side apply to the inside of the actual ACLs—the two are entirely separate in reality but are jumbled together in a single dialog here.

We also got frustrated with a gratuitous "click Apply or we'll eat your changes quietly" checkbox that must be ticked to apply changes to group ownership. Finally, we experienced a bug that caused TrueNAS to just quietly eat all of our changes if we ticked the "apply recursively" checkbox. We had to give up on that and apply ACLs to each share individually.

Once we'd gotten through all of that, everything worked the way it should—we had shares, they mapped properly to Domain users, and permissions could be viewed and applied correctly from Windows File Explorer.

The recursive ACL bug was fixed shortly after we encountered and reported it, so readers shouldn't encounter it themselves. The major reason we include it here is to remind readers that TrueNAS Core is still in beta—although it's usable, it is not yet production quality.

Snapshots and replication

• If you aren't taking snapshots on a recurring basis, you're leaving an awful lot of ZFS' true value on the table.

  Jim Salter

• We can see all periodic snapshot tasks here, along with the policy on when those snapshots will be deleted.

  Jim Salter

• We're actually not entirely clear what Cloud Sync is—but whatever it is (rsync, maybe?) it's definitely not ZFS Replication.

  Jim Salter

You definitely shouldn't consider your setup process complete on any ZFS system until you've got a regularly recurring snapshot process configured. In TrueNAS, that's under Tasks-->Periodic Snapshot Tasks, and it's relatively straightforward. You can create as many snapshot jobs as you like here, along with options such as whether they're recursive (apply to datasets beneath the one the task runs on), what their naming schema looks like, and how long they should remain on the system.

That last part—the lifetime of the snapshot—isn't a ZFS feature, it's a TrueNAS feature. ZFS snapshots don't disappear unless and until manually destroyed, so you need an automated mechanism to get rid of stale snapshots for you or your drive will fill up with them eventually.

Under Tasks, we also noticed "Cloud Sync"—it's not immediately apparent just what that is from looking at the interface, but searching iXsystems' blog reveals that it's a file-based synchronization service using rclone to back files up to Amazon S3 buckets. What we were interested in was ZFS replication—which is, appropriately enough, under "Replication tasks."

Creating a replication task

• In order to replicate to a remote system, you need to publish SSH keys, one way or another—the "Semi-automatic" method, which we did not test, only works between TrueNAS boxes.

  you need to publish SSH keys, one way or another—the "Semi-automatic" method, which we did not test, only works between TrueNAS boxes.

• If you try to drop down the folder tree on the target side of the replication dialog without having a published SSH key, you get an untrapped error.

  Jim Salter

• Back out of replication, and go to System-->SSH Keypairs to generate a key for use in replicating to a remote system.

  Jim Salter

• Now that we've got a properly published keypair—I saved the public key from the last step in .ssh/authorized_keys on my remote machine—we can browse the remote ZFS tree to pick a replication target.

  you need to publish SSH keys, one way or another—the "Semi-automatic" method, which we did not test, only works between TrueNAS boxes.

• Your completed replication task can be run just once, or run on a repeating schedule.

  you need to publish SSH keys, one way or another—the "Semi-automatic" method, which we did not test, only works between TrueNAS boxes.

• By default, TrueNAS will reach out over SSH and delete snapshots from the remote system if it considers them stale. Be cautious here.

  Jim Salter

If you've got another system running a ZFS pool—whether it's using TrueNAS or not—you can replicate your TrueNAS data to it as an extremely efficient over-the-network backup method. This works whether the remote system is on the same network or across the internet—as long as you can SSH to the remote box, you can replicate to it.

First, you need to head to System-->SSH Keypairs to generate a new keypair, then copy the newly generated public key and put it in .ssh/authorized_keys for the appropriate user on the remote system. Once you've done that, the rest of the process is fairly simple; you can browse directory trees on both source and target to choose what you're replicating and where.

One thing that's not immediately apparent is just how it works when you replicate from a source dataset to a target dataset that already exists. In standard ZFS replication, that would throw an error due to the lack of matching snapshots, but TrueNAS works a little differently; it cheerfully forces things to work, so be extra careful here. If you replicate onto a target dataset that already exists, you can lose data!

TrueNAS will also allow you to freetype a dataset path that doesn't already exist, and it will create the dataset for you on first replication. This is certainly a safer way to go and closer to how things actually work beneath the hood.

Restoring from a replication task

• There's a RESTORE button on each replication job, which will run the replication task in reverse... sort of.

  Jim Salter

• After clicking RESTORE, we're invited to choose a target dataset, which defaults to the original dataset the replication task used as a source.

  Jim Salter

• There's another "gotcha" checkbox here—if you don't tick the little "enabled" box, clicking RUN NOW won't do anything. It won't throw an error, mind you—it just won't do anything.

  Jim Salter

• You might think running "restore" would put things back the way they were when you last replicated, fixing any errors or corruption since then. You would be incorrect, unfortunately.

  Jim Salter

• If we instead free-type a new, non-existing but sane dataset path to restore to, the restoration process will work as we'd expect.

  Jim Salter

For each replication task you create, there's an easy RESTORE button that will replicate in the reverse direction—from your backup onto your production system. There are some "gotchas" involved here, though.

If you accidentally delete a file, clicking RESTORE here won't bring it back—because TrueNAS will see that there are no snapshots on the target newer than those on the source, so replication will exit having done nothing. You have two options here—you can destroy snapshots on the source, then replicate them back in from the backup system, or you can restore to an alternate location.

Although it's not entirely clear, free-typing in the target text box does work. When we made up a new dataset name in the target during the creation of a Restore task, replication worked just as we would expect—all of the snapshots on the remote backup system were replicated in to our new dataset.

We didn't find this set of dialogs to be representative of either how ZFS really works under the hood or what naive users who don't understand much about either TrueNAS or ZFS are likely to expect. It works well enough to get the job done, but we strongly advise users to play thoroughly with replication and snapshot dialogs before beginning to rely on the system for real data.

We also encountered another obnoxious interface bug while testing snapshots and replication—the list of snapshot tasks or replication tasks tended to just blink off the screen for no apparent reason after a few seconds. Clicking to another menu and then back would restore them—until they'd disappear again, a few seconds later.

The issue turned out to be with browser cache not being properly cleared. Clearing the cache manually would resolve the problems for a while, though they would eventually come back. A fix has been committed for the bug; the fix is still in testing, but hopefully this will also be an issue Ars readers won't encounter.

Compatibility with other ZFS implementations

• ZFS users can generally expect to export and import a pool from one operating system to another. TrueNAS pools, unfortunately, have a bleeding-edge feature flag enabled that isn't found in most production systems.

  Jim Salter

• The log_spacemap feature flag which prevents importing our TrueNAS pool into Ubuntu 20.04 is only available in Joyent master and ZFS on Linux master.

  Jim Salter

After running a few simple fio tests, we hoped to simply export the TrueNAS pool, import it into Ubuntu 20.04, and repeat the tests there. Unfortunately, this was not to be—TrueNAS has enabled a bleeding-edge feature flag, called log_spacemap, that isn't available in typical production systems (including both Ubuntu 20.04 and FreeBSD 12.0).

We're not going to mince words here—we didn't like it when FreeNAS had hole_birth enabled back in 2014 when production systems did not, and we don't like it that TrueNAS has similarly pulled the trigger early on log_spacemap.

Enabling feature flags that aren't widely supported makes recovery an altogether sweatier process, since your ability to access the pool from an alternative operating system on a thumbdrive is impaired—and it exposes users to potential bugs lurking in a master source tree that might well be discovered and fixed before the next actual release.

Performance comparison with Ubuntu 20.04

• TrueNAS was a little slower than Ubuntu 20.04 on 1MiB random writes—which doesn't matter, unless you've got terabit(!) Ethernet. Writes over gigabit Ethernet bottleneck at around 110MiB/sec, about an eighth of TrueNAS's storage bottleneck here.

  Jim Salter

• TrueNAS loses the race again on 4KiB sync write throughput. While this is well underneath typical network bottlenecks, it's still unlikely to be a problem for most NAS use-cases.

  Jim Salter

• Latency, not throughput, is really the killer metric on 4KiB writes. What we're seeing here are the average and worst-case times to sync a single block to disk.

  Jim Salter

TrueNAS was noticeably slower than Ubuntu 20.04 in our limited fio testing, using a set of eight Ironwolf 12TB disks in a single RAIDz2 vdev. With that said, we don't think the performance difference is likely to actually matter for most NAS users.

We tested two simple metrics here—1MiB async write throughput and 4KiB sync write latency. In each case, we used eight parallel processes with an I/O queue depth of 8, and we tuned recordsize to match the operation block size. Sticking to eight processes and iodepth=8 gives the operating system and filesystem implementation a little extra breathing room in which to attempt to efficiently order writes. This helps expose differences in the software stacks, since the actual hardware remains unchanged.

For the 1MiB tests, all we really need to do is outrun the network. Gigabit Ethernet bottles at roughly 110MiB/sec, so although Ubuntu "outran" TrueNAS here, it really doesn't matter—TrueNAS is already beating the network by a solid factor of eight.

For the 4KiB test, we included throughput numbers—but mostly just for comfort. The interesting statistic here isn't throughput, it's latency. What we're really doing here is finding out how long it takes to sync an individual 4KiB block to disk. In addition to the average latency—which is just the inverse of throughput—we can check peak latencies here.

TrueNAS is noticeably slower than Ubuntu here, with thirty-three percent higher average latency, and more than double the peak latency. This still should not typically be considered a deal-breaker for TrueNAS. Most NAS workloads won't rely heavily on 4KiB operations—the kind of photos, movies, and other large files most users primarily store on NAS appliances won't be affected by poor 4KiB sync performance.

If you want to get deeper into TrueNAS's full featureset than we did and run VMs or potentially database-backed services directly on the system, those 4KiB numbers will start becoming more important. But if you're doing that, you really shouldn't be relying on a wide RAIDz2 vdev the way we did here, either. In order to accelerate that workload, you'll instead want mirrors, narrower stripes, and possibly a LOG vdev as well.

Conclusions

We've been following TrueNAS Core's development off and on since March, and we're pretty pleased with it. Unifying the codebase between FreeNAS and TrueNAS allows iXsystems to devote more focus to developing a single, coherent, effective interface—and to squashing bugs as they pop up.

FreeNAS, and now TrueNAS Core, have come a long way in the past several years. TrueNAS Core is an easy way for a home admin or hobbyist who's a little nervous about the command line to maintain a truly robust, feature-rich ZFS storage server. It's also good for potential TrueNAS Enterprise customers to get their feet wet with a free edition that looks just like what they'll be working with if they pull the trigger on a commercial license.

Although we didn't see the best absolute performance out of TrueNAS, we don't think the differences in performance between it and Ubuntu will be as relevant for most users as the expansive interface and easy setup are. There are also plenty of ways to drastically increase performance above the simple setup we explored here; for instance, a fast LOG vdev would have accelerated those 4.8MiB/sec 4KiB writes to 100MiB/sec or more.

TrueNAS Core is still in beta, and unlike some open source projects that live in fully production-ready "beta" status for years, it means it. We aren't ready to recommend TrueNAS Core for prime-time use by users who aren't prepared to take bugs in stride and actively participate in finding them, reporting them, and living with them in the meantime.

But this is an exciting project with an unusually deep featureset, and we look forward to looking again after the bugs are ironed out and it reaches release status later this year.

Let's block ads! (Why?)

Technology - Latest - Google News
July 19, 2020 at 08:00PM
https://ift.tt/39mHStH

TrueNAS Core will soon replace FreeNAS—and we test the beta - Ars Technica
Technology - Latest - Google News
https://ift.tt/2AaD5dD
Shoes Man Tutorial
Pos News Update
Meme Update
Korean Entertainment News
Japan News Update

Bagikan Berita Ini