Matching Application Access Patterns to Storage Device ...

More documents

Recommendations

Info

8 · Matching Application Access Patterns to Storage Device Characteristics requesting only the data needed by the query. Unwanted portions of a table can be skipped while scanning at full speed, resulting in scan times proportional to the amount of data actually used by queries. 1.4.3 Automated characterization of disk performance The discovery tool described in this dissertation, called DIXtrac, automatically characterizes the performance of modern disk drives. It can extract over 100 performance-critical parameters in 2–6 minutes without human intervention or special hardware support. While only a small fraction of these parameters is encapsulated as the set of performance attributes to be passed to the storage manager, this accurate characterization is useful for other applications requiring detailed knowledge of device parameters [Lumb et al. 2000; Wang et al. 1999; Yu et al. 2000]. In particular, the access delay boundaries performance attribute encapsulates the extracted disk track sizes and the parallelism attribute additionally encapsulates the head-switch and/or one-cylinder seek time. 1.5 Organization The reminder of the dissertation is organized as follows. Chapter 2 describes previous work related to exposing information about storage devices for application performance gains. Chapter 3 describes in detail the proposed approach of encapsulating storage device performance characteristics into a few high-level attributes annotating the device’s LBN linear address space. It also discusses in detail the underlying storage device characteristics. Chapter 4 describes a discovery tool, which can determine the performance characteristics of modern disk drives using conventional SCSI interface. Chapter 5 describes a performance attribute called access delay boundaries, and evaluates how utilizing this attribute improves performance for file systems and database systems. Chapter 6 describes another performance attribute, called parallelism, and shows how it improves performance for database query operators. Chapter 7 summarizes the contributions of this dissertation and suggests some avenues for future work.
2 Background and Related Work 2.1 Storage interface evolution Virtually all of today’s storage devices use an interface that presents them as a linear space of equally-sized blocks (e.g., SCSI or IDE [Schmidt 1995]) . Each block is uniquely addressed by an integer, called a logical block number (LBN), from 0 to LBN max (which is the number of blocks minus one). This interface separates a storage device and its software from the host running applications; the clean separation between the two allows changes to occur on either side of the interface without affecting the other. For example, a new storage device can be simply connected to the host, without any modifications to the storage manager code. The storage device abstraction offered by this interface also provides a simple programming model. Within this abstraction, a piece of system software, called the storage manager (SM for short), accepts requests for data from applications through a well-defined API. The SM then transforms these requests into individual I/O operations and issues them to the storage device on behalf of the host applications. Because the SM communicates with these applications, it can utilize the knowledge of all the applications’ access patterns to generate non-competing I/O operations. Before this storage interface existed, the storage manager was also responsible for controlling storage device specifics such as positioning of the read/write heads, data encoding, and handling of media errors. With such tight coupling between the storage device and the SM, plugging a new storage device into the host required software changes to the storage manager. It also had one important advantage. The storage manager could leverage its intimate knowledge of device’s performance characteristics and application access patterns. This knowledge, combined with the ability to control the mechanics of the storage device, allowed the storage manager to fully utilize storage device resources by turning the application access patterns into efficient I/O operations. In particular, many algorithms have been developed for efficient scheduling of read/write heads of rotating drums and disk drives, minimizing disk access latency
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: 1.4 Contributions · 7 provide up t
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 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 75 and 76:
4.2 Characterization algorithms ·
Page 77 and 78:
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?