Netgear ReadyNAS 716 Review: 10GBase-T in a Desktop NAS
by Ganesh T S on January 1, 2014 3:00 PM EST- Posted in
- Enterprise
- NAS
- NetGear
- 10G Ethernet
Single Client Performance - CIFS and iSCSI on Windows
The single client CIFS performance of the Netgear ReadyNAS 716 was evaluated on the Windows platforms using Intel NASPT and our standard robocopy benchmark. This was run from one of the virtual machines in our NAS testbed. All data for the robocopy benchmark on the client side was put in a RAM disk (created using OSFMount) to ensure that the client's storage system shortcomings wouldn't affect the benchmark results. It must be noted that all the shares / iSCSI LUNs are created in a RAID-5 volume.
We created a 250 GB iSCSI target and mapped it on the Windows VM. The same benchmarks were run and the results are presented below.
Encryption Support Evaluation:
Consumers looking for encryption capabilities can opt to encrypt a iSCSI share with TrueCrypt or some in-built encryption mechanism in the client OS. However, if requirements dictate that the data must be shared across multiple users / computers, relying on encryption in the NAS is the best way to move forward. Most NAS vendors use the industry-standard 256-bit AES encryption algorithm. One approach is to encrypt only a particular shared folder while the other approach is to encrypt the full volume. Some NAS vendors have support for both approaches in their firmware, but Netgear only opts for the latter. Details of Netgear's encryption strategy can be found in forum thread, but the summary is that encryption relies on a key created and stored in a mounted USB drive at the time of volume creation (the volume can't be X-RAID, but has to be set up in a manual RAID level). The USB key needs to be present at boot time for the encrypted volume to be mounted, but, can be removed later. This allows for maximum security, as the encrypted data remains safe even if the unit itself is stolen.
On the hardware side, encryption support can be in the form of specialized hardware blocks in the SoC (common in ARM / PowerPC based NAS units). In x86-based systems, accelerated encryption support is dependent on whether the AES-NI instruction is available on the host CPU (not considering units based on the Intel Berryville platform). Fortunately, the Xeon CPU used in the Netgear ReadyNAS 716 does support AES-NI. So, we can expect performance loss due to encryption enabling to be minimal / non-existent.
We enabled encryption on a a CIFS share to repeat our Intel NASPT / robocopy benchmarks. The results are presented in the graph below (with the unencrypted folder numbers for comparison purposes).
As expected, encryption carries almost no performance hit. In a number of cases, the numbers seem to even favour the encryption case. It goes to show that the bottleneck is on the disk or network side for those cases, rather than the RAID and encryption-related computation on the NAS CPU.
Facebook
Twitter
RSS
24 Comments
View All Comments
Guspaz - Wednesday, January 1, 2014 - link
Yikes, that's a highly questionable decision, to go with btrfs instead of ZFS as the default file system. ZFS has been in production use for seven years now, proven through widespread deployments and available on every *nix platform you can think of, while btrfs is still beta quality (without even an official stable release) and nowhere near feature-competitive with ZFS...JDG1980 - Wednesday, January 1, 2014 - link
Agreed. This is a full-fledged Xeon PC with ECC RAM, so why not go with ZFS? It would seem to be the obvious choice for a high-quality, time-tested software RAID system.By the way, it would really be better if you listed the suggested retail price on the first page of reviews along with the other specs. (A quick Google search seems to indicate that the street price is $2500-$3000.)
Runiteshark - Wednesday, January 1, 2014 - link
Probably because it takes a bit more effort to get ZFS running in Linux than btrfs, but not that much. It recently went stable and is working just fine on a 72 bay Supermicro chassis I have in test for the past 3 months. All this being said, why didn't they just go with a BSD solution?nafhan - Thursday, January 2, 2014 - link
While, BTRFS has been supported as a root file system in SLE and Oracle Linux since 2012. ZFS: not available from the vendor on either (even though Solaris is owned by Oracle). That's probably it right there.shodanshok - Friday, January 3, 2014 - link
I agree. While BTRFS is quite stable now, considering the critical role assigned to a filesystem I would go with a FS with a proven track record (and fsck). Moreover being a CoW filesystem, BTRFS tend to be extremely fragmentation prone in some circumstances, basically everytime a file rewrite is required, for example a database or a virtual machine (but I think that a similar NAS units is primarily assigned with archiving role).SirGCal - Wednesday, January 1, 2014 - link
Yup, I have two 8-disk systems myself. One running hardware LSI controller for RAID 6 and one using ZFS for the same effective protection. Sure the hardware controller is actually a tiny bit faster at hard reads, but for the $600 price tag, so what. All of my current systems are going to be ZFS. These arrays in a box are interesting until they decide to go with some other pooling system... If there is a real comparable reason and argument for BTRFS instead of ZFS, I'd like to see it.Runiteshark - Wednesday, January 1, 2014 - link
I tested btrfs recently with a large disk array (read 45 4TB drives) and the performance was very poor. Ended up going with JFS and shunned XFS because it's not stable in the event of power issues.shodanshok - Friday, January 3, 2014 - link
Hi,from my understanding JFS and JFS2 are more or less unsupported from some time now.
What problem did you have with XFS? It is designed to manage the exact case you describe: a lot of space spread over a lot of spinning disks. When using XFS, the only two thing that can lead to data loss are:
1. no barrier/FUA support in the disk/controller combo
2. an application that rewrite files with truncate and do _not_ use fsyncs
Case n.1 is common to all filesystem: if your disk lies about cache flush, then no filesystem can save you. The only thing that can somewhat lessen the risk is journal checksumming, that is implemented in both XFS, EXT4 and BRTFS, but I don't know about JFS.
Case n.2 is really an application shortcoming, but EXT4 and BTRFS choice here are the more sensible one: detect such corner case and apply a work-around. Anyway, with application the properly use fsync, XFS is rock stable.
Regards.
Runiteshark - Wednesday, January 1, 2014 - link
On one hand, I'm happy that 10g is becoming more prevalent slowly for the con/prosumer grade market, however products like this make my head hurt. The performance that you were able to get out of this host were nothing short of embarrassing, and could of easily been handled by a single gigabit link. I think this primarly stems from vendors still using software RAID without using good quality HBAs. You can most certainly have a fantastic software solution that is high performance without a real RAID controller or even a high end HBA, however it requires you use ceph, or ZFS.The performance you are seeing out of this is actually very similar to a HP Microserver that I have running on FreeNAS with 2GB of ram, LAGG gigabit ports, 4x4TB 7200rpm Seagates + 32GB USB3 OS drive, granted the entire unit cost no more than $1800, and only has 4 slots instead of 6. Without a doubt if I was going to build something bigger, I'd use a Supermicro X9DR7-TF+, same as what I use in production for $800, get a decent chassis, the LSI BBU and have support for up to 16 drives with 2 10G ports with an Intel X540 chipset, which all toghether would still be significantly less than this solution, and obviously blow the performance of this out of the water.
hpglow - Wednesday, January 1, 2014 - link
Runiteshark not good at reading or convertng bits to bytes? With some of the tests pushing over 600 MB/sec a 1G ethernet port would be saturated more than 4 times over not including packet overhead. A 1Gb ethernet port is good for only 125 MB/sec.