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

CHAPTER 6. MICROBENCHMARKS – OTHER FUNDAMENTAL OPERATIONS 56
lookatme.txt 1000 times, where XXX refers to the processor that the thread is executing on. The files were
regular, random-access files. All threads were executed in parallel and each was assigned its own processor
and disk. The file was located several levels down the directory tree to provide a more realistic file location
that would cause a more realistic coverage of cache entries examined. However, the parent directories were
empty except for the very leaf directory that contained the target file. This configuration may have provided
a slightly unfair workload since, in practice, each directory should have been populated, causing the lookup
scheme to linearly traverse each directory to find the target entry that represented the next directory down
the path. Since we were not concerned with absolute performance results but with relative scalability results,
we considered the configuration to be appropriate.
The results, shown in Figure 6.7, indicate that scalability was extremely poor beyond 2 processors.
Since the experiment was run from within the file system address space (server-level), the normal file name
caching system provided by the VFS was not utilized. Under normal usage, the VFS would handle the
majority of repeated lookups of the same path names, making the performance of the file lookup operation
less critical.
6.3.1 Increased Initial Pool of Block Cache Entries
This experiment examined the effect of increasing the initial pool of block cache entries from 20 to 200. Under
the chosen workload, each thread required approximately 10 block cache entries in its working set. Due to
the method of managing block cache entries, the characteristics of the chosen workload, and a temporary
patch to avoid reader/writer problems in the original HFS implementation, the number of block cache entries
never increased and remained at 20. The optimal behavior of the block cache system should have resulted
in an increased number of block cache entries, from 20 entries to 200 entries. When running the experiment
on more than 2 processors, this flaw caused the 20 block cache entries to thrash between all processors.
The results from increasing the initial pool of block cache entries from 20 to 200 is shown in Figure 6.8.
Performance improved but the scalability problems were not resolved, as shown in the magnified version of
the results in Figure 6.9.
6.3.2 Applying the Read Test Optimizations
In this experiment, we additionally applied the optimizations developed from the read test workload. This
configuration included all the optimizations from Section 5.5.9 and the increased initial block entry pool size
from Section 6.3.1. These optimizations included the following.
1. Padded ORS hash list headers.
2. Padded ORS and block cache entries.