DSM-G600, DNS-3xx and NSA-220 Hack Forum

The DNS-343 seems  a little power deprived when compared to other NAS units driven by the likes of multi-core Intel Atoms or SandyBridge cpu’s. As delivered, the DNS-343 does a decent job serving up samba, but it doesn’t seem to know what to do with its Gbs bandwidth.  It definitely benefits from its built in jumbo frame capability if it is possible to use.

This message is about iSCSI, but it is also about getting the most out of a DNS-343.  Jumbo Frames not only reduce protocol requirements going from 1500 MTU to 9000 MTU, they also reduce the amount of work the CPU must do to manage the protocol.  On modern systems this extra work for the CPU is almost negligible.  On the 343, it is huge, and enables the unit to begin using the bandwidth it is endowed with.   Properly implementing jumbo frames is another subject and probably best left for systems using secondary nics, dedicated to jumbo frames.

I always felt that using the 343 as a block oriented server would be a good match for the type of power it has.  My thinking was that a server managing low level disk requests, only, would be doing less work than a server doing that and managing a file system too.  This describes an iSCSI target.  The other side of the iSCSI model, the iSCSI initiator, runs on another system – usually a server.
I have seen other discussions with the goal using a 343 as an iSCSI target, and they include talk of kernel modifications and running Debian.  I also found this:  http://zloy.pclovers.ru/2011/04/22/iscsi-dlink-dns-343/  It is in Russian, but I decided to give it a go.  An ffp unit can be updated in minutes.  So far I have found the results to be spooky.  They are too good to be true.  I must have missed something.

I currently have this 343 iSCSI target linked to an initiator on a Server 2008 R2.  This Windows/Linux marriage gives me file services that are very responsive.  Windows manages the disk format and file system (NTFS), the 343 acts like a scsi disk array, via Ethernet.  These are local disks as far as Windows is concerned.

The iSCSI drives appear in the device manager as scsi disks.  The disk manager treats them like any other local disk.  Unlike usb, iSCSI disks may be converted to dynamic disks, and run at different raid levels.  I have done a lot of testing on this setup, and I have beat it up.  It runs well as separate volumes, merged volumes, and striped volumes.  It appears to favor striped volumes, and most of my testing has been done with a striped set of four, two terabyte disks.  Jumbo frames gives me a sustained transfer rate of 30 to 35 mbs,  1500 mtu gives me a strong 20 mbs.  Regardless of the mtu, a client can write to this volume, shared via samba at well over 100 mbs for the first one or two gigs since the server makes good use of its cache.  Reads via a client cannot exceed the raw speed of the link between the server and 343.

With this setup I have rebooted the server as well as pulled the plug on the 343 in different ways trying to make it fail.  I can’t.  It won’t.  Everything always comes back up, and re-connects.  I run checkdisk on the volume – it finds nothing.  I did discover that rebooting my managed switch causes the iSCSI daemon on the target to stop.  I added a watchdog to the 343 to restart automatically, so I am back to no problems.  This is spooky, and my hat is off to Microsoft and Intel for this iSCSI implementation.

---

Attachments:
DNS-343 iSCSI.zip, Size: 456,282 bytes, Downloads: 1,584