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

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 perfor-
mance. For our experiments, cache flushing is triggered explicitly when desired.