DNS-320

D-Link's DNS-320 is a low cost NAS device for home usage. it is capable of using up to 2 hard drives.

Jamie Lentin described DNS-320 device itself and linux installation on it, on his dlink-dns325 page. there is also an interesting dns-320 page, describing device details and some info on building custom firmware. in general these pages contain all that you need to know. here i'll just focus on few remarks i found in handy and modifications i've made.

box is run on Feroceon 88FR131 processor (ARMv5l), running at 800MHz, with 128MiB ram and 128MiB flash.

it has two SATA ports, 1000mbps ethernet port, 3.3V-level serial port, and single USB 2.0 port.

device is supplied by the 12VDC, external power supplier.

Jamie suggest usage of max232 chip for level converting from TTL to RS-232 levels. the board however works on 3.3V and so does the serial port attached, so max3232 (3.3V version of max232) is needed. max232 is reported to work, though it's better to be safe than sorry.

additional modification is putting RS-232 pins (gnd, tx and rx) outside, via the hole in the back of the box. max3232, along with the required capacitors, are glued back to the device metal box. this way it will not move/short-circut, but still bill be hidden inside the device itself. it makes RS usage very convenient.

one more thing – to stop booting of the original u-boot and firmware, when the text says “Hit any key to stop autoboot” one must press “space” followed by “1” - other combinations will not work. it is mentioned on the Jamie's page, but just hides in the text – i've missed that and spent quite some time, being sure that my RS-232/TX connection is failing.

Jamie described and made available package for controlling fan and temperature sensors. they work nice on the default setup. w/o it there is no dynamic fan control. the bad news is that FAN allows only 3 speeds: 0rpms (nice), 3krpms (disturbing) and 6krpm (hell loud).

in my case device is placed in a not too big closet, when it operated for some time, under load, fan was unable to get CPU bellow 48*C, thus FAN was operating at 6krpm constantly (due to 2*C hysteresis). this was unacceptable so i've decided to coll things down a little. i've placed silent force fan 12 on top of it. it's 12x12cm, 1100rpm, 12VDC with fluid dynamic bearings, giving total max noise of 12.9dB/A. though it is PWM controlled, i decided to skip control and leave it on all the time – it is quit enough any way and does not consume much power.

fan was mounted on the top of the device, and closing plane was permanently removed.

additionally, to minimize the vibration noises, i used felt “washers” under the fan, so that it won't touch the box directly.

fan is powered directly from the supplier. power supply cord was cut and 3-pin goldpin was soldered in, so that the fan can be naturally plugged in. it has to be easily demountable, since fan is expected to die in about 2-3 year time.

after mounting external fan, typical idle temperature for the CPU is about 38*C. even under load for a long time it rarely goes to 43*C. since thresholds for small, noisy, internal fan are 45*C (3kprm) and 50*C (6krpm), effectively it is never run! :)

installing linux on DNS-320 is not a new subject. probably the most interesting set of articles and remarks on that topic has been prepared by Jamie Lentin on dlink-dns325 page. this part gives some installation ideas you may like.

since i like having easily upgradable kernel and system, option of using internal flash as the place to store read-only system image was out.

finally i've decided to use 16GB USB drive as a system disk and 2x2TB disks for data. 4TB data space is split to 1TB of RAID1 (mirrored) partition, for important data and 2TB of RAID0 (striped) space, for data that are less important (backup copies from other machines, internet radio records, etc…).

using USB thumb drive as a system partition means that rotary drives can be spin down most of the time saving power, device life time and noise level at night. partitions split gives secure location for unique data and lots of space for non-important and temporary stuff. part of this is also a shared location, via witch local users can exchange files.

just to be on the safe side, you might want to disable access times updated (noatime mount option) on your pen drive. there are pen drives with time-unlimited warranty – this might be a good idea as well.

having constant disk layout allows to hardcode boot device in u-boot. since second hard drive starts about 10 seconds after the first one, and USB is able to initialize in few seconds, pen drive is always /dev/sdb. thanks to this one can simply provide root=/dev/sdbX as the parameter for kernel, and save it as a bootcmd u-boot's parameter.

u-boot does not handle ext4 (nor ext3, in fact), so the location with kernel image and dtb file needs to be ext2 ((v)fat? spare me… ;) ). however when powers goes down, ext2 can get damaged easily. to overcome this i've placed boot elements, on the separate, ext2 partition (50MiB is more than enough) while the remaining part of the system resides on ext[34]. this way i can mount ext2 on /boot as read-only filesystem and have root (/) as ext[34] and keep both u-boot and me happy.

for that price there are no hardware RAIDs – software solution is the only one. fortunately it works nicely under linux. usual stuff – mdadm is your friend.

when multiple users use the same space it is beneficial to use per-user quota. this helps keeping space organized.

installing quota package under debian works like a charm. turning quota slows down transfer by about 5%.

to start quota, on all quota enabled disks add:

modprobe quota_v2
quotacheck -vaugm -F vfsv1
quotaon -a

to the /etc/rc.local file.

to enable user-level quota on a given partition usrquota option must be passed when mounting.

there is one pitfall. device's CPU is not too fast. in fact, when it comes to encryption, it is dead slow. at first i wanted to make both data partitions encrypted, but i had to pass on that – after turning encryption on, i/o on the device dropped ~100x, making it simply unusable. similar thing applies to ssh – remote shell is fine, but if you plan to use sshfs to get to your data, think again. both CIFS and FTP work fine.

in general, after installing own linux (i personally used debian/stable), performance does not change, compared to the standard firmware. what you can expect is about 25MB/s r/w via CIFS/FTP for bigger files (ex. disk images) and about 10-15MB/s for smaller ones (ex. pictures).

generally device is slow. in times of NTB disks it does take time to push data on the remote disks, connected to the DNS-320. device can be considered as a nice, low cost solution, when performance is not critical and encryption not required.

debina/stable installation with CIFS enabled consumes less than 30MiB of ram, thus swap is not needed. in fact it is highly not recommended. swap on USB will shorten its life (when used) and on rotary disks will often spin it up/down. due to its low performance, swapping usually means device is dead for an a'priori unspecified amount of time.

it is highly recommended to disable swap at all. if you're sure you need, ensure swapinness is set to minimum, so that system will swap only when out of RAM:

echo 0 > /proc/sys/vm/swappiness

in /etc/rc.local will do the trick.

SATA disks should be spin down most of the time. it can be achieved with hdparm. i personally use 16 minutes of idle before spinning-down and do not spin down by default. to do so add following loop to the /etc/rc.local file:

for d in sda sdc
do
  hdparm -S 192 /dev/$d # sleep after 16 minutes
  #hdparm -Y    /dev/$d # got to sleep mode right away
done

for experiments note that even though hdparm says it can set spin down after just a few seconds of disk being idle, in fact, for most drives it does not allow times shorter than 5 minutes. this is not a bad thing itself (after all shorter times usually mean either a configuration error or a brain error ;) ), but it would be nice of hdparm to inform user about this fact and save some frustration.

since /etc/fstab entries, not marked with noauto are required to exist, it is better to mount external partitions manually, in /etc/rc.local. in case of hard disk failure, it will not prevent system from booting (keep in mind it has no screen nor keyboard attached).

during usage of the device i found it convenient to have a common script for checking current state of the device: temperatures, FAN speed and disk states. all of this is reported by simple sys_stat scripts:

#!/bin/bash
echo "CPU Temp: `dns_temp 2>&1` C"
hddtemp /dev/sd[ac]
echo "FAN: `cat /sys/devices/platform/gpio-fan/fan1_target 2>&1` RPM"

device itself is unable to do real encryption because of the performance. it is possible however to store data, encrypted on the client side (i encrypt my backups for years now – it does not cause any trouble :) ).

there is a nice package called ecryptfs that does just that. it allows user to mount one directory to another, making its content encrypted on the per-file basics. further more file names can be mangled as well, so that when not mounted, directory's content looks like a random garbage. though this is a FUSE-based fs, performance is not hurt, since it is still much faster than DNS-320 itself.

in general such an on-the-fly encryption gives better performance and does not require to preallocate space for the loopback, crypto device.

hard disks i/o is to be minimized. spin up and down does limit drives' life time. additionally starting and running disk causes an extra noise. when it comes to the pen drives, r/w cycles are highly limited.

fortunately device has a lot of RAM. after installing and configuring debian, device typically uses less than 30MiB of RAM – this means that almost 100MiB are not used at all, most of the time. also not all applications need full disk i/o – examples are internet radios and slow torrents.

the solution would be to introduce virtual, hierarchical storage, that would occupy RAM, USB pen drive and SATA disks. RAM would be used by default. when RAM is full, or some predefined amount of time would pass, it can be flushed to pen drive (low power, low noise and persistent) and when pen drive space (i.e. dedicated to this virtual drive) is full, it would be all flushed to the rotary disks. this way up/down spins would be limited to a minimum.