STORAGE AREA NETWORKING

Object-Based Storage

Mike Mesnier, Carnegie Mellon and Gregory R. Ganger, Carnegie Mellon Erik Riedel, Seagate Research

ABSTRACT A storage object is a logical collection of bytes on a storage device, with well-known meth- Storage technology has enjoyed considerable ods for access, attributes describing characteris- growth since the first disk drive was introduced tics of the data, and security policies that prevent nearly 50 years ago, in part facilitated by the unauthorized access. Unlike blocks, objects are slow and steady evolution of storage interfaces of variable size and can be used to store entire (SCSI and ATA/IDE). The stability of these data structures, such as files, database tables, interfaces has allowed continual advances in medical images, or multimedia. both storage devices and applications, without Objects can be regarded as the convergence frequent changes to the standards. However, the of two technologies: files and blocks. Files pro- interface ultimately determines the functionality vide user applications with a higher-level storage supported by the devices, and current interfaces abstraction that enables secure data sharing are holding system designers back. Storage tech- across different platforms, but nology has progressed to the point that a change often at the cost of limited performance due to in the device interface is needed. Object-based file server contention. Blocks offer fast, scalable storage is an emerging standard designed to access to shared data; but without a file server to address this problem. In this article we describe authorize the I/O and maintain the metadata, object-based storage, stressing how it improves this direct access comes at the cost of limited data sharing, security, and device intelligence. security and data sharing. We also discuss some industry applications of Objects can provide the advantages of both object-based storage and academic research files and blocks. Like blocks, objects are a primi- using objects as a foundation for building even tive unit of storage that can be directly accessed more intelligent storage systems. on a storage device (i.., without going through a server); this direct access offers performance INTRODUCTION advantages similar to blocks. Like files, objects are accessed using an interface that abstracts Industry has begun to place pressure on the storage applications from the metadata neces- interface to storage, demanding that it do more. sary to store the object, thus making the object Since the first disk drive in 1956,1 disks have easily accessible across different platforms. Pro- grown by over six orders of magnitude in density viding direct, file-like access to storage devices is and over four orders in performance, yet the therefore the key contribution of object-based storage interface (i.e., blocks) has remained storage. largely unchanged. Although the stability of the The remainder of this article is organized as block-based interfaces of SCSI and ATA/IDE follows. We discuss today’s prominent storage has benefited systems, it is now becoming a lim- architectures, the trade-offs involved, and the iting factor for many storage architectures. As fundamental limitations of block-based inter- storage infrastructures increase in both size and faces. We describe object-based storage as an complexity, the functions system designers want architecture that will remove these limitations. to perform are fundamentally limited by the We conclude with a discussion of the industry block interface. activity around object-based storage, in particu- Recent industry and academic research sug- lar the standards efforts in the Storage Network- gests a shift in storage technology, in which ing Industry Association (SNIA) and the flurry 1 IBM introduced the devices evolve from relatively unintelligent and of activity around object-based file systems. Random Access Method externally managed to intelligent, self-managed, for Accounting and Con- and aware of the storage applications they serve. TORAGE ODAY AND RADE OFFS trol (RAMAC) in 1956, However, creating such an intelligent device S T T - with a density 2000 b/in2 requires a more expressive interface. Many in An ideal storage architecture would provide and throughput of 8 the industry believe that an interface based on strong security, data sharing across platforms kbytes/s. storage objects can be the answer. (i.e., operating systems), high performance, and

84 0163-6804/03/$17.00 © 2003 IEEE IEEE Communications Magazine • August 2003 scalability in terms of the number of devices and clients. Today’s architectures force system designers to decide which of these features is most important, as choosing an architecture Clients involves a trade-off. The three storage architec-

tures in common use today are direct-attached File I/O storage (DAS), storage area networks (SANs), and network-attached storage (NAS). A fourth architecture, often called a SAN , has recently been introduced in an attempt to cap- ture the features of both NAS and SANs. IP network DAS connects block-based storage devices directly to the I/O bus of a host machine (e.g., via SCSI or ATA/IDE). While DAS offers high Storage area network performance and minimal security concerns, Block I/O there are limits on connectivity. SCSI, for exam- ple, is limited by the width of the bus (a 16-bit bus can have at most 16 hosts or devices). To File server address the connectivity limits of DAS , and con- sequently enable the consolidation and sharing Block storage of storage devices, the SAN was introduced. A SAN is a switched fabric that provides a fast, Figure 1. This figure illustrates NAS being used to share files among a num- scalable interconnect for large numbers of hosts ber of clients. The files themselves may be stored on a fast SAN. However, and storage devices. With this added connectivi- because the clients often suffer from queuing delays at the server, they rarely ty, however, came the need for better security. see the full performance of the SAN. SANs therefore introduced concepts such as zoning (like a virtual private network) and host- device authentication to keep the fabric secure. DAS and SAN are both block-based. The storage application (e.g., file system) is responsi- Clients ble for mapping its data structures (files and directories) to blocks on the storage devices. The extra data required to do this mapping is com- monly referred to as metadata. For multiple Metadata Servers hosts to share data blocks, they must also share metadata, and do so in a manner that guarantees metadata consistency among the hosts. The com- plexity of this process has resulted in block shar- Data ing only among tightly coupled Storage area network performance-sensitive storage applications such as clustered file systems and databases. Most other infrastructures only allow hosts to share data indirectly through files by using NAS. Management NAS is just another name for file serving, which was introduced to enable data sharing across platforms. With NAS, the metadata describing how files are stored on devices is managed completely on the file server. This level of indirection enables cross-platform data shar- Block-based storage devices ing but comes at the cost of directing all I/O through the single file server. NAS may be Figure 2. This figure illustrates a SAN file system being used to share files implemented on top of a SAN or with DAS, the among a number of clients. The files themselves are stored on a fast storage former often referred to as a NAS head. In either area network (e.g., iSCSI) to which the clients are also attached. File server case, clients will be limited by the performance queuing delays are avoided by having the file server share metadata with the of the file server and will rarely see the aggre- clients who can directly access the storage devices; but, because the devices gate performance of the storage devices (Fig. 1). cannot authorize I/O, the file server must assume that the clients are trusted. To address the performance limitations of NAS, SAN file systems have recently appeared. In a SAN file system, the file server and clients the device. A SAN file system is illustrated in are all connected to a SAN on which the file sys- Fig. 2. tem is stored. Given this connectivity, the file The trade-off in today’s architectures is there- server can share file metadata with the clients, fore security and cross-platform data sharing thus allowing the clients to directly access the (files) vs. high performance (blocks). While files storage devices. Examples include EMC’s High- allow one to securely share data between sys- Road, IBM’s StorageTank, and Veritas’ SAN- tems, the overhead imposed by a file server can Point Direct. Because the devices have no limit performance. Yet, increasing file serving mechanism for authorizing I/O, increasing file performance by allowing direct client access serving performance in this manner reduces comes at the cost of security. Building a scalable, security; the SAN mechanisms for device securi- high-performance, cross-platform, secure data ty only protect the entire device, not data within sharing architecture requires a new interface

IEEE Communications Magazine • August 2003 85 Unlike block I/O, creating objects Applications Applications on a storage device is System call interface System call interface accomplished File system, File system, user component user component through a rich interface similar to File system, storage component a file system. And, Object interface because objects can grow and Block interface File system, shrink dynamically, storage component Block I/O manager the storage device Block I/O manager is responsible for all internal space management of Storage device Storage device the object. (a) Traditional model (b) OSD model

Figure 3. Offloading of storage management from the file system.

that provides both the direct access nature of data stored in an object is opaque to the object- SANs and the data sharing and security capabili- based storage device and is simply stored in the ties of NAS. data portion of the object. The user-accessible attributes describe characteristics of the object, OBJECT-BASED STORAGE some of which will be opaque and others not. For example, a quality of service (QoS) attribute OVERVIEW may describe latency and throughput require- Objects are storage containers with a file-like ments for a multimedia object. Lastly, the device- interface, effectively representing a convergence managed metadata is any extra information (e.g., of the NAS and SAN architectures. Objects cap- an inode) maintained by the storage device for ture the benefits of both NAS (high-level the purposes of managing the physical storage of abstraction that enables cross-platform data the object. sharing as well as policy-based security) and We refer to a device that stores objects as an SAN (direct access and scalability of a switched object-based storage device (OSD). OSDs can fabric of devices). Although objects do behave come in many forms, ranging from a single disk like files in terms of space allocation and data drive to a storage controller with an array of access, they are only intended to serve as con- drives. OSDs are not limited to random access tainers for storage applications (e.g., file systems or even writeable devices; tape drives and optical and databases), which implement any desired media could also be used to store objects. The additional interfaces (e.g., locking) and lookup difference between an OSD and a block-based mechanisms (e.g., directories). device is the interface, not the physical media. An object is variable-length and can be used The most immediate effect of object-based to store any type of data, such as files, database storage is the offloading of space management records, medical images, or multimedia. A single (i.e., allocation and tracking of used and free object could even be used to store an entire file blocks) from storage applications. To illustrate system or database. The storage application this offloading, consider the traditional file sys- decides what gets stored in an object. Unlike tem architecture (Fig. 3a). Block-based file sys- block I/O, creating objects on a storage device is tems can roughly be divided into two sections: a accomplished through a rich interface similar to user component and a storage component. The a file system. And, because objects can grow and user component is responsible for presenting shrink dynamically, the storage device is respon- user applications with logical data structures, sible for all internal space management of the such as files and directories, and an interface for object (i.e., the storage device maintains the accessing these data structures; and the storage allocation and free-space metadata structures, component maps the data structures to the phys- such as UNIX index nodes, or inodes, and free- ical storage. This separation of responsibilities block bitmaps). makes it easy to offload management to the stor- Objects are composed of data, user-accessible age device, which is the intended effect of object- attributes, and device-managed metadata. The based storage. In Fig. 3b, the user component of

86 IEEE Communications Magazine • August 2003 the file system is unchanged, the storage man- OS components (Fig. 3) will facilitate the agement component offloaded (and therefore change. In particular, object-based file systems The interface to the metadata) to the storage device, and the will be relatively straightforward to implement (a device interface changed from blocks to objects. file system need only give up control over block object-based The management of block metadata (the management), and an OS’s I/O subsystem can be storage is very storage component in Fig. 3a) is completely introduced to objects by virtue of a new class determined by the storage application (e.g., file driver, similar to those that already exist for disk similar to that of systems have unique ways of laying out data and and tape. Reference code from Intel Labs shows maintaining on-disk metadata structures). These how both can be done in Linux [1]. a file system. dependencies make directly sharing data blocks The remainder of this section describes the Objects can be between hosts difficult, as a priori knowledge of object-based storage architecture in greater both the metadata structures and on-disk layout depth, particularly the interface to an OSD, the created or is necessary before accessing the storage device. attributes associated with an object, the security deleted, read or Furthermore, sharing the devices requires spe- architecture used for object-based storage, and cial coordination among the hosts in order to some opportunities objects present for more written, and even distribute the tasks associated with space alloca- intelligent storage devices. tion (e.g., by sharing a free-block bitmap). In queried for certain offloading metadata to the storage device, DATA SHARING attributes — just objects remove the dependency between the The improved data sharing of objects is a result metadata and storage application, making data of both the higher-level interface and the like files are sharing between different storage applications attributes describing the data being stored. today. feasible. Even more, cluster scalability improves considerably when the hosts no longer need to Interface — The interface to object-based stor- coordinate metadata updates. age is very similar to that of a file system. Objects Storage applications may still maintain their can be created or deleted, read or written, and own indexing information (e.g., directory meta- even queried for certain attributes — just like data) to resolve an object id from a higher-level files are today. File interfaces have proven easy name. But, given this id, the object can then be to understand, straightforward to standardize accessed in a platform-independent manner. (e.g., CIFS, NFS), and therefore possible to This makes sharing data considerably easier. For share between different platforms. example, a backup application could be handed The interface can also be easily extended with a list of object ids, allowing for a more efficient application-specific methods for manipulating physical backup of the device. data within an object, a technique referred to as Furthermore, with all metadata offloaded, active disks [2]. For example, a database filter storage applications can now store their struc- could be associated with an object, the output of tures as single objects as opposed to collections which could be returned on subsequent read of blocks. And, because the device can treat operations. Furthermore, an OSD could allow objects individually, it is easy to set security poli- storage applications to establish sessions with the cies on a per-object basis, similar to the manner device to encapsulate application-specific param- in which files can be protected by a file server. eters such as QoS or security guarantees. In Objects allow storage applications to set flexible short, objects introduce a mechanism in the stor- security policies that will result in authorization age device that allows the device treat storage for an entire device, a collection of objects on applications, and even clients, individually. the device, a single object, or even bytes within an object. Attributes — Attributes improve data sharing The immediate benefits of object-based stor- by allowing storage applications to share a com- age are therefore cross-platform data sharing mon set of information describing the data (e.g., and application-level security. These benefits are access times). They are also the key to giving most relevant for SAN-based storage devices storage devices an awareness of how objects are and would be of limited value for DAS-based being accessed. storage, which is already under the protection In most deployments, attributes will at least and management of a single host. An additional contain information analogous to that contained benefit results from the devices managing the in an index node (inode), the primary data struc- physical layout of the data, as new opportunities ture used in many UNIX file systems. An inode arise within the storage device for self-manage- contains file attributes such as access time, size, ment. Self-management benefits both DAS and and group and user information, all of which can SAN devices equally, and includes actions such be efficiently stored with the object data and, in as reorganizing data to improve performance, certain cases, interpreted by the storage device. scheduling regular backups, and recovering from For example, a write operation that updates the failures. For example, file-level prefetching with- size attribute would be reflected on subsequent in a block-based device is precluded by the fact attribute requests, making the update visible to that the device does not know about files. In other storage applications accessing the object. contrast, an object-based device could easily Clustered applications could therefore depend prefetch files (stored as objects) on behalf of on the storage device to maintain this metadata, storage applications, or organize files according rather than delegate this responsibility to an in- to the order in which they are mostly commonly band (i.e., on the data path) metadata server accessed. that may hinder performance. Operating systems must support objects if Beyond these file-like attributes, additional they are to be widely adopted. Fortunately, the information can be made available such as likely clean separation between the user and storage patterns of access to the object (e.g., sequentially

IEEE Communications Magazine • August 2003 87 age device, and it is the job of the storage device to validate the integrity of the capability to Clients ensure that neither it nor the request has been modified. The OSD therefore provides only the mechanism for enforcing security, rather than Managers the policy, which is set by the storage applica- Metadata tion. Separating policy from mechanism is key to building a scalable security architecture. In par- ticular, not having to maintain client-specific authentication information on the device means

Data the storage device will scale independently from Storage area network the number and types of clients in the system. While an OSD does not question the authen- ticity of the client, it does need some mechanism Management to validate the integrity of the capability, or proof that the object manager granted access to the client. Providing this guarantee requires that Secret the object manager and device share a secret that can be used in creating a secure hash of the contents of the capability. Before granting a Object-based storage devices Cap. client its capability, the manager will first create a keyed hash of the capability, using the secret as Figure 4. The object-based storage security architecture. Object managers the key. It will then return both the secure hash, grant capabilities to clients; clients present these capabilities to the devices on referred to as a capability key, amf the capability every I/O. Secrets shared between the manager and the storage devices are to the client. The client is expected to use this used to generate a keyed hash of the capability, thereby protecting it from capability key in creating its own keyed hash of modification. every request sent to the OSD. This hash pro- tects the command from undetected modifica- tion, similar to how the hash of the capability protects the capability from modification. or randomly accessed), or even relationships to The request sent to an OSD includes the other objects. For example, multimedia files on a command, the client capability, and a signature storage device may have similar attributes that (or digest) of the entire request. Upon receipt of will cause them to be organized and efficiently a new request, the OSD must first validate the managed as a group. client digest. The OSD will create its own digest of the request and compare this with the digest SECURITY sent by the client.2 If they match, the OSD is Security is perhaps the single most important fea- guaranteed that neither the capability nor any of ture of object-based storage that distinguishes it the arguments in the request were modified. from block-based storage. Although security does Had either of these changed, the digest generat- exist at the device and fabric level for SANs (e.g., ed by the OSD would differ from that sent by devices may require a secure login and switches the client, and the OSD would reject the request; may implement zoning), objects make it possible all responses sent from the OSD to the client to partition large devices or fabrics into multiple can be protected using a digest similar to that security domains whose access policies are indi- sent by the client. vidually determined by the storage applications. In some environments, object-based storage In the object-based security architecture [3], must also ensure the privacy of data transfers every access is authorized, and the authorization and guard against delay and replay attacks. In is done without communicating with a central the absence of a trusted channel (e.g., IPSec), authority that may slow the data path (Fig. 4). the object-based storage security architecture The storage application in Fig. 4 could be a allows the capability key to be used as an encryp- file server that stores each file as an individual tion key, thereby safeguarding the client and 2 It is not immediately object on a storage device. This architecture is storage devices from snooping attacks. Delay obvious how this is possi- identical to the SAN file system shown in Fig. 2, and replay attacks are prevented by adding client ble when the storage with one important distinction: the clients no timestamps and sequence numbers to each I/O, device does not possess longer have to be trusted, nor does the network. respectively. The timestamp will establish a small the capability key used to This means that the clients and storage devices window in which the command is valid. If the generate the digest. How- can be anywhere on the network, without the command is received by the storage device out- ever, recall that the capa- risk of unauthorized clients accessing the stor- side of this window, it will not be authorized. bility key is just a hash of age, or authorized clients accessing the storage Similarly, the storage device can check the the client’s capability in an unauthorized manner. sequence number of each command and reject (which was sent in the The fundamental building block in an object- those that have already been executed. request), and the secret based security system is a cryptographically To avoid a trip to the object manager on shared between the object strong capability that contains a tamper-proof every I/O, clients may cache and reuse capabili- manager and the OSD. description of the rights of a client. This capabil- ties. The object manager revokes cached capabil- Thus, the OSD can simply ity represents the security policy, and is created ities by embedding expiration times in the regenerate the capability out-of-band (i.e., off the main data path) by an capability or establishing a new secret with the key and use this key to object manager that manages the storage devices storage device. generate its digest of the and grants access to clients. While in possession Although the object manager has been taken request. of this capability, the client can access the stor- off the data path, it is still a single point of fail-

88 IEEE Communications Magazine • August 2003 ure or attack. If the object manager is compro- OS from Carnegie Mellon [6] and the mised, the system is compromised. Clustering iMAX-432 OS from Intel [7]. These operating With objects, can be used to improve availability, but at the systems used variable-size objects on disk to expense of more attack points. These issues are store not just files, but all pageable entities storage devices not endemic to object-based storage, and are within an OS, including process state, instruc- can understand identical to what traditional file servers struggle tions, and data. Although these operations sys- with today. The goal of object-based storage is tems never took off, they were instrumental in some of the not to improve the availability of file servers but establishing the fundamentals of capability- rather to improve the performance and scalabili- based security. relationships ty of the entire system by taking the servers off The SWALLOW project (circa 1980) from between the the main data path and allowing secure direct Massachusetts Institute of Technology [8] was access to the storage devices. among the first systems to implement a distribut- blocks on the ed object store, and was a precursor to early file device, and can INTELLIGENCE serving architectures. With the emergence of object-based storage The seminal work on object-based storage use this comes the potential for storage devices to active- occurred at Carnegie Mellon University’s Par- ly learn important characteristics of the environ- allel Data Lab (PDL) with the Network- information to ments in which they operate. Storage devices Attached Secure Disks (NASD) project [9]. better organize today are largely unaware of the users and stor- The architecture focused on cost-effectively age applications actually using the storage, adding processing power to individual disks, the data and because block-based storage devices manage specifically for networking, security, and basic anticipate needs. opaque data blocks. With objects, storage devices space management functionality. This research can understand some of the relationships led to a larger industry-sponsored project between the blocks on the device, and can use under the auspices of the National Storage this information to better organize the data and Industry Consortium (NSIC). Several storage anticipate needs. companies joined the collaboration, and NASD Object attributes can contain static informa- was generalized to network-attached storage tion about the object (e.g., creation time), devices, where individual drives, array con- dynamic information that is updated on each trollers, and appliances could take advantage access (e.g., last access time), information specif- of the interface change. This work yielded a ic to a storage application and uninterpreted by standard extension to the SCSI protocol for the device (e.g., filename, group, or user ids), object-based storage [10]. and information specific to a current user (e.g., The NSIC draft continues to be defined in QoS agreement). Attributes may also contain the Object-Based Storage Devices working group hints about the object’s behavior such as the of the Storage Networking Industry Association expected read/write ratio, the most likely pat- (SNIA) [11]. The SNIA plans to submit a com- terns of access (e.g., sequential or random), or pleted SCSI draft standard to T10 in 2003, and the expected lifetime of the object. Having is also exploring mappings to transports other access to such attributes enables a storage sys- than SCSI, including direct mappings onto IP. tem to better organize and serve the data. Even as standards develop, the industry is Using objects to better manage storage is an already implementing systems using object-based active area of academic research. One of the storage technology. IBM is exploring object- largest questions to be addressed relates to the based storage for their next generation of Stor- attributes themselves, specifically which ageTank [12]; the National Laboratories and attributes are most useful in classifying the Hewlett-Packard are building the highly scalable behavior of objects. Past research has already Lustre file system [13], with object-based storage shown that file attributes play an integral role in as their basic storage interface; and smaller com- determining file behavior [4, 5]. For example, panies and startups (BlueArc, Data Direct, and the name of a file can be used to predict how Panasas) are building devices that make use of the file may be accessed. Parallels exist for object-based storage. The Venti project at Bell object-based storage. Laboratories and Centera from EMC have also In general, objects enable attribute-based used object-based storage concepts to implement learning environments in which storage devices write-once media for the archival of reference can become aware of the environments in which data. Both systems employ the concept of con- they operate, and thereby better allocate and tent addressable storage (CAS) in which the id of provision resources. Furthermore, with increased an object (Venti actually uses a variable length knowledge of storage and user applications, stor- block) is a unique hash of the data con-tents. age devices can perform application-specific Intelligent storage is a hot area of academic functions, thereby making the SAN a computa- research. Carnegie Mellon’s PDL continues to tional resource. Indeed, storage devices are explore the use of more expressive interfaces themselves computers, with processors, network between host operating systems and storage connections, and memory. Through more expres- devices [2, 14]. As one such interface, objects sive interfaces, these resources can be more enable information exchange between the device effectively exploited. and the OS in order to achieve better functional- ity and performance in the storage system. ELATED ORK Researchers at the University of Wisconsin, R W Madison are exploring an alternative path, Primitive forms of object-based storage can be semantically smart disk systems that attempt to found in the early work (circa 1980) on object- learn file system structures behind existing block- oriented operating systems, including the based interfaces [15]. Many other research

IEEE Communications Magazine • August 2003 89 groups are beginning to explore storage-level [7] F. J. Pollack, K. C. Kahn, and R. M. Wilkinson, “The intelligence as well. iMAX-432 Object Filing System,” ACM Symp. OS Princi- Although ples, Asilomar, CA, published in OS Rev., vol. 15, no. 5, Dec. 1981, pp. 137–47. block-based [8] D. P. Reed and L. Svobodova, “SWALLOW: A Distributed SUMMARY Data Storage System for a Local Network,” Int’l. Wksp. interfaces have Although block-based interfaces have enabled Local Networks, Zurich, Switzerland, Aug. 1980. [9] G. A. Gibson et al., “A Cost-effective, High-bandwidth enabled significant significant advances in both storage devices and Storage Architecture,” Architectural Support for Prog. storage applications, we are now at a point Languages and OS, San Jose, CA, 3–7 Oct. 1998, pub- advances both in where continued progress requires a change in lished in SIGPLAN Notices, vol. 33, no. 11, Nov. 1998, the device interface. pp. 92–103. storage devices [10] R. Weber, “Object-Based Storage Devices (OSD),” The object interface offers storage that is http://www.t10.org and storage secure and easy to share across platforms, but [11] SNIA, Object-Based Storage Devices (OSD) workgroup, http://www.snia.org/osd applications, we also high-performance, thereby eliminating the common trade-off between files and blocks. Fur- [12] IBM, Storage Tank, http://www.almaden.ibm.com [13] P. Braam, The Lustre Project, http://projects.clusterfs. are now at a thermore, objects provide the storage device com/lustre with an awareness of the storage application and [14] G. R. Ganger, “Blurring the Line Between OSs and point where enable more intelligence in the device. Storage Devices,” Tech. rep. CMU-CS-01-166, Carnegie Object-based storage was designed to exploit Mellon Univ., Dec. 2001. continued [15] M. Sivathanu, A. C. Arpaci-Dusseau, and R. H. Arpaci- the increasing capabilities of storage devices. Dusseau, “Evolving RPC for Active Storage,” Architec- progress requires Characteristics of the future storage device may tural Support for Prog. Languages and OS, San Jose, CA, 05–09 Oct. 2002, published in OS Rev., vol. 36, no. a change in the include self-configuration, self-protection, self- optimization, self-healing, and self-management. 5, 2002, pp. 264–76. device interface. Replacing block interfaces with objects is a major step in this evolution. BIOGRAPHIES ACKNOWLEDGMENTS MIKE MESNIER ([email protected]) is a storage archi- tect with Intel Labs, a Ph.D. researcher at Carnegie Mellon The authors would like to thank the IEEE University, and co-chair of the Object-Based Storage reviewers for their comments and suggestions, Devices workgroup of SNIA. He received his Master’s in and Chenxi Wang (CMU) for her initial review. computer science from the University for Illinois, Urbana- Champaign, and has been with Intel since 1997. His cur- We would also like to thank the members of the rent activities include file systems and storage technologies, SNIA OSD technical work group for their regu- in particular intelligent storage devices. Prior to joining lar meetings and conference calls in which many Intel, he was a research scientist on the NEOS project at of the arguments presented in this article were Argonne National Laboratory. formed. GREG GANGER [M] ([email protected]) is director of the CMU Parallel Data Lab (PDL), academia's premier storage REFERENCES systems research center, and an associate professor in the ECE department at Carnegie Mellon University. He has [1] Intel, Internet SCSI (iSCSI) Reference Implementation, broad research interests in computer systems, including http://www.intel.com/labs/storage storage systems, operating systems, security, networking, [2] E. Riedel, G. Gibson, and C. Faloutsos, “Active Storage and distributed systems. He received his Ph.D. in computer for Large-Scale Data Mining and Multimedia Applica- science and engineering from the University of Michigan. tions,” Int’l. Conf. Very Large DBs, New York, NY, Aug. He is a member of the ACM. 24–27, 1998, pp. 62–73. [3] H. Gobioff, “Security for a High Performance Commodi- ERIK RIEDEL ([email protected]) leads the Interfaces ty Storage Subsystem.” Ph.D. thesis, TR CMU-CS-99- and Architecture Department at Seagate Research, Pitts- 160. Carnegie-Mellon Univ., July 1999. burgh, Pennsylvania. His group focuses on novel storage [4] D. Ellard et al., “Passive NFS Tracing of An Email and systems with increased intelligence for optimized perfor- Research Workload,” Conf. File and Storage Tech., San mance, automated management, and content-specific opti- Francisco, CA, Mar. 31–Apr. 2, 2003, pp. 203–17. mizations. Before joining Seagate Research, he was a [5] D. Roselli, J. R. Lorch, and T. E. Anderson, “A Compari- researcher at Hewlett-Packard Laboratories. He received his son of File System Workloads,” USENIX Annual Tech. Ph.D. in computer engineering from Carnegie Mellon Uni- Conf., San Diego, CA, June 18–23, 2000, pp. 41–54. versity for his work on Active Disks, an extension to NASD. [6] G. Almes and G. Robertson, “An Extensible File System His interests include I/O in a number of areas, including for HY-DRA,” 3rd Int’l. Conf. Software Eng., Atlanta, parallel applications, data mining, databases, file systems, GA, May 1978. and scientific data processing.

90 IEEE Communications Magazine • August 2003