Performance Analysis and Optimization of the Hurricane File System ...

More documents

Recommendations

Info

CHAPTER 3. HFS ARCHITECTURE 21 global block cache lock 0 1 2 3 4 5 6 7 free list dirty list ¦¦¦ ¦¦¦ ¦¦¦ ¦¦¦ ¦¦¦ ¦¦¦ ¦¦¦ ¦¦¦ ¦¦¦ ¦¦¦ ¦¦¦ ¦¦¦ ¦¦¦ ¦¦¦ ¦¦¦ ¦¦¦ waiting list free list ¦¦¦ ¦¦¦ ¦¦¦ ¦¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦¦ ¦¦¦ ¦¦ ¦¦ ¦¦¦ ¦¦ ¦¦¦ hash list 0 1 2 3 Waiting I/O Figure 3.5: Block cache. memory, similar to the memory layout of an array in the C language 1 , and point to the head of each list. All lists are doubly-linked and circular. Each cache entry in the hash list is protected with a simple reader-writer lock 2 implemented using three data structures. ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ block cache entry ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ ¦¦ 1. A counter indicating the number of reads in progress. The counter is protected by either the global lock (block cache) or the corresponding hash list lock (ORS cache). 2. A busy bit flag indicating that an exclusive write is in progress. 3. A global wait queue (one for the block cache, and one for the ORS cache) for waiting readers and writers. The first cache is the ORS cache, which contains entries of 128 bytes in size. It is hashed by file token and is mainly used to hold file attributes such as the meta-data information that is obtained from a typical Unix stat() function call. For certain types of files such as extent-based files, it is used to hold the index of extent blocks. It can also be used to hold a shortened version of the directory block index. The structure of the ORS cache system implementation is shown in Figure 3.4. The second cache is the block cache, which contains larger cache entries of 4096 bytes in size 3 . It is used to hold the file index of each disk, block index of each file, directory contents, etc. It is hashed by three values: (1) file token, (2) block number, and (3) type of meta-data block, such as block index, file index, 1 Due to the allocation algorithm of hash and dirty list headers, these data structures are arranged in memory in a form that is equivalent to a contiguously allocated array. 2 This reader-writer lock is by no means the most efficient. 3 In reality, the block cache entry contains a pointer to a 4096 byte memory region to hold the cache contents rather than having it embedded within the cache entry itself.
CHAPTER 3. HFS ARCHITECTURE 22 directory contents, etc. The structure of the block cache system is shown in Figure 3.5. As stated by Krieger [34, p. 53], “Having multiple caches, each tuned for a different size, results in better performance than having a single physical cache with multiple element sizes”. In the original HFS design, the ORS cache contained 64 hash lists whereas the block cache contained only 4. The reasons for the difference have not been determined, however the size of the hash lists can be changed easily during the optimization process. The ORS cache contains a single dirty list whereas the block cache contains 8 dirty lists due to flushing order requirements of different types of meta-data. The free list in both the ORS and block cache indicates which items can be recycled although they are given a second chance to be reused under their original identity should they be needed. However, due to the nature of the content in the two caches, the operation of the free list in the ORS cache is slightly different from the block cache. In the ORS cache, entries are placed on the free list only after the represented file is invalidated. In the block cache, entries are placed on the free list quite liberally. As long as the entry is not being used, meaning that it does not have a reader or writer lock set, and the contents are unaltered, it is placed onto the free list. Consequently, the free list is utilized much more frequently in the block cache. In the ORS cache, the entries cannot be on the free list and the hash list simultaneously and hence the free list exists as a separate list. In the block cache, entries can exist on both the free list and a hash list simultaneously and hence the free list is threaded throughout the cache. This policy in the block cache leads to a natural recycling process of cache entries. The locking infrastructure is different as well. In the block cache, there is a single global lock protecting all data structures. On the other hand, the ORS cache uses a number of locks, each protecting a specific group of data structures. For instance, there is a lock for each hash list header, for the dirty list header, and free list header. The difference in locking infrastructure is due to the nature of access and purpose of the two different meta-data caches. The ORS cache contains file attributes that must be consulted (and possibly modified) frequently. Access latency is very important, which may be the reason for the finer-grain locks. On the other hand, access latency to the block cache contents may not be as critical so the simpler design of a single global lock may be sufficient. There are trade-offs between the two designs. Under a single global locking scheme, the number of locks that need to be acquired for any operation on the target data structures is small, whereas under a finer grain locking scheme, several locks need to be acquired for an operation. The disadvantage of the global locking scheme is that it may lead to high contention on the single lock if the lock is held for long periods of time and there are many concurrent threads that are competing for the single global lock. Finer grain locks can reduce this contention but at the cost of higher overhead. Meta-data cache flushing policies have not been decided and may have a significant impact on performance. For our experiments, cache flushing is triggered explicitly when desired.
Page 1 and 2: Performance Analysis and Optimizati
Page 3 and 4: Acknowledgements This thesis has be
Page 5 and 6: 4.6 Measurements Taken and Graph In
Page 7 and 8: List of Tables 3.1 File system inte
Page 9 and 10: 6.1 Create. . . . . . . . . . . . .
Page 11 and 12: CHAPTER 1. INTRODUCTION AND MOTIVAT
Page 13 and 14: CHAPTER 1. INTRODUCTION AND MOTIVAT
Page 15 and 16: CHAPTER 2. BACKGROUND AND RELATED W
Page 23 and 24: Chapter 3 HFS Architecture This cha
Page 25 and 26: CHAPTER 3. HFS ARCHITECTURE 16 3.1.
Page 27 and 28: CHAPTER 3. HFS ARCHITECTURE 18 ORS
Page 29: CHAPTER 3. HFS ARCHITECTURE 20 dirt
Page 33 and 34: CHAPTER 3. HFS ARCHITECTURE 24 1. 2
Page 35 and 36: CHAPTER 3. HFS ARCHITECTURE 26 curr
Page 37 and 38: CHAPTER 4. EXPERIMENTAL SETUP 28 1
Page 39 and 40: CHAPTER 4. EXPERIMENTAL SETUP 30 de
Page 41 and 42: CHAPTER 4. EXPERIMENTAL SETUP 32 av
Page 43 and 44: Chapter 5 Microbenchmarks - Read Op
Page 45 and 46: CHAPTER 5. MICROBENCHMARKS - READ O
Page 61 and 62: Chapter 6 Microbenchmarks - Other F
Page 63 and 64: CHAPTER 6. MICROBENCHMARKS - OTHER
Page 75 and 76: Chapter 7 Macrobenchmark 7.1 Purpos
Page 77 and 78: CHAPTER 7. MACROBENCHMARK 68 server
Page 79 and 80: CHAPTER 7. MACROBENCHMARK 70 avg #
Page 81 and 82:
CHAPTER 7. MACROBENCHMARK 72 Logica
Page 83 and 84:
CHAPTER 7. MACROBENCHMARK 74 avg #
Page 85 and 86:
CHAPTER 7. MACROBENCHMARK 76 avg #
Page 87 and 88:
CHAPTER 7. MACROBENCHMARK 78 7.5 Ot
Page 89 and 90:
CHAPTER 7. MACROBENCHMARK 80 to deq
Page 91 and 92:
CHAPTER 8. CONCLUSIONS 82 8.1 Gener
Page 93 and 94:
CHAPTER 8. CONCLUSIONS 84 read-only
Page 95 and 96:
Bibliography [1] Gene M. Amdahl. Va
Page 97 and 98:
BIBLIOGRAPHY 88 [33] David Kotz, So
Page 99:
BIBLIOGRAPHY 90 [71] Keith A. Smith
show all

Performance Analysis and Optimization of the Hurricane File System ...

Create successful ePaper yourself

Delete template?

Save as template?