Work and family life was busy, so it was a few days before I could put the QNAP TS-419P+ to the test with some representative use cases. But before I did, I spent some time educating myself with RAID levels and came to the conclusion that until I am in desperate need of more storage space, RAID 5 just doesn’t make sense. Here’s why. RAID 5 distributes parity across all the drives in the array, this parity calculation is both compute intensive and IO intensive. Every write requires the parity calculation, and data must be written to every drive. With the low power CPU already the bottleneck for throughput, adding an additional load didn’t seem like a good idea. More importantly is data integrity. RAID 5 allows for a single drive to fail without any loss of data. However, while rebuilding the array, if one of the remaining three drives were to fail, all the data is lost. Rebuilding a RAID 5 array after a single disk failure is also very compute and IO intensive as every disk must be read in order to restore the blocks to the new drive.
A better option for a four drive array is RAID 10, a striped pair of mirrored disks. In this configuration writes only affect the two drives in the mirror, and the data integrity is much improved. After a single drive fails, it is restored by copying it’s sibling in the mirrored pair. If one of the three remaining drives were to fail, there is only a 33% chance that data will be unrecoverable as either drive from the other mirrored pair could fail without a problem.
The cost for this is total volume size. RAID 5 provides SIZE*(N-1) while RAID 10 provides SIZE*(N/2). With 4 1.5TB drives, RAID 5 yields a 4.5TB volume, while RAID 10 yields only 3TB. When drives were expensive, this 50% gain was significant, but when 2TB drives can be had for under $100, and larger drives becoming available every year (3TB drives now ship with consumer level NAS products), the principle value of RAID 5 is not as convincing as it once was. With RAID 10 and current technology (3TB drives) I can still double my capacity, and that should only improve in the coming years.
OK, on to configuration. I took to configuring the NAS for use with my home Linux network. I should preface this by saying I am not a network file system expert, not even an experienced user. I have setup NFS enough times to know the homogeneous uid/gid thing is a pain and that there are plenty of failing corner cases with respect to dropped connections, file locking, etc. QNAP claims to support NFS, so I expected them to provide the necessary tooling in their oft-praised web interface. The sad truth is that NFS appears to be an afterthought, and the implementation barely merits an “[x] NFS” string on their marketing material. The UI allows you to add users, but not to specify (or modify) the uid or gid. This means that standard Unix file permissions simply do not work, and their solution appears to be to make the shares globally read-only or globally read-write. Two words: cop out. Fortunately QNAP does provide a root-only ssh shell, and I was able to log in and manually edit /etc/passwd and /etc/group to make my users match the rest of the network. Some careful recursive ‘chmod g+s ug+rw o-rwx’ commands provided me with the permissions I wanted – but avoiding that sort of work is precisely why I opted for QNAP instead of building my own. In this regard, they failed miserably.
The SMB story is better. The QNAP UI supports per volume user and group permissions. While the on disk representation is still globally read-write, it’s not a problem as SMB performs it’s own user authentication and only the admin user has ssh access anyway. I tinkered with this enough to get it working with the GNOME desktop file manager and with autofs. This might be the best way to access shares on the QNAP, even from a Linux system. Still, something about running SMB makes me feel like I need to shower.
For throughput tests I used the rsync daemon to copy my MythTV recordings to the QNAP. This consisted of 300GB of mostly mpeg2 files from 2 to 6 GB each. I used the UI as well as top to monitor the system status periodically during the transfer. The CPU was pegged at 100% for the duration of the transfer, and it averaged just over 20MB/s.QNAP claims 45MB/s writes over SMB and 42MB/s over FTP. Rsync should be faster if anything. Throughput was a disappointment. Following the transfer the QNAP remained under heavy load (7-8), and became fairly unresponsive. Watching the kernel logs I found a few Out of Memory errors, with apache and php being among the OOM Killer’s victims. I raised the throughput and OOM issues with QNAP and my supplier. They weren’t able to suggest any changes to improve throughput or identify why the OOM occurred. They did agree to allow me to return the TS-419P+ in exchange for a TS-459Pro+. The latter replaces the ARM CPU with a dual core Atom, doubles the RAM, and replaces the 16MB flash with a 512MB DOM. 20MB/s just wasn’t cutting it, and a kernel OOM was just unacceptable. I shipped the QNAP TS-419P+ back and am impatiently awaiting a TS-459Pro+. Whether I keep the QNAP firmware or replace it with Ubuntu Server or perhaps a custom Yocto image is the subject for a future project.