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

CHAPTER 2. BACKGROUND AND RELATED WORK 10
was a subject of future work. A brief examination of lock times by the authors revealed that the file system
can be responsible for causing the kernel to spend up to 88% of the total execution cycles of AIM VII on a
busy-wait spin lock known as the “big kernel lock” (BKL). This portion varies from 12% on XFS, to 30%
on Ext2, to 85% on Ext3, and to 88% on ReiserFS. These values had a direct impact on scalability. From
this work, we can see that file systems can have an impact on the operating system and subsequently on
scalability. However, more research must be conducted to understand and improve file system performance
scalability on shared-memory multiprocessors.
NTFS disk scalability was briefly examined by Riedel et al. [59]. They examined the performance im-
provements of using up to 4 disks configured for striping and used sequential transfers of 100 MB files as
the workload. The results indicate that under NTFS, increasing the number of disks can result in a linear
increase in throughput. Larger request sizes resulted in higher throughput and lower processor overhead.
Processor scalability was not examined.
Overall, SMP file system scalability has not been extensively studied. Commercial Unix SMP vendors
claim performance scalability of their file systems but there is little concrete evidence, such as detailed
experimental results, to support the claims.
There have been many performance studies conducted on file systems for message-passing multiprocessors,
multicomputers, and clusters such as the performance of the Andrew File System [27], Sprite Network File
System [47], Thinking Machines Scalable File System [38], Galley Parallel File System [48, 49, 50], IBM
Vesta Parallel File System [17], IBM General Parallel File System [25], IBM Parallel I/O File System [79],
Intel Parallel File System [79], Intel Concurrent File System [10], and Parallel Virtual File System [13].
However, there have been few performance studies conducted on parallel file systems on shared-memory
multiprocessors. Due to the coarser granularity of sharing in message-passing multiprocessor file systems,
these designs do not apply well to tightly-coupled shared-memory multiprocessor file systems such as HFS.
Kotz and Nieuwejaar designed a file system for multiprocessors called Galley [48, 49, 50]. Galley is a file
system targetted for scientific workloads, and it has been evaluated on message-passing systems such as the
IBM SP2 MPP. Galley is not specifically targetted for shared-memory processors.
Dibble et al. [19] created Bridge as a multi-layered file system designed for parallel processors. It uses
conventional local file systems as its base but cordinates them using a Bridge server and Bridge clients to
create a single file system image. This multi-layering technique is similar to the configuration of NFS. Since
they used conventional local file systems at the client ends, they did not study scalability at the same level
of detail as in this thesis. They were interested in a first iteration design that offered basic functionality and
showed some performance improvement.
Kotz and Ellis examined caching policies in parallel file systems for multiprocessor scientific workloads
[31]. They assumed a fairly rigid configuration of striped data across all disks. They focused on write-only