If you walked by the Seagate booth at the recent Storage Networking World in Phoenix, you probably noticed as I did an interesting demo of object storage technology.

To a casual observer the demo was nothing too glamorous: a couple of IBM servers sending data to storage devices over Ethernet and, via an Emulex HBA, to an array of Seagate drives.

Well, to a casual observer Neil Armstrong's historical landing on the Moon was probably just a step like many others, but we know better.

Indeed, this not much rumored public display of object storage technology could mark the beginning of a significant leap forward for this industry.

At the booth I had the pleasure of meeting Erik Riedel from Seagate Research, who gave me a captivating update on object storage.

Riedel chairs with IBM's Julian Satran the Object-Based Storage Devices Technical Workgroup at SNIA, and has a privileged view of the state of this technology.

The concept behind object storage is rather simple: to give storage devices more control over basic features such as allocating sectors for a file. Obviously, in an object world the OS does not manage those activities anymore, which translates into increased transparency of a device data content across different OS’.

Although the smaller unit of data for disk drives is still (obviously) the sector, the minimum exchange unit between OS and object devices becomes, you guess it, an object.

For example, to store this article the operating system would pass the whole content as an object to the storage device, receiving in return an object ID to associate with its filename.

To retrieve the same article, the OS would find its filename in a directory, pass the associated ID along with a request to retrieve an object to the device, and grab the results.

If you are thinking that to accommodate object storage devices the set of SCSI commands needs to be expanded, you're absolutely right. But the impact of object storage could go much further.

Think of how many other activities besides space allocation an intelligent object device could manage independently from the OS. Consider for example, access control, encryption, replication, criteria-based data movement across devices ... the possibilities are nearly endless.

Perhaps the most immediate impact of object storage will be to finally settle the dispute between serving block and serving files. Of course, the winner will be serving files, or to be more accurate, serving objects.

Other possible implementations of the technology will probably be decided, as usual, by criteria of efficiency and cost. Regardless, object storage promises to be the greatest revolution since networked storage.

Joe Breher of lingua data responded to this:-

Thank you for your column inches on OSD. If I may expound a bit...

You stated that "If you are thinking that to accommodate object storage devices the set of SCSI commands needs to be expanded, you're absolutely right." While this is certainly a true statement, a reader may have the impression that there is no defined way to speak to an OSD over SCSI.

To the contrary, we in the SNIA's OSD Technical Working Group have written a specification for the SCSI Model and Command Set for OSD. This work was passed on to the INCITS T10 Technical Committee, which competed a letter ballot on the document. This is now a standard within INCITS, document number INCITS 400-2004, published since mid-2004.

The upshot of all this is that there is ratified SCSI spec for OSD that is a full peer to SBC-x (disks), SSC-x (tapes), etc. Work continues upon version 2.0 of the spec, which will lend additional functionality to the specification.

Concerning your statement "the winner will be serving files, or to be more accurate, serving objects" - I would like to point out that objects are potentially quite different from files. It is certainly true that one natural mapping from a host space to the object space is representing the data associated with a file as an object. Indeed, this is the initial thrust of lingua data's approach to OSD. (Note that the metadata of the file may be represented as attributes associated with the object within the OSD, as metadata maintained on the MetaData Server (MDS), or some combination thereof.)

However, other natural mappings spring to mind. One intuitive mapping is a 1:1 relationship between objects and records within a database. At least one company is looking at encapsulating an entire file system within each object.

In essence, I just wish to convey that there are more applications for OSD than a 1:1 mapping between files and objects. It will take some time for the industry to learn which of these other mappings may have wide applicability.

I would wholeheartedly agree with your observation that "object storage promises to be the greatest revolution since networked storage". While work remains to be done in order to implement the entire architecture in a standardized manner, OSD offers the best aspects of both NAS and SAN architectures, while leaving behind the shortcomings of either.

We are faced today with the unnatural situation of two predominant architectures for networked storage. When discussing architectures aimed at solving a given problem, two is an unnatural cardinality. A cardinality of one would indicate convergence on a solution. A cardinality of many would indicate there are really multiple problems in the space. However, we currently have two approaches - SAN and NAS. Why do we have two? In essence, SAN does some things better than NAS, and NAS some better than SAN.

SAN's primary drawbacks centre around data sharing. For any meaningful data sharing to occur, the clients must coordinate their access to shared data through communications with each other. This can happen in a limited fashion today - but only on certain client platforms. Native cross-platform shared data access is a distant wish.

NAS's primary drawbacks centre around performance. All data must pass through the server. The bandwidth of the server's bus becomes a bottleneck as the number of clients and/or the size of the served file set scale up.

Read part 2 of this feature here