Wrapping Up

Once the unit is mounted, it looks okay—you're not seeing much of the mods.

Figure 6: Finished mod in its new orientation

This modified NAS is now the quietest device I have in the living room and the CPU idles around 40 degrees. An additional modification I feel better about is adding ventilation to the front panel. The panel is black, the interior is unlit, so since this photo was taken, I've drilled a series of holes through the door. It helps with the temps of the drives themselves (for which there are no sensors that I've found.)

The modified NAS runs cooler than the stock product. The new fans add about 30 bucks to the cost of the unit, or $60 if you don't already have a security bitset.

I've spent some time looking at the motherboard, obviously, and also looking at the embedded Linux. In the photo (blurry, apologies) below, the 14 pin connector up top is a JTAG connector. The CPU is an MPC8343VRAGD and it looks to me as if it could potentially be detached and replaced with a more capable CPU if there is one. (I know nothing about the Freescale chips.)

At the bottom of the board in line with the JTAG is a white connector; it is a four-pin connector, CN-9, which is also labeled COM. The OS looks to live on a Spansion S29GL flash unit.

Figure 7: Motherboard closeup

I used the root password reset trick from the original review to explore a bit, and found an account on the system called engmode which I've accidentally discovered:

a) is always available

b) has the password test

I'd reset the password to test, then rebooted. I'd forgotten about the reboot; I couldn't get back into root, but I could get back into engmode, which I had happened to set the password for earlier as test. Another is vpd-vpd, which cannot be logged into without test equipment attached.

For persistent access to the system, I really like uploading the hack to replace the DLNA stuff. I don't use this as a media server, and I like being able to enable telnet and sudo without needing to redo my proxy configuration.

One thing to be aware of: if you use the NFS mode, you need to use jumbo frames. The NFS on this box is a UDP-only NFS, and it can corrupt data silently over gigabit links. UDP does a lot less accounting than TCP does, and can lose track of what byte was tied to what packet if you do a heavy sustained write.

The workaround for this is to use jumbo frames - I don't think adjusting the time window on the NFS client alone will fix it, and I wouldn't want to change the window on the Smartstor until I learn to make persistent changes in the filesystem. Or you can use SMB for both your Linux and Windows mounts of the system.

If you tell the Smarstor that it is the backup server, it opens an rsync port at 873. This rsync implementation does not have any modules defined; it is expecting a userid of Promise. So far, I've not been able to use it, but it seems the most promising avenue for using this box as a Linux backup destination.

I don't particularly like static SMB mounts in Linux and NFS is easy but risky, both security-wise and from a data integrity standpoint. The one advantage to doing a persistent SMB mount is that you can then use rsync to that mount for backup. With jumbo frames on you can, in theory, also do an NFS mount and rsync, but the data corruption issue is a real concern. I'd rather do a pure rsync but am not yet there.

If there is a way to pry the CPU off and replace it with a better one, this system is crying out for it. At rest, the OS reports a load of 1. When the system is being used (say, when writing a large file or a backup) the load on the OS spikes to 7 as reported by top. The commandline is notably pokier at that point, and this is probably the biggest bottleneck on the system.

Tags: How To, NAS, Promise,

Related Articles: