Matching Application Access Patterns to Storage Device ...

More documents

Recommendations

Info

16 · Matching Application Access Patterns to Storage Device Characteristics I/O operation [IBM Corporation 2000], and the DB2 STRIPED CONTAINERS parameter instructs the storage manager to align I/Os on stripe boundaries. Database storage managers complement DBA knob settings with methods that dynamically determine the I/O efficiency of differently-sized requests by issuing I/Os of different sizes and measuring their response time. Unfortunately, these methods are error-prone and often yield sub-optimal results. These mechanisms are also quite sensitive and prone to human errors. In particular, high-level generic parameters make it difficult for the storage manager to adapt to the device-specific characteristics and dynamic changes to workload. This results in inefficiency and performance degradation. 2.3.3 Extending storage interfaces Many works demonstrated how extending storage interfaces with functions that expose information about device specifics can improve application performance. The following paragraphs discuss three specific aspects of this research that include the freedom to rearrange requests to improve aggregate performance and better utilization of resources by exposing some additional information about storage organization. Masking access latency Recent efforts have proposed mechanisms that exploit freedom to reorder storage accesses in order to mask access latency. Storage latency estimator descriptors estimate the latency for accessing the first byte of data and the expected bandwidth for subsequent transfer [VanMeter 1998]. Steere [1997] proposed a construct, called a set iterator, that exploits asynchrony and non-determinism in data accesses to reduce aggregate I/O latency. The River projects use efficient streaming from distributed heterogeneous nodes to maximize I/O performance for data-intensive applications [Arpaci-Dusseau et al. 1999; Mayr and Gray 2000]. Other research has exploited similar ideas at the file system level. Parallel file systems achieve higher I/O throughput from the underlying, inherently parallel, hardware [Freedman et al. 1996; Krieger and Stumm 1997]. As demonstrated by Kotz [1994], a parallel file system rearranging application requests into larger, more efficient I/Os to individual disks provides significant improvements to scientific workloads. Similarly, I/O request criticality annotations based on file system and application needs provide greater scheduling flexibility at the storage subsystem level, resulting in better application performance [Ganger 1995].
2.3 Exploiting device characteristics · 17 Exposing information about device organization Arpaci-Dusseau and Arpaci-Dusseau [2001] recently termed a system building practice that exploits knowledge of the underlying subsystem structure gray-box approach. Using such approach, Burnett et al. [2002] built algorithms, which can determine the OS management policies for buffer caches. Their findings can be extended to the storage manager (e.g., a file system), allowing it to determine which I/Os are going to be serviced from cache and schedule I/O requests accordingly. Wong and Wilkes [2002] proposed new storage interface operations which enable more intelligent buffer management. Using promote/demote operations, the host and the storage device can explicitly coordinate which data is cached where, avoiding double buffering and hence effectively increasing the cache footprint. Denehy et al. [2002] extended the gray box approach to building an interface between storage devices and file systems. This interface exposes parallelism and failure-isolation information to a log-structured file system, which can make dynamic decisions about data placement and balance load between individual disks of the exposed RAID group. Their approach is similar to the one presented here; the storage device provides hints to a file system storage manager, called I-LFS, which then adjusts its behavior to improve performance and reliability. Object-based storage interface The object-based storage interface, advocated by the NASD project [Gibson et al. 1998] and drafted as an ANSI interface specification [National Committee for Information Technology Standards 2002], proposes to use variable size objects, instead of fixed size blocks, as the interface between hosts and storage devices. These higher level semantics pass hints to the storage device. Combined with the ability to assign various attributes to different objects, these hints can be used within the storage device to allow, for example, object collocation and other performancerelated operations behind the object-based storage interface. However, there must still exist some kind of a storage manager within the storage device to be able to allocate and manage the individual blocks of the storage media and map them into an object exported by the storage interface. Although the storage manager is now found on the opposite side of the physical interface, the work explored in this dissertation is suited to this object model as well. Applications providing hints to storage managers Patterson et al. [1995] proposed a mechanism, called informed prefetching and caching, whereby applications provide hints about intended access patterns to a
Page 1 and 2: Matching Application Access Pattern
Page 3 and 4: To Katrina.
Page 5 and 6: Abstract Conventional computer syst
Page 7 and 8: Acknowledgements The work presented
Page 9 and 10: Contents 1 Introduction 1 1.1 Probl
Page 11 and 12: Contents · xi 5.1.3 MEMStore . . .
Page 13 and 14: Figures 3.1 Two approaches to conve
Page 15 and 16: Tables 3.1 Representative SCSI disk
Page 17 and 18: 1 Introduction 1.1 Problem definiti
Page 19 and 20: 1.3 Overview · 3 fixed-size blocks
Page 21 and 22: 1.3 Overview · 5 performance avail
Page 23 and 24: 1.4 Contributions · 7 provide up t
Page 25 and 26: 2 Background and Related Work 2.1 S
Page 27 and 28: 2.2 Implicit storage contract · 11
Page 29 and 30: 2.3 Exploiting device characteristi
Page 31: 2.3 Exploiting device characteristi
Page 35 and 36: 2.5 Accesses to multidimensional da
Page 41 and 42: 3 Explicit Performance Characterist
Page 43 and 44: 3.1 Storage model · 27 VFS read()
Page 45 and 46: 3.1 Storage model · 29 The archite
Page 47 and 48: 3.1 Storage model · 31 that has n
Page 49 and 50: 3.2 Disk drive characteristics · 3
Page 57 and 58: 3.3 MEMS-based storage devices · 4
Page 63 and 64: 3.4 Disk arrays · 47 3.4.1 Physica
Page 65 and 66: 4 Discovery of Disk Drive Character
Page 67 and 68: 4.2 Characterization algorithms ·
Page 79 and 80: 4.4 Results and performance · 63 d
Page 81 and 82: 4.4 Results and performance · 65 V
Page 83 and 84:
4.4 Results and performance · 67 Q
Page 85 and 86:
5 The Access Delay Boundaries Attri
Page 87 and 88:
5.2 System design · 71 5.2 System
Page 89 and 90:
5.3 Evaluating ensembles for disk d
Page 91 and 92:
Page 93 and 94:
Page 95 and 96:
Page 97 and 98:
Page 99 and 100:
5.4 Block-based file system · 83 1
Page 101 and 102:
5.4 Block-based file system · 85 E
Page 103 and 104:
5.4 Block-based file system · 87 p
Page 105 and 106:
5.5 Log-structured file system · 8
Page 107 and 108:
5.6 Video servers · 91 Startup lat
Page 109 and 110:
5.7 Database storage manager · 93
Page 111 and 112:
Page 113 and 114:
Page 115 and 116:
Page 117 and 118:
Page 119 and 120:
Page 121 and 122:
Page 123 and 124:
Page 125 and 126:
Page 127 and 128:
6 The Parallelism Attribute Several
Page 129 and 130:
6.1 Encapsulation · 113 row a row
Page 131 and 132:
6.1 Encapsulation · 115 that can i
Page 133 and 134:
6.2 System design · 117 6.2 System
Page 135 and 136:
6.2 System design · 119 that do no
Page 137 and 138:
6.3 Atropos logical volume manager
Page 139 and 140:
Page 141 and 142:
Page 143 and 144:
Page 145 and 146:
Page 147 and 148:
Page 149 and 150:
Page 151 and 152:
6.4 Database storage manager exploi
Page 153 and 154:
Page 155 and 156:
Page 157 and 158:
Page 159 and 160:
Page 161 and 162:
Page 163 and 164:
Page 165 and 166:
Page 167 and 168:
Page 169 and 170:
Page 171 and 172:
7 Conclusions and Future Work 7.1 C
Page 173 and 174:
7.2 Directions for future research
Page 175 and 176:
Bibliography Ailamaki, A., DeWitt,
Page 177 and 178:
Bibliography · 161 Chang, E. and G
Page 179 and 180:
Bibliography · 163 Gibson, G. A.,
Page 181 and 182:
Bibliography · 165 McKusick, M. K.
Page 183 and 184:
Bibliography · 167 Schindler, J.,
Page 185 and 186:
Bibliography · 169 VanMeter, R. 19
Page 187 and 188:
A Modeling disk drive media access
Page 189 and 190:
A.3 Zero-latency disk · 173 A.3 Ze
Page 191 and 192:
A.3 Zero-latency disk · 175 (I) S1
Page 193 and 194:
B Storage interface functions This
show all

Matching Application Access Patterns to Storage Device ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?