A Storage Framework for the Future Page 2


Want the latest storage insights?

Download the authoritative guide: Enterprise Data Storage 2018: Optimizing Your Storage Infrastructure

Continued From Page 1

RAID Could Become 'A Thing of the Past'

When you create a file under OSD, given the allocation policy that is allowed within the OSD file system, a certain amount of space is allocated. The file system passes the request to the object managers, and the object managers allocate and manage the available space. Each object manager could have its own policies for allocation. RAID as we know it would likely become a thing of the past.

What happens if you have a file system with a number of small files and a number of larger files within the same file system? In today's fixed block world, RAID-1 (mirroring) would likely be better for performance and access time for the small files, and RAID-5 (parity) would likely be better for performance, access time and space efficiency for the large files. The space efficiency is an important aspect of RAID-5 compared to RAID-1, since you have more drives being used for actual data space. For example, with RAID-5 4+1, you have 1 parity drive for every four data drives. Using RAID-1, you would have four mirrors for every data drive.

With RAID as we know it today, you cannot have both types of RAID dynamically allocated for a single file system. Some RAID vendors have attempted this, but to have successful dynamic RAID allocation, the file system and the RAID must be able to communicate, which is not possible with today's block-oriented storage. Today, a single RAID using both RAID-1 and RAID-5 cannot operate efficiently since the file system does not communicate with the storage.

However, with OSD, the object manager can be tuned to do the equivalent of RAID-1 for small files and RAID-5 for larger files, and dynamically allocate objects. All of the problems with space efficiency and performance are taken care of since the file system passes the file allocation information to the object managers.

If a file is opened to extend the end of a file that was initially small, the object manager could change the place the file was allocated and the policy of that file to allow it to be changed from the equivalent of RAID-1 to RAID-5, if that is the policy specified by the object manager. The ability to dynamically change the allocation of the file and the number of disks used for the file allows performance to change with file sizes. This is transparent to the file system, since all it passes is allocation policy for the file and data.

You could theoretically change what we now know as RAID level by just the size of the file. OSD would theoretically allow, if the user had the correct permissions, allocation of files across a specific number of disk drives to match bandwidth.


The current SCSI and POSIX standards don't provide nearly the same level of security that you can find with networking technology. To some degree, the reason is obvious, since storage was generally local and thus not an issue. That, of course, is changing rapidly.

As shared file systems become more widely used, the data could be local, or it could be remote, and you do not know if it is directly attached locally, directly attached over dark fiber with Fibre Channel, or possibly running from SAN to WAN.

OSD does not offer security nirvana, but the framework offers far more security than we currently have. The following is taken directly from the OSD standard document:

Threat thwarted by security method
OSD Security Methods

As you can see, the standard provides far greater security than standard file systems with even with ACLS (Access Control Lists), because with a file system, someone can still get to the data by reading the raw device, which is not very secure. Add to that the complexity of shared file systems and security issues between operating systems, and OSD provides a basic framework for security that could be implemented across operating system boundaries.

To me, the big feature OSD provides is not host security, but the security and authentication of every OSD device. That means that HBAs, RAID controllers and disks all must be OSD-compliant and authenticated. You cannot just pull a disk out and plug it in somewhere else, and if the data on the disk is encrypted, it provides far more security than we have today. If this encryption technology was applied to tapes, you could ship sensitive data via standard mail with no concerns for data security (damage in shipping is another matter, however).

Page 3: Now All We Need Are OSD Products

Submit a Comment


People are discussing this article with 0 comment(s)