Reading (For Dummies)

D-Link DNS-323 Needs Work

A few weeks ago I had a job interview during which I was asked to define the word 'quality.' Memories of Zen and the Art of Motorcycle Maintenance came rushing forth, and I found myself at a bit of a loss for words in how to answer. I didn't get the job.

D-Link shouldn't get the job either. I recently purchased their DNS-323 network attached storage device and my review is: it stinks.

I bought it as it promised to be a good, cheap, RAID-1 NAS. What I got has a firmware laden with old software that is buggy as hell. The firmware included uses the Linux 2.6.6 kernel, and offers Ext3 filesystem support. I never realized that Ext3 had so many problems in the older kernels...

I've been trying to copy my laptop's data to the disk, about 60 gigabytes worth. I can't copy it all at one time -- the NAS randomly drops files, and leaves stale file handles open on the physical hard drive. Rebooting the NAS won't clear the problems (probably some partially written inode data?) and the interface doesn't provide any ability to run fsck. My understanding of Linux's VFS is brought into question, as I thought file locking and whatnot would be handled by the VFS and not the physical drive layer. Something bizarre must be happening.

I updated the firmware, released two days ago, that promises to fix problems copying large numbers of files to the NAS. Does it? Hardly. I reformatted the NAS after installing the firmware, just to be sure. This NAS will probably be best as a roll-your-own-firmware box. I suspect that the filesystem problems are fixed and fixable but D-Link was just too lazy to get them compiled. Newer kernels and devtools have only been around for about 2 years...

D-Link's toolchain is dated 2004 and doesn't incorporate many of the bugfixes in the arm libc since that time. For example, the toolchain code has quite a few weird functions and macros like this:

void myfunc(complextype *b){
  int c;
  (complextype *)c = b;
  *((void *) b->next)++ = c;
}

It's called an lvalue typecast, which was a bug (not a feature) in gcc many years ago. Most other c compilers don't touch this kind of calamity and bow out at the parsing stage for good reason -- the programmer clearly didn't know what they intended to do :).

There are also oddities in determining if the files are copied over correctly, probably due to the way SMB presents directory blocks to clients versus the way VFS (or whatever filesystem layer it is that OS X uses, unless it uses HFS directly? Not sure). To get around them, you could do something like this:

$ find -s /Local-Drive-Directory/ -type f -exec md5sum {} \; > /some/path/localdrive.md5sums
$ find -s /Nas-Drive-Directory/ -type f -exec md5sum {} \; > /some/path/nasdrive.md5sums
$ diff /some/path/localdrive.md5sums /some/path/nasdrive.md5sums

If you get any output from the diff command, you know the NAS has hosed your data, and you know which files it hosed.

I have to repeat that I'm pretty miffed that D-Link shipped the 323 with a broken firmware. Thankfully I did not lose too much data finding the problems. Nothing irreplaceable, anyway...

In summary, quality this is not...