A Storage Framework for the Future
In my previous column (Let's Bid Adieu to Block Devices and SCSI), I documented all the reasons why block device and SCSI technologies are ripe for replacement. The standard that I hope will replace those technologies is Object-Based Storage Devices (OSD), from T10.org. T10 is the same group that brought you SCSI, so if T10 is ready for a change, we should be too.
Of course, I could be totally wrong and OSD could become another standard like HiPPI, the High Performance Parallel Interface (here I'm showing both my age and my HPC roots). HiPPI never became popular in the early 1990s for a variety of reasons and is almost forgotten history. Will OSD become a popular standard or forgotten history?
The biggest issue with the current block-based storage framework, in my opinion, is the lack of communication between the file system and the physical storage, a problem compounded in shared file systems. This manifests itself in many ways, but the major impact is on storage performance and scalability.
Another area that has been a concern for a number of organizations and the storage community is storage security. OSD solves many of the security problems of the current framework. You might want to review Securing Data Across SANs, WANs, and Shared File Systems for some background on some of the current security issues that affect SANs.
Performance and Scalability
With the file-oriented OSD in the data path, information about each object is known at each level, and objects communicate to object managers through the data path — there is a framework to pass information that does not exist using standard SCSI.
If you create a file on a server running an OSD file system, by using standard UNIX open(2) system call or C Library fopen(2) call, that object is managed without any knowledge or intervention from the programmer.
On the host, the object looks and behaves just like files with today's UNIX and Windows file systems, but under the covers, the way the file system deals with the storage is completely different. One of the biggest differences is the process of allocation within the file system (see Storage Focus: File System Fragmentation for more about file system allocation).
With current file systems, the file system understands what space has been allocated and what space has not been allocated by looking at a map and allocating the actual data space from within that map. The representation of the allocation map can vary between file systems.
With OSD, allocation works completely differently. The file system queries the object manager or managers associated with that file system. Those managers could reside on different disk drives or different object manager controllers (what we now call RAID controllers), or a combination of both. The object managers provide the file system with information on how much space is available. The file system keeps track of the total space available, but not the specific allocations and location of any of the space for a file.