DADA : Dynamic Allocation of Disk Area

Transcription

1 DADA : Dynamic Allocation of Disk Area Jayaram Bobba and Vivek Shrivastava Computer Sciences Department University of Wisconsin, Madison Abstract With current estimates of data to be managed and made available increasing at 6% per annum, disk space utilization is becoming a critical performance issue for high end users, including but not limited to IT solutions, Storage Area Networks and Virtual Machine environment. We propose Dynamic Allocation of Disk Area (DADA), a disk management framework that performs on-demand disk area allocation on the basis of user access patterns. Results show that our service can reduce disk space utilization upto 2 times when compared to traditional static allocation policies. Also it is shown that using certain pre allocation schemes, minimize the overhead incurred due to on demand allocation. Our experiments indicate that there is a tradeoff between disk utilization and the runtime performance of the programs. We test our scheme on two microbenchmarks with varied properties and show that our framework performs considerably better for non I/O intensive applications. Also we perform experiments on HP disk traces to study the efficacy of our pre allocation mechanisms. 1 Introduction Information technology is the lifeblood of any business, especially today when organization performance depends on information on demand. Business accountability hinges on it, laws and regulations mandate it, customers demand it, and effective business processes rely on it. But as utterly valuable as information on demand has become, it has become more costly to store, maintain and protect. Storage is no longer an afterthought. Too much is at stake. Companies are searching for more ways to efficiently manage expanding volumes of data. Also, the increasing complexity of managing large numbers of storage devices and vast amounts of data is driving greater business value into software and services. With current estimates of data to be managed and made available increasing at 6 percent per annum [9], disk space utilization is fast becoming a major concern for high end users. Scalability and manageability have become major issues in data storage with solutions pointing towards smart placement of data on the disk and flexible data movement within storage devices [5]. As storage takes precedence, three major initiatives have emerged: Consolidation : Within the storage arena, consolidation can include reducing the number of data centers and sharing fewer large-capacity storage systems among a greater number of application servers. Consolidated resources can cost less and can be easier to share and protect [6]. Virtualization : Storage virtualization involves a shift in thinking from physical and logical- treating storage as a logical pool of resources, not individual devices. Not only can this help simplify the storage environment, but it can also help increase utilization and availability. Automation : The storage arena is ripe with opportunities to lower administrative costs through automation. Once tasks are automated, administrators can deal with more strategic issues. In addition, automation can help reduce errors and contribute to high system performance. 1

2 1.1 Problem Statement As discussed above, disk space is fast becoming a premium resource component of major businesses. However current disk management utilities still treat disk space as a secondary resource without much emphasis on efficient space utilization and smart data placement. Disk Space Utilization Conventional disk management utilities statically allocate fixed disk space to users on a one time basis. The most common example can be seen in normal commercial workstations where users are allocated actual physical disk space during partitioning. Suppose if a user is allocated a fixed partition size of 1GB, but it ends up using only 1GB due its particular access patterns, then approximately 9% of the disk space in wasted in that partition. Such a wastage is intolerable in high end scenarios where disk space might be a scarce resources as discussed earlier. Data Placement Consider multiple operating systems running on a Virtual Machine Monitor [11, 4, 7] that allocates fixed sized disk partitions to these OS s at the time of partition or boot up. Now if all the virtual machines actively perform I/O intensive applications on their allocated disk partition, the disk head has to continuously position itself between different partitions, which may result in highly reduced I/O efficiency. So this calls for smarter data placement. 1.2 Approach - DADA We strive to improve disk space utilization and data placement by using on demand allocation of disk area. During initial partitioning of disk, the user is allocated a virtual disk partition of specified amount, but no corresponding space is allocated on the hard disk. Now when the user actually tries to read/write data from its partition, the DADA layer allocates disk space on-the-fly to satisfy the read/write request of the user. Please note that DADA can allocate space just sufficient to satisfy the demand. In this fashion we can avoid space wastage by any particular user and it also gives us the opportunity to multiplex users requesting in an intelligent manner (by allocating disk blocks to multiple users sequentially on the hard disk to harness combined temporal locality of access patterns of multiple users). We base DADA on Logical Volume Manager (LVM) [8], the existing state-of-art userspace application for dynamic resizing and partitioning of hard disks. We also modify the kernel device mapper and add our own ioctl commands so as to make a trap feasible to user space LVM tool. We evaluate DADA using some microbenchmarks and real life filesystem traces. We look at the workload characteristics that effect the various parameters in the policies specified by our system. We also identify the fundamental trade-off between space utilization and performance that has to be made in the implementation of these policies, and infer that an extent size in the range of 128KB to 512KB provides good space savings with tolerable loss in performance. We discuss the related work in Section 2 followed by a discussion of current LVM implementation in Section 2. We then briefly describe device mapper in Section 4 followed by a detailed design and implementation analysis of our system in Section 5. Then we describe the results from our microbenchmarks mkfs and asynchronous I/O in Section 6. Then we conclude our report in Section 7. 2 Related Work Wilkes et. al present HP AutoRAID [13], a two level storage hierarchy on a single disk. Hot(heavily accessed) data is kept in RAID while cold data is kept in RAID5. The data is migrated between these two levels depending on its current access frequency. AutoRAID tries to place the data intelligently on the disk so as to improve the performance of I/O operations and also reduces disk space wastage by only replicating heavily accessed data. Virtual Disk Service(VDS) [3] is a LVM equivalent provided by Microsoft Corporation. It provides a higher level abstraction of the underlying hard disk, known as Dynamic Disks, which are equivalent of volume group in the LVM terminology. Dynamic disks offer greater flexibility for volume management because they use a database to track information about dynamic volumes on the disk and about other dynamic disks in the computer. IBM Virtual Shared Disk [2] provides a special programming interface that allows applications running on 2

3 Schemes Flexible Efficient Data High Disk partitions placement utilization LVM X X Auto RAID[13] X Microsoft R Virtual Disk Service [3] X X IBM R Virtually Shared Disk[2] X Conventional Disk Utilities X X X DADA Table 1: Comparison of various disk management schemes with DADA multiple nodes to access the data on a single raw logical volume as if it were local at each of the nodes. Although this approach provides great flexibility, but is highly insecure and requires special hardware for good performance. Figure 1: Example of disk space management using LVM This figure illustrates the relationship between various components of LVM subsystem with the help of an example. Hard disks (sda and sdb) are divided into physical extents of size 4MB. Logical volumes lv1, lv2 and lv3 contain logical extents that seamlessly map to physical extents from both the hard disk. Suppose an application accesses the LV lv3 at Byte , so the corresponding LE will be #62 (62*4MB= , #63 would be the next LE). The mapping table in device mapper tells that for LV lv3 LEs - 5 (approximately) are stored on PV1, and the PE is the number of PEs of lv1 on PV1 plus number of PEs of lv2 on PV1 plus 62 Logical Volume Manager [8] provides a higher-level view of the disk storage on a computer system. Our work is based on this freely available piece of software, now shipped as a part of Linux We will describe the working of the LVM in detail in the next section. 3 Logical Volume Manager Volume Management creates a layer of abstraction over the storage. Applications use a virtual storage, which is managed using a volume management software, a Logical Volume Manager (LVM). This LVM hides the details about where the data is stored, on which actual hardware and where on that hardware, from the entire system [8]. Volume management facilitates editing the storage configuration without actually changing anything on the hardware side, and vice versa. By hiding the hardware details, it completely separates hardware - and software storage management, so it is possible to change the hardware side without the software ever noticing, all during runtime. With LVM, system uptime can be changed significantly, because for changes in the storing configuration, no application has to be stopped anymore. 3.1 Working Here we present the working of the current LVM implementation. The various components of LVM are as follows: Physical Volume (PV) Any regular hard disk. Volume Group (VG) A volume group contains a number of physical volume. It groups them into one logical drive - the volume group. Logical Volume (LV) A logical volume is a part of volume group and is equivalent to a partition in conventional terminology. Logical volumes are created in volume groups, and can be resized within the boundaries of their volume group. They are much more flexible than partitions since they do not rely on physical boundaries as partitions on disks do. Physical Extent (PE) Physical Volumes are divided into physical extents(pe), the smallest storage unit in 3

4 Figure 2: Working of unmodified LVM Figure 3: Working of DADA (on top of LVM) LVM system. Data is stored in PEs that are part of LVs that are in VGs that consist of PVs. It means any PV consists of lot of PEs, numbered 1-m, where m is size of the PV divided by the size of one PE. Logical Extent (LE) Logical Volume consists of logical extents (LE), which are mapped to physical extents (PE) on the physical volume(pv). Figure 1 illustrates the relationship between various components of the LVM system. As the figure shows, the LE of a logical volume can be mapped in any fashion to the underlying physical extents on the physical volume. This gives the flexibility to place data from various partitions in any manner e.g. LFS style [1], contiguous etc. Also Figure 2 illustrates the working of current LVM implementation. Suppose User A requests a partition of 32MB and User B requests a partition of 16MB. So LVM creates a 32MB LV for A and allocates -7 physical extents on the hard disk. Similarly, a 16MB partition is created for B by mapping extents 8-11 to LV B. These mappings are stored by the device mapper and all further read/writes preclude LVM. Also note that here total disk space allocated is 48MB/88MB 54%, even though A or B might use a very small portion of their partitions. 4 Device-Mapper Device-Mapper is a new infrastructure in the Linux 2.6 kernel that provides a generic way to create virtual layers of block devices that can do different things on top of real block devices like striping, concatenation, mirroring, snapshotting, etc. It is a dumb layer that simply stores the logical extent to physical extent mappings provided by the LVM. In the current state-of-art implementation, once LVM creates the mappings for a logical partition, it is stored in device mapper and all further reads/writes to that section of the physical volume are translated by the device mapper without any interaction from the LVM. We modify device mapper to make suitable traps to LVM in order to facilitate on demand disk space allocation. 5 DADA As discussed in Section 1, disk space utilization is fast becoming a critical issue for managed storage applications like Virtual Machine Monitor [7], SAN [9, 5] etc. In a multi user scenario, conventional mechanisms for managing disk space, allocate fixed physical partition to users, which is highly inflexible and wasteful, as a user might use only a small fraction of the allocated space. Even though LVM makes the partitions flexible, it does not improve the disk space utilization, as disk space is still allocated statically at the time of the LV creation. So LVM only provides the mechanisms for flexibility but does not exploit user access patterns to minimize disk space wastage, which can be a critical performance issue in scenarios mentioned above. DADA tries to minimize disk space wastage by allocating disk space only on demand, which may be considered analogous to virtual memory approach for main memory subsystem. So we make use of the flexibility mechanisms provided by the LVM system to facilitate on demand allocation and placement of disk blocks. This approach as we will short describe, not only minimizes disk 4

5 space wastage but can also be instrumental in reducing data transfer times by intelligently placing the data on the basis of access patterns of the user. 5.1 Implementation Here we describe the implementation details of DADA. In order to perform on demand disk space allocation, we introduce the following additional concepts into the existing LVM system: Error Mapping An error mapping refers to a mapping from a logical extent to an error, which indicates that the logical extent has not been allocated any physical extent on the physical volume. Virtual Segments Contiguous logical extents that have an error mapping, form a virtual segment. It is analogous to the concept of segment (that has not been allocated any physical pages) in the virtual memory system. Extent Fault When a user tries to access a logical extent that has a error mapping, it results in an extent fault, prompting the device mapper to trap to the LVM. Reference Pre-allocation Table (RPT) This table contains the most recent references to logical extents and their corresponding stride values and number of blocks to be pre-allocated for that particular reference. The detailed working of the RPT will be explained shortly. Next we enumerate our specific modifications to the LVM system for DADA LVM Modifications As discussed in Section 3, LVM maps the logical extents to the physical extents while creating a logical volume, and the mappings are stored in the device-mapper. We modify the LVM allocation policy to initially assign an error mapping for all the logical extents of a newly created logical volume. Also now when a user tries to access any error mapped logical extent, it results in an extent fault and a trap is made to LVM. LVM then calculates the number of physical extents required to satisfy the request of the user, and then dynamically allocates those extents by mapping them to suitable free physical extents on the physical volume. This is done simply by changing the error mappings for those particular logical extents to corresponding physical extents allocated on the hard disk. As the LVM starts up, we create our own daemon processes to handle the traps made by the device mapper. These daemon process handle the request from the user and pass the control to LVM core that performs dynamic disk space allocation as described above Device mapper modifications The device mapper was modified to allow daemons to sleep in the kernel. This was achieved through a new ioctl call into the driver. When an I/O request maps to a virtual extent, device mapper does a callback to the daemon processes. This callback wakes up exactly one process which returns to LVM with the necessary information to satisfy that I/O request. Meanwhile, I/O requests that do not map to a virtual extent are allowed to proceed. Once the daemon returns from LVM with the newly allocated extents, the mapping table is reloaded and all the deferred I/O requests are processed again. 5.2 Working Figure 3 shows the working of DADA with the help of an example. Here the underlying physical volume (PV) is divided into physical extents of size 4MB each. In figure 3, User A initially requests a partition of size 16 MB and consequently DADA assigns error mapping to extents -7. These mapping are stored in the device mapper. Similarly when a logical volume is created for User B, logical extents -3 of user B s logical partition are given error mappings. Please note that at this point, none of the physical extents is actually allocated and disk utilization is %. Now when user A tries to access its logical partition for writing 6MB of data, it results in an extent fault and the device mapper transfers the control to the LVM. At this point, DADA scans the free physical extents and allocates suitable number of physical extents at suitable positions by changing the error mappings for faulting logical extents to point to the allocated physical extents. The number and position of physical extents allocated will vary on the basis of particular strategies adopted by DADA. A discussion of such strategies and their corresponding 5

6 1.4e+7 Trap Timetrace(ext2) 1.4e+7 Trap Timetrace(ext3) 1.2e+7 1.2e+7 1e+7 1e+7 Accessed Sector 8e+6 6e+6 Accessed Sector 8e+6 6e+6 4e+6 4e+6 2e+6 2e Logical Time Logical Time Figure 4: Timetrace for ext2 extent faults for HP disk trace [1] Figure 5: Timetrace for ext3 extent faults for HP disk trace performance is presented in Section 6. In this particular example, we just follow a dumb strategy that allocates physical extents and 1, just sufficient to satisfy the current request. Again when user B faults trying to write/read 1MB, DADA allocates physical extents 8-11 for B. Obviously a better strategy could be to allocate physical extents 2-5 for user B, so that the underlying driver can coalesce both the writes to one sequential write from extents to 5. This kind of strategy is already proposed in LFS [1] and might prove very useful in the context of extent allocation. Note here the total space used after 2 requests of 6MB (by A) and 1 MB(by B) is 18MB/88MB 2%. 5.3 Pre-allocation Pre-allocation of disk space can be done to decrease the number of extent faults taken during the lifetime of a logical volume. We present below a few strategies for preallocation Dumb Pre-allocation Dumb pre-allocation works by allocating disk space in terms of extents rather than blocks. Typically, I/O is specified in terms of sectors i.e a sector is the minimum data transfer unit. On an extent fault, we do not allocate just the required sectors, we pre-allocate the whole extent. This policy is based on spatial locality of new filesystem blocks Stride Pre-allocation We realize we can do better than dumb allocation by observing the access patterns for newly allocated filesystem blocks. This intuition is also backed up by an analysis of filesystem behaviour using a HP trace [1]. Figures 4 and 5 present these patters observed with ext2 and ext3 filesystems respectively. The horizontal axis refers to the logical time (which is incremented with each newly allocated block) and the vertical axis refers to the block number in the volume. We see dark horizontal patches corresponding to strides. DADA maintains a Reference Pre-allocation Table (RPT) tracks the multi strided access patterns of the users. If it observes a stride pattern in the extent faults, it issues a strided pre-allocate for the next extent in the pattern (e.g faults for extent A, A+32, A+64 triggers the pre-allocate for the extent A+96). DADA can track up to n independent access patters, where n is the number of entries in the RPT. It will issue its next strided pre-allocate for this pattern, following a demand reference to its previously preallocated extent. This class of pre-allocation is known as tagged pre-allocation [12] and is shown to be very effective in minimizing wasteful pre-allocation. The tradeoff between various allocation policies is discussed in Section 6. 6

7 45 Performance of mkfs 14 Performance of mkfs Number of faults Execution time (in secs) Extent Size(in Kbytes) Extent Size(in Kbytes) Figure 6: Number of extent faults taken by mkfs on 1MB LV 6 Results In this section, we present the results for DADA. The implementation of DADA used LVM v2.2 running on top of device-mapper v1.1 in Linux kernel Table 6 gives the system configuration parameters. We have used two microbenchmarks and a filesystem trace generated by HP research labs [1] for our experiments. The trace consists of around 5 GB of directories and data and was collected over many hours of filesystem activity. The trace is replayed using a simulator. Processor P III, 1 GHz Memory 512 MB RAM Motherboard ASUS CUV4X-C Hard Disk IBM Deskstar, ATA/IDE DTLA-352, 2.5 GB Table 2: System Configuration Parameters Given the base system on which we built DADA, we confined ourselves to investigating the problem of how much to allocate on a extent fault. We attempt to answer the following questions using our experiments - Do extent faults impact the performance of an application? How effective are the various pre-allocation policies? Figure 7: Time taken by mkfs on 1MB LV How do we choose the parameters for the preallocation policies? 6.1 Impact of extent faults on performance To study the impact of extent faults on performance, we chose two microbenchmarks. The first was a standard mkfs implementation. The benchmark creates a 1 MB ext2 filesystem on a newly created logical volume and mostly involves synchronous i/o to the disk. The second benchmark was an asynchronous i/o(aio) based benchmark. This benchmark creates a number of user-level threads. Each thread issues an asynchronous i/o request and then proceeds to do some useful work (which in our case was sleep ) before waiting for the completion of i/o. The idea is to completely mask out the effect of a extent fault. Figure 6 presents the number of extent faults during one run of the mkfs benchmark using a dumb pre-allocation policy. The horizontal axis shows the size of allocation extent while the vertical axis shows the number of extent faults. We can observe a dramatic decrease in the number of faults with increase in allocation extent size. Figure 7 gives the execution times for these runs. We can see a linear correlation between the number of faults taken and the performance of the benchmark. Clearly, in this case extent faults impact performance. The aio benchmark, on the other hand, does not seem to be affected by the number of extent faults. Figures 8, 9 present the number of extent faults taken and the execution times for the benchmark respectively. Clearly, here 7

8 14 Number of Traps 25 Performance of Asynchronous I/O benchmark Traps Time (Seconds) Extent Size (KB) Extent Size (KB) Figure 8: Number of Traps taken by the Asynchronous I/O micro-benchmark on ext2 Figure 9: Time taken by the Asynchronous I/O microbenchmark on ext2 performance is not affected to a great extent by extent faults. From these two experiments, we conclude that the relative importance of extent faults is application-dependent. Both the microbenchmarks we have chosen are realistic and we come across similar application in daily use. 6.2 Pre-allocation policies We now discuss a set of experiments that were designed to test the effectives of pre-allocation policies. These results are based on the HP trace on top of various ecosystems. We show the results for two filesystems - ext2 and ext3. The ext3 filesystem was created with an ordered journaling mode. We compare two pre-allocation policies - Dumb pre-allocation and Stride Pre-allocation. Figure 1 presents the results for the two policies on an ext2 filesystem. The allocation extent size is on the horizontal axis while the number of extent faults taken is on the vertical axis. Stride allocation performs better than dumb allocation in all cases. The performance is especially better at lower extent sizes. The same results can be observed for ext3 filesystem also (Figure 11). 6.3 Design Tradeoffs We now discuss the tradeoff associated in choosing an extent size for the pre-allocation policies. We use the HP trace again on top of ext2 and ext3 filesystems. We note that there is a fundamental trade-off between the number of extent faults taken and the allocated size of the disk volume. On one extreme, we could allocate the whole volume in one go and not take any faults. On the other hand, we could always allocate on demand and take as many faults as disk accesses to the new blocks in the filesystem. We plot the tradeoff graph for dumb allocation on ext2 filesystem in Figure 12. Each point in the graph corresponds to an extent size. As the extent size increases, the number of extent faults decrease and the allocated volume size increases. Irrespective of the characteristic of the workloads run by a system, we would like to place ourselves in the left bottom corner of the graph. This narrows down our choices to a few values from 128K - 512Kbytes. A similar tradeoff graph can be observed on ext3 filesystem (Figure 13). The knee of the curve is pretty profound here and leaves us a with a few good design points(64k - 256Kbytes). Interestingly, we could find a correlation between filesystem allocation policies and the tradeoff graphs. Note that a extent fault is taken only when the filesystem accesses a block that has been newly allocated within the filesystem. ext2 tries to allocate a new block for a file within the next 64 blocks(256k) of the last allocated block for that file. Correspondingly we can observe that all extent sizes beyond 256K show a remarkable decrease in the number of extent faults. This observation leads us to better pre-allocation policies that are designed to mimic the filesystem behaviour. 8

9 35 3 Allocation Policies(ext2) stride dumb 25 Allocation Policies(ext3) stride dumb Extent Size(in KB) Figure 1: Comparison of pre-allocation schemes for ext Extent Size(in KB) Figure 11: Comparison of pre-allocation schemes for ext3 35 4K Dumb Allocation(ext2) 45 Dumb Allocation(ext3) 3 4 4K 8K K 32K 64K 128K K 16K 256K 5 512K 1M 2M 4M Allocated Space(in MB) K 64K 128K 256K 512K 1M 2M 4M Allocated Space(in MB) Figure 12: Performance-Space tradeoff analysis for Figure 13: Performance-Space tradeoff analysis for Dumb Dumb Pre-Allocation scheme on ext2 Pre-Allocation on ext3 7 Future Work We have presented DADA, a system for lazy allocation of disk space. In this work, we have only addressed issues relating to allocation quanta. The other important issue would be allocation layout. Multiple requests from various volumes could be temporally laid out or each volume could be spatially laid out on the disk. A mixture of the two approaches could also be used. However, a performance study of these policies would need an efficient implementation of DADA. Reclamation of physical space from freed blocks is another interesting issue. The solution in this case, seems more straightforward and would probably involve the filesystem passing down the free block information to DADA. 8 Conclusion We have designed and implemented a lazy logical volume management system which provides on-demand disk space allocation similar to on-demand virtual memory. We study this system on some microbenchmarks and a real-life filesystem trace and discuss the factors influencing the various policies made in the system. In particular, we identify a fundamental trade-off between performance and disk space. We also develop some pre-allocation strategies that can be used to improve performance. These strategies play an important role for achieving tolerable 9

10 Stride Allocation(ext2) Stride Allocation(ext3) 25 4K 1 4K 9 2 8K 8 16K 7 8K K 64K K 4 32K 128K 5 256K 512K 1M 2M 4M K 3 128K 256K 2 512K 1M 2M 4M Allocated Space(in MB) Allocated Space(in MB) Figure 14: Performance-Space tradeoff analysis for Figure 15: Performance-Space tradeoff analysis for Stride Stride Pre-Allocation scheme on ext2 Pre-Allocation on ext3 performance in I/O critical workloads. References [1] Hp research lab [2] Planning for virtual shared disk. Technical report, IBM Corporation, 23. [3] Virtual disk service. Technical report, Microsoft Windows Server Technical Reference, 23. [4] P. Barham, B. Dragovic, K. Fraser, S. Hand, T. Harris, A. Ho, R. Neugebauer, I. Pratt, and A. Warfield. Xen and the art of virtualization. In SOSP 3: Proceedings of the nineteenth ACM symposium on Operating systems principles, pages , New York, NY, USA, 23. ACM Press. [5] A. Brinkmann, K. Salzwedel, and C. Scheideler. Efficient, distributed data placement strategies for storage area networks (extended abstract). In SPAA : Proceedings of the twelfth annual ACM symposium on Parallel algorithms and architectures, pages , New York, NY, USA, 2. ACM Press. [6] D. H. Brown. Vmware: Tool for server consolidation. Technical report, VMware Inc., May 22. [7] K. Govil, D. Teodosiu, Y. Huang, and M. Rosenblum. Cellular disco: resource management using virtual clusters on shared-memory multiprocessors. ACM Trans. Comput. Syst., 18(3): , 2. [8] M. Hasentein. The logical volume manager. Technical report, SuSE Inc., March 21. [9] J. Kate and R. Kanth. Introduction to storage area networks. Technical report, IBM, April 25. [1] M. Rosenblum and J. K. Ousterhout. The LFS storage manager. In Proceedings of the USENIX Summer 199 Technical Conference, pages , Anaheim, CA, USA, [11] J. Sugerman, G. Venkitachalam, and B.-H. Lim. Virtualizing i/o devices on vmware workstation s hosted virtual machine monitor. In Proceedings of the General Track: 22 USENIX Annual Technical Conference, pages 1 14, Berkeley, CA, USA, 21. USENIX Association. [12] S. P. VanderWiel and D. J. Lilja. Data prefetch mechanisms. ACM Computing Surveys, 32(2): , 2. [13] J. Wilkes, R. Golding, C. Staelin, and T. Sullivan. The HP AutoRAID hierarchical storage system. In H. Jin, T. Cortes, and R. Buyya, editors, High Performance Mass Storage and Parallel I/O: Technologies and Applications, pages IEEE Computer Society Press and Wiley, New York, NY, 21. 1