An application based approach would only improve that particular application while a file system based approach does not help configurations that use a block device directly such as a database configured to use raw devices.
There are both benefits and costs in either the controller (often called hardware RAID) or device driver (software RAID) approach. We briefly discuss them here (for a more detailed comparison, see [#!bib:veritas-hwswraid!#]):
Benefits of a Controller Based Approach
Lower I/O bus traffic As the host issues a logical I/O to the controller, the I/O bus will see much less traffic compared to a software approach. For instance, a mirrored configuration of software RAID will issue two separate I/Os, one for each copy.
Separate Hardware A controller approach uses a separate on-board processor to process I/O requests, thus not loading the host processor. In parity based configurations like RAID5, this can save the host some computing, but with very fast server processors nowadays, this is a minor issue. In addition, controllers may have on-board NVRAM to improve write performance. But all these add to the cost of the system.
Benefits of Device Driver Approach
Host processors easier to upgrade The problem of increased I/O bus traffic and load on the host processor need not always be that serious. Host processors are generally far more faster and are easier to upgrade than the ones used in controllers.
Controller level redundancy In controller based approaches, redundancy is provided against disk failures but providing redundancy for other hardware such as controller hardware, can increase the cost. In software based configurations this can easily be provided by connecting disks across different controllers. Also, this can lead to better performance as the load is distributed across multiple controllers.
Flexibility A controller based approach has limitations on the number of disks that it can manage. Once that limit is reached, any new disks have to go under another controller and so cannot be accessed by the former. Also, configuration flexibility is limited. A software approach can be easily customized for a new access pattern. As we shall show in the section on implementation, the mechanisms and policies can be cleanly separated in a software approach.
A device driver approach is much simpler from an infrastructural viewpoint and it is increasingly becoming important commercially as many vendors are now providing such solutions for managing multiple disks (Veritas VxVM, IBM & HP LVM, SGI XLV). Hence we have investigated the device driver approach. Implementing at the controller level was not considered seriously due to the difficulty of carrying out modifications at this level, lack of information, and also the time and cost involved in developing the skills and the cost of implementation in a university laboratory environment.
In section 2 we discuss related work. Section 3 explains the design. Section 4 covers the implementation, with specific details on the changes for Linux from our initial Solaris prototype. Performance study for the Solaris platform is presented in section 5. Section 6 draws conclusions and spells out further work.