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

CHAPTER 7. MACROBENCHMARK 79
is made at the Web server application level and is not an issue of the file system core. Various technique can
be used due to the nature of Web server files and the fact that all disks are identical replicas. If a thread
cannot find the target meta-data in a particular hash list or if the target hash list is highly contended, it
could search for the meta-data in other sections of the hash table by modifying the target disk number. This
technique is only possible because all disks are identical and all threads perform similar work, suggesting
that the target meta-data may exist under other sections of the hash table.
7.6 Applicability of Clustered Objects
The K42 clustered object mechanism [4] may be useful in maintaining scalability in HFS. The clustered object
mechanism is used for designing, implementing, and managing execution concurrency and data locality in a
structured, formalized fashion. A clustered object presents a globally shared, uniform, external interface but
is internally distributed in nature. The nature of the distribution and data update policies are completely
customizable by the programmer. Clustered objects can be applied to two major structures in HFS: (1) ORS
and block cache hash tables, (2) the block cache free list.
Dynamically sizable, distributed hash tables can be designed and applied to the ORS and block cache
hash tables. Dynamic hash table sizing enables HFS to be robust, allowing it to handle load imbalances,
such as hot spots in a section of the hash table, and variable resource availability, such as available free
memory, number of disks, and number of processors. Once resized, existing elements in the hash table could
migrate to their new locations if necessary.
Clustered objects can offer a solution to the free list problem in the block cache without requiring major
modifications to the existing code base. The clustered object free list can maintain the appearance of a
single, globally shared list, but internally be organized as a distributed list. Internally, each processor could
maintain a local free list. Local free lists could trigger balancing between processors as needed. In reality,
only the free list header is local to a particular processor. The entries of the free list are actually block
cache entries in the block cache hash table 10 . Therefore, they are globally shared entries that may exist on
any processor. The free list contains several properties that make it a good candidate for clustered object
implementation. First, the free list requires fast FIFO 11 capabilities, which can be satisfied solely from the
local free list. Second, the free list is never traversed, meaning that there is never a need to perform global
traversals 12 . There is only one scenario that requires partial global co-ordination from the clustered object.
An entry in a free list may request to be removed because it no longer considers itself to be free. With such
a request, the clustered object mechanism must determine which processor’s local free list the entry resides
(since it is really a block cache entry, which is globally shared) and acquire the corresponding free list lock
10 As described in Section 3.3.2, the free list is threaded throughout the block cache hash lists.
11 First in, first out – Enqueuing onto the tail of the list and dequeuing from the head of the list.
12 A global traversal of the free list would be implemented by traversing all local free lists.