QNAP NAS

QNAP TS-439 PRO II+ NAS

A NAS (Network Attached Storage) is a disk server on the network. This QNAP NAS has a single-core Atom 1.8 GHz processor, 1 GB RAM and 2 gigabit ethernet ports (for failover or bundling). See a complete description here.

Lots of disk space on a gigabit LAN

I went visiting a friend, who had bought a NAS, and we checked it out, and found, that it was not powerful enough to handle a gigabit ethernet interface at full speed. You get the storage but not the speed with cheap hardware, but that's not good enough for me. I want both.

So I bought a NAS which could even do ethernet bundling (2 ethernet interfaces in parallel should give twice the speed - in theory). and that's where the limit of this one is. It can't deliver 200 MB/s even using the simplest network protocols. Otherwise it's wonderful. And it's a fully functional Linux server, which you can configure to suit your own needs.

RAIDs and file systems on the disks

All disks are of the same size, although it is possible to have different-sized disks in it. I have configured it for RAID-5 using four 1.5-TB disks. This gives a total of 4 TB with the possibility of a disk failure without data loss. The fdisk command shows four disks with identical partition tables: First two small ones, then a large one, and another small one in the end. Partitions are numbered from 1-4. Everything else is numbered from 0..n.

There are four raids on the disks corresponding to the four partitions:

md9 uses partition 1 and contains configuration files.
md4 uses partition 2 and is used for swap.
md0 uses partition 3 and is the user data partition.
md13 uses partition 4 and does not seem to be used - however, this is not the case.

All raids except the large one for user data are mirrors, meaning that the size won't increase with the number of disks. The large one can be set up with various raid types and options. The other ones are administered by the system and normally not visible to the user.

[~] # fdisk -l /dev/sd[abcd]

Disk /dev/sda: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 1 66 530125 83 Linux
/dev/sda2 67 132 530142 83 Linux
/dev/sda3 133 182338 1463569693 83 Linux
/dev/sda4 182339 182400 498012 83 Linux

Disk /dev/sdb: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sdb1 1 66 530125 83 Linux
/dev/sdb2 67 132 530142 83 Linux
/dev/sdb3 133 182338 1463569693 83 Linux
/dev/sdb4 182339 182400 498012 83 Linux

Disk /dev/sdc: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sdc1 1 66 530125 83 Linux
/dev/sdc2 67 132 530142 83 Linux
/dev/sdc3 133 182338 1463569693 83 Linux
/dev/sdc4 182339 182400 498012 83 Linux

Disk /dev/sdd: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sdd1 1 66 530125 83 Linux
/dev/sdd2 67 132 530142 83 Linux
/dev/sdd3 133 182338 1463569693 83 Linux
/dev/sdd4 182339 182400 498012 83 Linux
[~] #
[~] # cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath]
md0 : active raid5 sda3[0] sdd3[3] sdc3[2] sdb3[1]
4390708800 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]

md4 : active raid1 sdd2[2](S) sdc2[3](S) sdb2[1] sda2[0]
530048 blocks [2/2] [UU]

md13 : active raid1 sda4[0] sdd4[3] sdc4[2] sdb4[1]
458880 blocks [4/4] [UUUU]
bitmap: 0/57 pages [0KB], 4KB chunk

md9 : active raid1 sda1[0] sdd1[3] sdc1[2] sdb1[1]
530048 blocks [4/4] [UUUU]
bitmap: 0/65 pages [0KB], 4KB chunk

unused devices: <none>
[~] #
[~] # cat /proc/swaps
Filename Type Size Used Priority
/dev/md4 partition 530040 1012 -1
[~] #
[~] # cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext2 rw,relatime,errors=continue 0 0
/proc /proc proc rw,relatime 0 0
none /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0
sysfs /sys sysfs rw,relatime 0 0
tmpfs /tmp tmpfs rw,relatime,size=65536k 0 0
none /proc/bus/usb usbfs rw,relatime 0 0
/dev/sda4 /mnt/ext ext3 rw,relatime,errors=continue,data=writeback 0 0
/dev/md9 /mnt/HDA_ROOT ext3 rw,relatime,errors=continue,data=writeback 0 0
/dev/md0 /share/MD0_DATA ext4 rw,relatime,user_xattr,barrier=1,data=ordered,jqfmt=vfsv0,usrjquota=aquota.user 0 0
nfsd /proc/fs/nfsd nfsd rw,relatime 0 0
djmount /mnt/QUPNP fuse.djmount ro,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other 0 0
tmpfs /var/syslog_maildir tmpfs rw,relatime,size=8192k 0 0
tmpfs /.eaccelerator.tmp tmpfs rw,relatime,size=32768k 0 0
[~] #
[~] # ls -ld /etc/config
lrwxrwxrwx 1 admin administ 21 Mar 29 16:53 /etc/config -> /mnt/HDA_ROOT/.config/
[~] #

The first partition is used for configuration files, and these files are accessible and can be changed by the user. This can be seen by the symlink /etc/config, which points to /mnt/HDA_ROOT, which is the mount point for /dev/md9.

The second partition is used for swap, which can be seen by the swap system reporting using /dev/md4 as swap device. Don't get confused by the fact that it really is a raid while the list mentions it as type partition - is is a raw block device in contrast to a file, which is in a file system on a raw block device.

The third partition is for user data, and is accessible via /share/MD0_DATA.

The fourth partitions seems not be used, and then /dev/sda4, which is a member of a raid, is mounted on /mnt/ext. This is not the normal way of using a raid. However, it means, that the fourth partition is accessible via /mnt/ext in some less-than-normal way.
[~] # find / -xdev | while read xx ; do ls -ld "$xx" | grep '/mnt/ext' ; done
lrwxrwxrwx 1 admin administ 20 Mar 29 16:53 /bin/vi -> /mnt/ext/opt/vim/vim*
lrwxrwxrwx 1 admin administ 20 Mar 29 16:53 /bin/vim -> /mnt/ext/opt/vim/vim*
lrwxrwxrwx 1 admin administ 30 Mar 29 15:55 /etc/init.d/gt_run.sh -> /mnt/ext/opt/DSv3/gt/gt_run.sh*
lrwxrwxrwx 1 admin administ 29 Mar 29 16:52 /etc/raddb -> /mnt/ext/opt/radius/etc/raddb/
lrwxrwxrwx 1 admin administ 35 Mar 29 16:53 /etc/openvpn -> /mnt/ext/opt/vpnopenvpn/etc/openvpn/
lrwxrwxrwx 1 admin administ 33 Mar 29 16:53 /etc/dbus-1 -> /mnt/ext/opt/avahi0630/etc/dbus-1/
lrwxrwxrwx 1 admin administ 32 Mar 29 16:53 /etc/avahi -> /mnt/ext/opt/avahi0630/etc/avahi/
lrwxrwxrwx 1 admin administ 39 Mar 29 16:52 /sbin/xtables-multi -> /mnt/ext/opt/vpnpptp/sbin/xtables-multi*
lrwxrwxrwx 1 admin administ 34 Mar 29 16:53 /sbin/ntpd -> /mnt/ext/opt/ldap_server/sbin/ntpd*
lrwxrwxrwx 1 admin administ 34 Mar 29 16:53 /sbin/ntpq -> /mnt/ext/opt/ldap_server/sbin/ntpq*
lrwxrwxrwx 1 admin administ 21 Mar 29 16:52 /home/httpd/cgi-bin/inc -> /mnt/ext/opt/lang/inc/
lrwxrwxrwx 1 admin administ 24 Mar 29 16:52 /home/httpd/cgi-bin/filemanager -> /mnt/ext/opt/filemanager/
^C
[~] #
A search through the file system (excluding mount points) for anything linked to /mnt/ext/... reveals a long list of files. It is (probably) add-on packages installed by the user. Such packages should not be installed on the large user volume, and they can't take up space on the configuration volume either, and they can't be stored on the root file system, which is read and uncompressed from ROM while booting, so here they are.

Speed tests

What can the hardware do? Let's run a few speed tests.
[~] # hdparm -t /dev/sd[abcd]

/dev/sda:
Timing buffered disk reads: 296 MB in 3.00 seconds = 98.64 MB/sec

/dev/sdb:
Timing buffered disk reads: 294 MB in 3.00 seconds = 97.95 MB/sec

/dev/sdc:
Timing buffered disk reads: 368 MB in 3.01 seconds = 122.34 MB/sec

/dev/sdd:
Timing buffered disk reads: 376 MB in 3.01 seconds = 125.07 MB/sec
[~] #
[~] # hdparm -t /dev/md[049]

/dev/md0:
Timing buffered disk reads: 842 MB in 3.04 seconds = 277.38 MB/sec

/dev/md4:
Timing buffered disk reads: 306 MB in 3.01 seconds = 101.57 MB/sec

/dev/md9:
Timing buffered disk reads: 330 MB in 3.02 seconds = 109.40 MB/sec
[~] #
The two first disks are slightly slower than the two last disks, they are normal SATA-300 disks from different manufacturers. They perform at the maximum hardware speed, the drives can't deliver more than this on a faster PC.

The mirrors don't give any extra speed, they perform just as a single disk. The large raid-5 however makes use of various optimizations such as striping to get almost three times the speed of a single drive.

Writing is significantly slower, because checksum blocks must be calculated and written as well as the data.

[/share/MD0_DATA/Public/t] # time dd if=/dev/zero of=bigfile.dat bs=1048576 count=32768
32768+0 records in
32768+0 records out

real 3m41.066s
user 0m0.264s
sys 2m36.961s
[/share/MD0_DATA/Public/t] # expr 32768 / 221
148
[/share/MD0_DATA/Public/t] #

Write speed is approx 150 MB/sec, half of the read speed. It's still higher than the limit on a 1 gigabit network, so there are no performance problems unless you enable trunking of two gigabit interfaces into one 2-gigabit interface.

Trunking two 1-gigabit interfaces into one 2-gigabit interface

The QNAP nas has two network interfaces. They can be used in different ways, either as fail-over, so one link can go down and but the nas is still accessible via the other link, or they can be combined into one logical interface, which uses the two network interfaces in various ways. There are some protocols required, which may not be implemented in a cheap switch, whereas a layer-3 switch (referring to layer 3 in the OSI model) has these protocols implemented.

With a frame buffer size of 9000 bytes, a layer-3 switch and a simple NFS protocol from a Linux-PC also with 2 network interfaces (one on the motherboard, another on the PCI bus), it was possible to reach the limit of the NAS.

A simple command finding files in the file system (the NAS on an NFS mount) and copying the contents to /dev/null should be the fastest way of reading data from the NAS.

The limiting factor is the CPU being overloaded with handling requests. A faster CPU in the NAS would probably give a better result. Still, the NAS does not deliver the theoretically possible 200 MB/sec, only about 160 MB/sec. But that's not that bad after all - it's worth the extra cabling.



Using the QNAP NAS as LAMP server

LAMP is an abbreviation for Linux, Apache, MySQL and Perl or PHP, and is a way of using Linux as a web server with database and programming support. The NAS runs Linux, and you can log in via ssh and use installed packages and even install more packages using optware. Most web/database servers depend more on hardware (network and disk) than on CPU, and with a fast 4-disk RAID or even a stripe, you should get a decent performance, even though the CPU is not so fast.

To use Linux as a LAMP server, you need
- Linux (!)
- Apache, which is installed and configurable on the NAS
- MySQL, which is also available for the NAS
- Perl or PHP, both are available for the NAS.

The configuration files can be found in /etc/config.
The default root password for MySQL is 'admin'.
Consult the apache documentation and the MySQL documentation for further details.

/etc/config is also the location of my.cnf, php.ini and many other configuration files. It is a symlink to /mnt/hda_root, as described in the file systems section above.

If you used optware or another software tool to install a different version of Apache or MySQL, then the files may be in a different location, however, the config files are still set up via a symlink to point to /etc/config, so the same set of config files are used.

All these symlinks across file systems can be confusing, but if things are made correctly, then you shouldn't have to worry about this, but simply edit the files in /etc/config.

[~] cd /etc
[/etc] # ls -l config
lrwxrwxrwx 1 admin administ 21 May 25 11:57 config -> /mnt/HDA_ROOT/.config/
[/etc] # ls -l config/apache/
-rw-r--r-- 1 admin administ 5717 May 25 11:00 apache.conf
-rw-r--r-- 1 admin administ 15107 Mar 30 2011 apache.conf.bak
-rw-r--r-- 1 admin administ 5558 May 25 10:59 apache.conf.tmp
drwxr-xr-x 2 admin administ 4096 Mar 10 22:31 extra/
-rw-r--r-- 1 admin administ 12958 Mar 30 2011 magic
-rw-r--r-- 1 admin administ 37523 Mar 17 2012 mime.types
drwxr-xr-x 3 admin administ 4096 Mar 30 2011 original/
[/etc] #
[/etc] # cd /usr/local
[/usr/local] # ls -l
drwxr-xr-x 2 admin administ 1024 Apr 26 00:16 amazons3/
lrwxrwxrwx 1 admin administ 19 May 25 10:58 apache -> /mnt/ext/opt/apache/
drwxr-xr-x 2 admin administ 1024 Apr 26 00:17 bin/
drwxr-xr-x 4 1001 1001 1024 Apr 26 00:14 etc/
lrwxrwxrwx 1 admin administ 29 May 25 11:00 jre -> /share/MD0_DATA/.qpkg/JRE/jre/
drwxr-xr-x 3 1001 1001 2048 May 25 11:56 lib/
lrwxrwxrwx 1 admin administ 25 May 25 11:56 medialibrary -> /mnt/ext/opt/medialibrary/
drwxr-xr-x 2 admin administ 1024 May 25 11:56 modules/
lrwxrwxrwx 1 admin administ 21 May 25 10:59 mt-daapd -> /mnt/ext/opt/mt-daapd/
lrwxrwxrwx 1 admin administ 18 May 25 10:58 mysql -> /mnt/ext/opt/mysql/
lrwxrwxrwx 1 admin administ 18 May 25 11:56 samba -> /mnt/ext/opt/samba/
drwxr-xr-x 3 1001 1001 1024 May 25 10:58 sbin/
drwxr-xr-x 2 admin administ 1024 Apr 26 00:11 share/
drwxr-xr-x 6 admin administ 1024 Aug 5 2008 ups/
[/usr/local] #
[/usr/local] # ls -l apache
lrwxrwxrwx 1 admin administ 19 May 25 10:58 apache -> /mnt/ext/opt/apache/
[/usr/local] # ls -l apache/conf
lrwxrwxrwx 1 admin administ 18 May 25 10:58 apache/conf -> /etc/config/apache/
[/usr/local] # ls -l mysql
lrwxrwxrwx 1 admin administ 18 May 25 10:58 mysql -> /mnt/ext/opt/mysql/
[/usr/local] # ls -l mysql/my.cnf
lrwxrwxrwx 1 admin administ 18 May 25 10:58 mysql/my.cnf -> /etc/config/my.cnf
[/usr/local] #

Error log files

The locations of the various error log files are set in apache's configuration files and in php.ini. When Apache is started, it is started as root, and then immediately switches to a lower-priority user. This is normally not a problem, but on the NAS, the log files are still owned by root, and the low-priority user does not have rights to write to them.

This makes it look like logging does not occur, but it does - it just falls on a permission error, which you can fix by giving the file write permissions for all users (chmod a+w logfilename).

So if you know, that you did enable logging to /var/log/php_error.log, but you don't see any entries, then ssh into the NAS and type
chmod a+w /var/log/php_error.log
and the entries should start to appear.