Matching Application Access Patterns to Storage Device ...

More documents

Recommendations

Info

24 · Matching Application Access Patterns to Storage Device Characteristics
3 Explicit Performance Characteristics A carefully designed storage interface can provide device-specific performance characteristics and encapsulate them in device neutral attributes. These attributes annotate the linear address space of fixed-size blocks, identified by a logical block number (LBN), which is a storage device abstraction provided by current interfaces such as SCSI or IDE [Schmidt et al. 1995]. With these annotations, a piece of host software, called the storage manager (SM), can match application access patterns to these explicitly stated characteristics, take advantage of the device’s unique strengths, and avoid accesses that are inefficient. This chapter describes the storage interface model and the mechanisms for conveying performance attributes. It also describes performance characteristics of devices for secondary storage. It describes the characteristics of disk drives (the most prevalent on-line storage device in today’s systems), disk arrays, and MEMS-based storage devices (MEMStore) [Carley et al. 2000] that are still being researched. These devices are expected to complement or even replace disk drives as on-line storage in the future [Schlosser et al. 2000; Uysal et al. 2003]. Finally, it discusses how these characteristics influence different access patterns. 3.1 Storage model The storage model, depicted in Figure 3.1, builds upon established computer systems architecture, which consists of, among others, two components relevant to this dissertation: a host and a storage device. The host (e.g., a web server) is a separate component that includes memory and a general purpose CPU capable of running various applications. The storage device includes the media for nonvolatile storage and any additional hardware required for control and access to this media. These controllers may include ASICs, memory, and even CPUs. A high-level storage interface cleanly separates the host functions from those of the storage device. It abstracts device-specifics away from the host, allowing it to work transparently with any storage device. This dissertation extends this interface to provide performance information to the applications running on the host,
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 35 and 36: 2.5 Accesses to multidimensional da
Page 37 and 38: 2.5 Accesses to multidimensional da
Page 39: 2.5 Accesses to multidimensional da
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:
5.3 Evaluating ensembles for disk d
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 ...

Create successful ePaper yourself

Delete template?

Save as template?