A multi-tiered storage system can be implemented at various levels:
As an application This is the most flexible approach as the user application has complete control over data management. Applications like database servers are good candidates. In a file system environment that supports Data Management API (DMAPI) [#!bib:dmapi!#], an application can keep track of access patterns of files and implement a multi-tier storage. HSM implementations using DMAPI already exist.
Inside the file system Less flexible than the former, but may provide better performance than the former due to lower context switch overhead.
As a layered device driver (our approach) The device driver is layered on top of block storage media (generally disks). A given I/O request is divided into separate I/O requests each of which is issued to the device drivers of the underlying storage media it is configured to use. Our design currently has 3 tiers: declustered RAID1, RAID5 and compressed RAID5 (cRAID5), with future extensions for additional tiers like NVRAM. The data is migrated between the tiers depending on access patterns, so as to keep frequently accessed (hot) data in RAID1 tier and not so frequently accessed (cold) data in RAID5/cRAID5.
In the controller HP AutoRAID is a two-tier RAID storage array that uses RAID1 and RAID5. It is implemented at the controller level communicating with the host over the system bus. SCSI disks are connected to this controller through the controller's internal SCSI bus.