Hacking D-Link DNS-315 NAS 3: performance

Now let’s try to squeeze the most performance of it.

First, I have set up SAMBA as this is the most important file sharing protocol supported by this NAS; everything else revolves around it. I created some shares, mounted them on my Linux box. Unix extensions on SAMBA are enabled, that’s good – I can see the owners and file modes correctly. But when I tried to create a symlink – bah! – got access denied?

Long story short, after digging the SAMBA sources I found out that those strange D-Link guys hacked them badly and ugly. In particular, they changed the ‘follow symlinks’ option from its default of ‘yes’ to ‘no’. So, everything you have to do is to add ‘follow symlinks=yes’ to /etc/samba/smb.conf and restart SAMBA. You’ll have to do that manually after every reboot, of course – or write a script to do it automatically 🙂

Another thing I wanted to try is to compare the performance of NFS and SAMBA and decide which of two is better to use. Long time ago SAMBA was no alternative to NFS because it was missing file ownership and mode info; but things changed since that and nowadays it’s a quite functional alternative.

So, I’ve made my SAMBA shares also available via NFS, mounted them on my PC and did a simple test by dd’ing a large file (>1Gb) to /dev/null (dd if=largefile.avi of=/dev/null bs=64k). Fortunately, dd will do all the math for us, so we get the numbers… what??? 17Mb/s? What the hell?

After some research I found that the guys at D-Link, amongst other things, forgot to correctly set up NFSD. If you do a ‘cat /proc/net/rpc/nfsd‘ you can see that the ‘th’ (threads) line says the NFS daemon uses a single thread to serve client requests. So, basically, CPU usage goes to 100% on a single core and the second core stays idle. That’s the limiting factor for NFS. We have to increase number of NFSD threads at least to number of CPU cores, or more. To increase number of NFSD serving threads just  run ‘rpc.nfsd 4‘ to set th to 4, for example. After that my ‘dd’ test shows a increase in throughput from 17 to 27Mb/s! That’s way better.

Then I tried the ‘dd test’ with SAMBA shares and – guess what – it gave me 58Mb/s! That’s astonishing, given the fact that ‘dd’ on NAS can’t read more than 48Mb/s directly from /dev/sda! Moreover, during the test the CPU load is under 20% (just one core).

Some research has revealed that the SOC used on DNS-315 contains a circuit named “Network Offloading Engine”. My guess is that this circuit (with appropriate support from kernel) can pump data directly between SATA and Ethernet controller, without CPU intervention. So, on this NAS the best results on file sharing operations can be achieved when this hardware data pump support is activated.

It looks, like this support is built into the Linux’ sendfile() system call. This syscall just copies data from one file handle to another; if it happens that one handle points to hard disk and other to Ethernet, the kernel support activates the CPU-less data pumping function.

Now, as you understand, the most important option in smb.conf is “use sendfile = yes”. If you set ‘use sendfile=no’ in smb.conf, it starts crawling just like NFS. So, don’t do it! 🙂

So, in the end, I decided to use SAMBA and avoid using NFS. Unfortunately, the NFS implementation does not use sendfile() (perhaps because NFSD is already implemented in kernel, so it won’t gain anything on “regular” hardware). So, the net result is that NFSD can’t take advantage of the huge performance benefit provided by the “Network Offloading Engine” on PLX NAS 7820 SOC.

Now, to put it all together, let’s create a script that will automatically optimize NFSD performance (just in case) and enable symlinks in SAMBA at NAS startup. Create a shell script in /ffp/start/ and put the following inside:

#!/bin/sh

if grep -q '^th 1' /proc/net/rpc/nfsd ; then
    # set up 4 threads to handle NFSD requests
    # instead of default 1 which is ineffective on a 2-core config
    rpc.nfsd 4
fi

# fix SAMBA symbolic links
if ! grep -q 'follow symlinks' /etc/samba/smb.conf ; then
    sed /etc/samba/smb.conf \
        -e '/^\[ global \]/{' \
            -e 'a \' -e 'unix extensions = yes' \
            -e 'a \' -e 'follow symlinks = yes' \
        -e '}' > /etc/samba/smb.conf.new
    if [ -r /etc/samba/smb.conf.new ] ; then
        mv -f /etc/samba/smb.conf.new /etc/samba/smb.conf
        while pidof smbd >/dev/null ; do
            killall smbd
            sleep 1
        done
        smbd -D
    fi
fi

After that, chmod a+x the file so that it will automatically run at startup, and you’re done!

Hacking D-Link DNS-315 NAS 2: software

Of course, the first thing I did was to put some real software on it, besides that limited stuff that D-Link puts in firmware.

Fortunately, somebody already did most of the work, so I just had to install ffp_plug and get the ssh door open. Whack! I’m inside.

The first unpleasant thing I encountered is the utterly dumb habit of the firmware to ‘chmod 0777’ all files on my hard drive on every boot! Yes, it just runs ‘chmod -R a+rwx /mnt/HD’ or something like that – on every reboot. This means that all the nice file modes in ffp subdirectory full of binaries, libs and configs will get flat 0777 after first boot, not speaking if you’re going to use file modes to separate access rights for different NAS users.

Fortunately, this problem also has been dealt with, so we just have to follow the instruction. Do it before you reboot for the first time, and everything will be allright. If you already got everything chmoded, it’s easier to re-install ffp_plug from scratch, like I did :), and then install the uwchmod package before NAS gets a chance to trash your file modes.

Now, to make things simpler, I’ve changed user and group ids in /etc/{passwd,group} on NAS to the IDs I use on my home linux boxes. After you modify passwd, shadow or group files you have to run the ‘store-passwd.sh’ script which will just copy them from the root ramdisk to /usr/local/config/ which is located on your HDD, so it won’t get lost after reboot.

Hacking D-Link DNS-315 NAS 1: hardware

Last week I bought a DNS-315 NAS from a guy that didn’t know how to use it. The idea is to put all the multimedia stuff on it, buy an additional Android-TV box, this way my home computer doesn’t have to be powered on every time my son asks to view a cartoon.

The first thing I did (just like the quick install guide says) was to open the box. Well, I opened it maybe a bit too wide, took out the mainboard and studied it a little 🙂

Well, the CPU is more or less bearable. The SOC is a PLX NAS7820 chip which contains a dual-core ARM11 CPU at 750Mhz (Linux’ shows 300 “BogoMIPS” but I assume that’s because at early startup, when “BogoMIPS” are measured, the CPU isn’t running at full speed – my Galaxy S5, for example, shows 48 “BogoMIPS”, for Snapdragon 801).

It contains a Oxford Semiconductor OX820 SATA 3G/s controller which can sustain 48Mb/s when directly reading from the Seagate Video 2Tb HDD I inserted (which shows about 190Mb/s sustained being connected to a PC).

Plus an USB 2.0 port which can be used to connect USB HDDs/flash drives and, possibly, other types of USB hardware (that depends on how kernel’s configured).

And last but not least, it has a Gigabit Ethernet controller. With iperf I was able to measure about 760 MBits when sending data from NAS to PC and 488 MBits in the reverse direction; in both cases the limiting factor was the NAS CPU as it goes up to 100% on one core (and the second core is not used at all); I suppose iperf does some checksumming of the sent/received data; if it wouldn’t, the PC->NAS numbers would be much higher.

Also, as you can see from the product brief (available if you click on “NAS7820” above), the SOC contains a “Network offload engine” which, as far as I understand, can pump data directly from hard drive to network and back, thus substantially rising file server performance. More on this later.

Some researcrh revealed that there are similar products from other vendors, namely Medion Life P89626/P89630/P89635/P89636 aka NSA-212 and some Zyxel NASes are using the same SOC, so they should be compatible to some extent at hardware level; they use different software though (the proprietary D-Link web-interface and all related stuff), although the Linux kernels should be similar.

Here’s a photo of the mainboard, top and bottom:

At bottom-right you can see a 4-contact unsoldered connector which is, I guess, console UART. One of the pins is connected to GND plane, one is unconnected, and the two other are, I guess, RX and TX. Will try that some day, perhaps.