See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/3199003

Object-based storage

Article  in  IEEE Communications Magazine · September 2003

DOI: 10.1109/MCOM.2003.1222722 · Source: IEEE Xplore

CITATIONS READS

293 509

3 authors, including:

Michael P. Mesnier
Intel
27 PUBLICATIONS   1,288 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Michael P. Mesnier on 02 February 2015.

The user has requested enhancement of the downloaded file.

 STORAGE AREA NETWORKING

Object-Based Storage
Mike Mesnier, Carnegie Mellon and Intel
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 operating system 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.e., 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.
trol (RAMAC) in 1956, However, creating such an intelligent device
STORAGE TODAY AND TRADE-OFFS
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 file system, has
recently been introduced in an attempt to cap-
IP network
ture the features of both NAS and SANs.
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-
Met Servers
monly referred to as metadata. For multiple adat
a
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
t
as clustered file systems and databases. Most en
gem
other infrastructures only allow hosts to share na
data indirectly through files by using NAS. Ma
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
System call interface System call interface
device is
accomplished File system, File system,
user component user component
through a rich
interface similar to
File system,
a file system. And, storage component
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-
Met
adat
a
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
the storage device will scale independently from
Data

Storage area network the number and types of clients in the system.
While an OSD does not question the authen-
nt
me ticity of the client, it does need some mechanism
age
n to validate the integrity of the capability, or
Ma
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- Hydra 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
INTELLIGENCE device, and can
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.
Researchers at the University of Wisconsin,
RELATED WORK 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
iMAX-432 Object Filing System,” ACM Symp. OS Princi-
Although intelligence as well. 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 Local Networks, Zurich, Switzerland, Aug. 1980.
Although block-based interfaces have enabled [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,
pp. 92–103.
storage devices the device interface. [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,
also high-performance, thereby eliminating the http://www.snia.org/osd
applications, we [12] IBM, Storage Tank, http://www.almaden.ibm.com
common trade-off between files and blocks. Fur- [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
Mellon Univ., Dec. 2001.
continued Object-based storage was designed to exploit [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,
include self-configuration, self-protection, self- CA, 05–09 Oct. 2002, published in OS Rev., vol. 36, no.
a change in the 5, 2002, pp. 264–76.
optimization, self-healing, and self-management.
device interface. Replacing block interfaces with objects is a
major step in this evolution. BIOGRAPHIES
MIKE MESNIER ([email protected]) is a storage archi-
ACKNOWLEDGMENTS 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
computer science from the University for Illinois, Urbana-
and Chenxi Wang (CMU) for her initial review. 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
Argonne National Laboratory.
of the arguments presented in this article were
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

View publication stats