OSD: The Future of Storage

Information Management Journal, Jan/Feb 2005 by Straub, Joe, Samarra, Kenneth

Once networks arrived on the scene in the late 1980s, a new type of storage emerged: network attached storage (NAS). Here, a network existed between the host computer and the file system (see Figure 2). NAS hid the block-based nature of storage communication and allowed access on a file level. With NAS, all access was to individual files instead of to blocks within a file as was the case in the older DAS design. Unfortunately, because NAS tended to decentralize storage, device and request management became a nightmare. Frequent requests to the same device by different users presented fundamental problems of device request conflicts and slowness.

Out of this predicament emerged SAN (storage area networks) in the mid-1990s. SAN re-centralized storage using state-of-the-art fiber optics. SAN places the network between the file system storage component and the storage device itself (see Figure 2). This placement mitigates most device request conflicts and all information is sent via disk sectors. But the SAN approach uses block-based methods to store the data and logical block addressing (LBA) to fulfill requests.

The storage virtualization of SAN was intended to fix the diversity of problems that occur when disparate devices are simultaneously accessed by multiple users. It was a prime example of how marketing hype can surpass the real benefits of a product. Virtualization failed because it was based on an outdated storage design that has existed since the dawn of the computer revolution: block-based protocols. To date, users have not been able to construct a truly heterogeneous SAN because there is no standard file system format across computer platforms. For example, MS Windows file system format is different than that of Sun Solaris.

Future Tense

The best place to insert the network for modern storage systems is between the file system and the OSD storage component (see Figure 2) (a version of the file system storage component). The interface here is thin, meaning that it does not have a large command set. The significance is that the file system storage component has been moved out of the host computer's operating system and into the storage device itself where it can be most effective. File systems are currently implemented differently across various platforms (e.g., Microsoft Windows vs. Sun Solaris). OSD enables cross-platform compatibility, a sort of universal file system. With low-level storage management routines moved into the storage device itself, greater interoperability is achieved and a true heterogeneous architecture is possible.

OSD enables a high-performance solution, as there are no potential bottlenecks in the system between the hosts and the storage devices. For IT storage expansion, OSD gets around the problem of having to back up all the data, add more space, and then restore the data - a process that can easily take hours for terabytes of data.

OSD can accomplish all this with intelligent drives. Storage devices have had on-board microprocessors for years. However, this power has been significantly underutilized. By using that latent computing power to provide intelligence to the drives themselves, the OSD model separates the file system storage component from the host computer's operating system by moving it onto the storage device (see Figure 2).