Check out the new USENIX Web site. next up previous
Next: Previous Work Up: Design, Implementation and Policy Previous: Abstract

Introduction

With massive computerization and falling price of storage devices, the focus has shifted from simple data storage towards fault-tolerant, efficient and easily manageable storage devices. The increasing importance of highly available web servers, database servers and data mining is another need for such devices.

Consider a typical web server storing some public domain information, like software, music etc. Naturally, the information on the web server will not be equally popular, and hence will not be uniformly accessed. As web servers usually handle large amounts of information, a desirable feature of a storage device storing such information is the efficient use of available storage. At the same time the storage should be reliable. i.e. it should be able to sustain disk failures without bringing the system down. This requirement is a must for highly available application servers that should be up and running without interruptions. Further, even if the system crashes, it should be able to recover from the crash as soon as possible and the system down time should be minimal.

Other useful and desirable properties are the providing of an abstraction of large virtual disks that can be split into smaller ones as needed (while moving towards the goal of attribute based storage), the ability to mix old and new disks with migration from older (less reliable?) (slower?) disks to newer ones automatically and the ability to perform well on write-dominated traffic. The last one is quite important as large caches filter out most of the reads leaving more writes than reads in the traffic for the storage device.

In this paper, we present a Linux based Temperature Sensitive Storage (TSS) that provides a hierarchical storage consisting of RAID1, RAID5 and cRAID5 tiers. TSS gives a unified view of a single storage device with data migrating from one tier to another depending on the access frequency of the data. Thus the frequently accessed data resides in faster storage (RAID1), while the not so frequently accessed data slowly moves to a storage which is not as fast but is storage efficient (RAID5) and the least frequently accessed data moves to a highly storage efficient but slow tier (cRAID5). Thus the scheme optimizes between performance and storage efficiency. TSS implements different storage personalities as different RAID levels that can sustain single disk failures without bringing the system down. Data consistency across system crashes is taken care of using data logging. Because of the poor performance of partial writes in RAID5 and cRAID5, the hierarchy provides different performance and storage efficiencies while providing approximately the same reliability across the three layers. For read-dominated traffic, RAID1 and RAID5 do not provide the difference in performance that makes the hierarchy useful.

Further, the dynamic nature of the data placement in different tiers can take the advantage of locality of reference of the data accesses by typical applications. The policy for the dynamic data migration and maintenance of data at different tiers is kept separate from the low level implementation of TSS. The policies are implemented as user level daemon process, using the ioctl() calls provided by the TSS device. This also has the advantage of having different policies for different situations, depending on the type of application and the availability of the resources.

Section 2 of this paper discusses the previous work done in this area. The major design issues are discussed in Section 3 and Section 4 gives some details about TSS implementation. Section 5 reports the results of the trace driven execution on our experimental setup, followed by conclusions and future work in Section 6.


next up previous
Next: Previous Work Up: Design, Implementation and Policy Previous: Abstract
2001-09-13