At least one potentially positive counterpoint—the NAS (networked-attached-storage) server—shines among the abundance of predominantly negative economic news about the technology sector, particularly consumer electronics. People continue to take still and video pictures, listen to music, and download movies—maybe even more so than in the past—because they’re now staying home and looking to entertainment as a means of distracting themselves from their recession-related woes. More of them are also now working from home-based offices rather than in the cubicles of times past, when large enterprise servers and IT (information-technology) personnel met and managed their corporate-storage needs. Further, an increasing percentage of their homes contain reasonably robust networking setups, enabling various LAN (local-area-network) clients, such as computers, game consoles, media extenders, and printers, to not only share a common Internet connection but also intercommunicate.

All of these trends suggest the allure of a consolidated nexus in consumers’ residences for both professional and personal content that multiple LAN clients could simultaneously access. Ideally, this centralized storage would implement a RAID (redundant array of independent disks), which would protect the NAS from the failure of any one hard-disk drive, and the NAS would also act as a backup repository for all the computers on the network. Translating this vision into reality, however, requires that home-NAS suppliers deliver an easily justifiable price for the target market; an easy-to-grasp and compelling sales pitch; an easy way for consumers to both integrate the NAS within their networks and subsequently access it from diverse devices; sufficient speed in storage, retrieval, other processing functions, and network bandwidth; and a carefully crafted set of features and cosmetics.

In the more than 12 years that I’ve been dabbling in home-office NAS, I’ve seen abundant evidence of both evolution and maturation in the consumer-NAS-product category. Accompanying these trends, both diamonds and lumps of coal have emerged across the dozens of products I’ve used (see sidebar “Hardware-test beds”). Therefore, this article aims to provide not just a snapshot of current system and silicon-and-software building blocks but also a forecast of how the NAS category might further develop, with the guidance of historical precedents, product capabilities, and customer expectations.

Begin the architecture definition of your next NAS design from the outside, focusing first on its LAN interfaces. Wired Ethernet is the most common LAN-tethering approach—with good reason. Because NAS normally operates in a “headless” fashion—that is, without the need for a keyboard, a mouse, and a display—it can easily locate nearby the router and connect to it over Category 5, 5e, or 6 cable. Wired-Ethernet connections are comparatively robust and speedy. And your customers can leverage some other networking technology by using an external bridge adapter.

However, for aesthetics, operating noise, or other reasons, your customers might instead want to hide the NAS in some out-of-the-way location, such as a closet. In these cases, you’ll want to first ensure that you’ve educated your customers on the need for consistent NAS access to sufficient supplies of cool, ambient air. Consumers probably won’t want to string Ethernet cable around their homes, so they might be willing to pay extra for an integrated alternative network-access technology.

Wi-Fi is probably not only the first approach that would come to mind but also the leading candidate by virtue of its pervasive presence in modern routers. Keep in mind that, even in its latest-generation 802.11n form, it’s likely to be a lower-performance approach than wired Ethernet, however. Performance isn’t the only reason to focus on 802.11n. Because 802.11g and other wireless predecessors are now mature, they won’t provide justification for a substantive price premium.

Speed aside, Wi-Fi is also less reliable than wired Ethernet, due to RF (radio-frequency) interference and other issues, so you’ll need to ensure that the NAS recovers from dropped network connections in a user-friendly and data-preserving manner regardless of what operating mode it’s in at the time. And the need to provide the NAS with both the WLAN (wireless-LAN) SSID (service-set-identifier) and encryption-key information before it can make the Wi-Fi connection is a challenging setup requirement for a headless-system design. Finally, you need to decide whether to support both the 2.4- and the 5-GHz ISM (industrial/scientific/medical)-band options, as well as how elaborate and expensive to make the unit’s MIMO (multiple-input/multiple-output)-antenna array (Reference 1).

Because the NAS is ac-powered, thereby requiring a nearby wall outlet no matter where your customer puts the unit, power-line networking might be a tempting alternative-LAN-interface approach. Not every power outlet is a valid power-line-networking candidate, however, and performance and reliability also vary with time of day and time of year (Reference 2). So, at least for now, ignore the temptation to integrate this feature and stick with an external Ethernet-to-power-line-bridge adapter. The three contending power-line-networking technologies—HomePlug AV, UPA (Universal Powerline Association), and HD-PLC (high-definition power-line communications)—exhibit no serious signs of interest in pursuing interoperability, so if you “bet on the wrong horse,” you’ll add cost to your design and gain nothing (Reference 3).

Similarly, I don’t currently recommend that you integrate either a HomePNA (Phoneline Networking Alliance) or a MOCA (multimedia-over-coaxial) transceiver. Neither technology is sufficiently mature to be in use by much of your potential customer base. And the need to connect such a NAS to a phone-line- or coaxial-cable-based network tether is too location-restrictive for many homes.

Unless your target customer is a power user and particularly considering that a notable percentage of LAN clients will likely be accessing the NAS over low-bandwidth Wi-Fi connections, it may be difficult to justify the incremental cost of 1-Gbps GbE (gigabit-Ethernet) LAN transceivers versus conventional 10/100-Mbps alternatives. If a built-in Wi-Fi or 100-Mbps wired-Ethernet bottleneck constrains the NAS transfer-rate speed, there’s little rationale for a performance-tailored RAID 0, RAID 5, or similar multidrive-striped-storage architecture behind the network PHY (physical)-layer IC. Conversely, if you believe your target customer will see tangible value in GbE or multistream, bonded-channel 802.11n-networking capabilities, you should seriously consider correspondingly beefing up your design’s drive array.

Including more than one drive in your design typically costs more unless you’re comparing, say, a leading-edge 2-Tbyte drive with two more mature 1-Tbyte alternatives in a concatenated arrangement (Reference 4). Using a multidrive design also means that the NAS will need a larger system form factor, generate more heat, and, therefore, have a greater likelihood of needing to employ a noisy system fan. As such, seriously consider 5400-rpm drives instead of 7200-rpm alternatives. Thanks to dense bit-packing PMR (perpendicular-magnetic-recording) techniques, the slower-spinning drives still deliver robust transfer rates, and they consume notably less current. Despite the downsides of using multiple drives, avoid selecting a nonmirrored-drive architecture unless the customer will use the NAS exclusively for connected-computer backup. In the backup-only case, if the NAS drive fails, your customers will likely be able to swap in a replacement drive before any backed-up computer’s drive also fails.

Think about it: Your marketing counterparts will be advocating that your customers should use the NAS as a single-point-of-storage contact for all of their precious—often irreplaceable—digital data: music libraries, photographs, videos, financial records, and the like. Unless you use a RAID 1, RAID 5, or other mirrored-drive arrangement, such as Infrant’s (now Netgear’s) proprietary and flexible X-RAID, an inevitable drive failure will render that information permanently irretrievable. You can surely convince your customers of the value of redundancy within the NAS, yes? This topic brings up a bigger issue regarding how the NAS market may evolve in the future. Today’s NAS suppliers include traditional hard-disk-drive companies, such as Seagate and Western Digital; traditional network-equipment vendors, such as Cisco’s Linksys division, D-Link, and Netgear; and start-ups, such as Data Robotics. Hard-disk-drive companies are understandably more loath than companies in the other two categories to admit to the inevitable impermanence of drives. Also, is there a future NAS-supplier role for traditional consumer-electronics companies, such as Samsung or Sony?

All this talk about hard drives inevitably brings up the topic of the solid-state-drive alternative (Reference 5). These drives are increasingly becoming available in cost-effective capacities that make them compelling hard-disk alternatives for client computers. However, the bulk-storage nature of NAS makes it likely that it will continue as a hard-drive candidate at least for the next few years. Near-term pragmatism aside, increased flash-memory density and lower prices are indisputable trends, particularly since the advent of multilevel-cell-storage techniques. As such, solid-state drives’ increased reliability and performance, decreased power consumption and heat dissipation, and silent operation will likely in the future encourage their adoption in NAS at hard drives’ expense.

If you constrain your NAS brainstorming to only networked bulk storage, you might at first glance think that any of a number of operating systems could suffice. Dig a bit deeper, though, and you’ll quickly realize that it’s more difficult to solve this problem. First, a tangible percentage of your users will likely want to be able to carve up the available capacity into more than one shared-storage resource, with per-share access rights, such as disabled, read-only, or read/write, that customers will define on a per-user and -group basis. They’ll access the networked storage from LAN clients running various operating systems and therefore with various supported file-access protocols, such as AFP (Apple-filing protocol), NFS (network-file system), and SMB/CIFS (server-message block/common Internet-file system). They’ll also want both configuration and subsequent access to work in a way that doesn’t force them to comprehend and grapple with the underlying complexity.

LAN-client backup, another commonly requested NAS feature, is similarly challenging to implement in a simultaneously robust and trouble-free manner. Apple OS 10.5’s built-in Time Machine capability, for example, initially supports full backups and subsequently supports incremental backups to AFP-cognizant storage media. However, Apple officially sanctions backups only to its own Time Capsule hardware, which combines a router and a hard-disk drive (see sidebar “NAS adapters and alternatives”). Windows currently integrates no comparably robust backup features, although both Microsoft and third parties can subsequently augment the operating system with such capabilities. You also might want to include Rsync support for Unix clients. Keep in mind that users often want to back up files that the operating system or an application running on it is currently using. As a case study of the concept, although the Connector client-side software for the Windows Home Server NAS operating system generally runs well, it’s not without limitations and quirks. It automatically wakes up PCs once a day, even if they’re on standby at the time, but it sometimes fails to put them back to sleep once backup completes. Automatic wakeup also doesn’t work if Windows is running virtualized on another operating system (Reference 6).

Next consider the laundry list of other NAS capabilities that your potential customers might value and, therefore, pay extra for. These features include on-the-fly encryption during storage and subsequent decryption during read-back of information archived on the NAS, along with USB (Universal Serial Bus) ports for printer serving, augmented storage capacity, and networked access to scanners and other USB peripherals. Your customers might also want automatic network discovery through protocols such as UPnP (universal plug and play) and Apple’s Bonjour—that is, Zeroconf. Media streaming is also on the list. Protocols such as UPnP AV (audio/video) and DLNA (Digital Living Network Alliance) enable this feature both across the LAN and over a WAN (wide-area-network) connection. Firewall-surmounting technologies, such as UPnP and NAT-PMP (network-address-translation/port-mapping protocol), support the WAN connection.

Customers might also pay for additional file-access and update protocols, such as FTP (file-transfer protocol) and Bittorrent, including built-in servers for them. They might even want approaches such as Telnet and TFTP (trivial FTP). Dynamic DNS (domain-name-service) and NTP (network-time-protocol) support may also be on customers’ wish lists, along with a Web server, both for convenient user access to the NAS settings and for enabling the NAS to serve generic Web pages through both HTTP (hypertext transfer protocol) and HTTPS (HTTP-secure) over the LAN and WAN. Also consider iTunes, SqueezeCenter (formerly, SlimServer), and other media servers; iSCSI (Internet-small-computer-system-interface) support for optional SAN (storage-area-network) access; workgroup-tailored servers, such as DNS and e-mail, the latter complete with spam filtering; master-browser capabilities for Windows peer-to-peer workgroups; and direct attachment to OTA (over-the-air), cable, and satellite television tuners for both live-TV viewing and record-and-playback features using network extenders.

Although both open-source and proprietary software exists to implement these capabilities, each incremental concurrent task puts incremental demand on memory, processing, and other system resources. Incremental functions also threaten to exponentially increase the complexity of the perceived customer experience with the end result, along with the probability that functions will negatively interact with each other. With several of the NAS devices that I’ve tested over the years, multiple applications have insisted on using the same TCP (transmission-control-protocol) and UDP (user-datagram-protocol) ports, and other programs have blocked the NAS from putting its hard-disk drives in spin-down mode, thereby precluding consequent power-consumption reductions and operating-life extensions.

Speaking of operating life, warn your customers of pending problems with their NAS while the owners can still rectify the situation. For example, you can send automatic e-mails to inform users of high temperatures, which may indicate clogged or otherwise failing fans and vents, along with SMART (self-monitoring/analysis/reporting technology)-drive-diagnostic results that exceed predetermined thresholds. To get those e-mails to your customers, though, you also need to support spam-blocking safeguards that ISPs (Internet-service providers) now put in place. These potential roadblocks include nonstandard SMTP (simple-mail-transfer-protocol) ports, user-name and password authentication at the SMTP server, and SSL (secure-sockets-layer) capabilities.

Keep in mind, too, that you must support no-brainer updates to the NAS BIOS (basic input/output system) or EFI (extensible-firmware-interface) code, operating system, and applications, both to patch vulnerabilities and bugs and to upgrade features in the field. It would be naive to assume that your customers will remember to regularly search for, download, and install service packs. The built-in automatic Windows Update capability of Microsoft’s Windows Home Server is one notably robust implementation of the concept; Apple’s Time Capsules also regularly check for updates and alert users to their availability.

Innumerable factors drive your selection of a CPU architecture, the features within that architecture, and a performance option of that feature set, including the software suite’s demands, the system’s BOM (bill-of-materials)-cost expectations, and the availability of highly integrated and application-optimized IC variants. In addition, consider not only architecture-tailored software from your company but also that of third-party software you might want to license, along with additional utilities that your customers may want to install after the purchase. For example, many enthusiasts have developed freely downloadable add-ons for Windows Home Server on the We Got Served Web site.

Two examples highlight the divergent paths that companies have taken in this regard. First, look at Cisco’s Linksys division (Figure 1). The company in January 2007 introduced the NAS200, which employed RDC Semiconductor’s R3210 CPU, implementing the i486 microprocessor-instruction set. However, the NAS was so performance-strapped that it couldn’t support either SMTP-server authentication or SSL cognizance for e-mail alerts; it also could not use its USB port to implement a print server. Similarly, the company initially shipped the NAS200 with support for only the journaling-inclusive XFS (extended file system).

Journaling support is desirable in typical consumer environments, in which a UPS (uninterruptible-power supply) doesn’t feed the NAS, which can, therefore, abruptly shut down in the middle of a media write. But journaling and other advanced-file-system capabilities’ algorithm processing also steal CPU cycles. In response to user complaints about slow accesses, Linksys added optional support for nonjournaled ext2 (second extended file system) through a firmware upgrade. Marvell’s beefier ARM-based 88F5182 Orion SOC (system on chip) powers the newer Media Hub NAS line, which has substantially more capabilities than its NAS200 predecessor. Similarly, the latest iterations of Buffalo Technology’s LinkStation and TeraStation NAS products have started to use ARM processors; a mix of MIPS and PowerPC CPUs initially fueled these products.

Linksys migrated away from x86, but Netgear seems to be going in the opposite direction. The company in May 2007 acquired Infrant Technologies and its ReadyNAS product line. Infrant began life as a silicon supplier of the Leon SPARC-compatible CPU for NAS. For reasons that likely involved a dearth of stand-alone-IC sales to others, the company later switched gears and decided to become a system supplier selling Leon-based NAS. Netgear no longer manufactures the initial 600, X6, and NV product lines; Duo, NV+, and NVX systems continue to use Leon.

In late 2008, however, Netgear rolled out the ReadyNAS Pro, available in both enterprise- and consumer-targeted variants. ReadyNAS Pro leverages a dual-core Intel x86 CPU. It currently occupies the high end of the company’s product line, complete with six-drive support. Although Netgear doesn’t comment on future product plans, it’s not a stretch to imagine the company’s embrace of the x86 extending throughout the ReadyNAS line in the future (see sidebar “x86 enhancements”). As a longtime ReadyNAS X6 user, I’ve been frustrated at the long delays between the debut of new versions of PacketVideo’s TwonkyMedia DLNA server on conventional platforms and its availability on Leon-based hardware. Adopting a mainstream-CPU foundation would probably shorten those delays.