A Comparison of FFS Disk Allocation Policies

Transcription

1 A Comparison of FFS Disk Allocation Policies Keith A. Smith Computer Science 261r A new disk allocation algorithm, added to a recent version of the UNIX Fast File System, attempts to improve file layout by exploiting the clusters of free space that are available in the file system. In this paper I study the effectiveness of this algorithm at reducing file system fragmentation. To do this, I have created a program that artificially ages a file system by replaying a workload similar to that experienced by a real file system. To evaluate the effectiveness of the new disk allocation algorithm, I use this program to replay four months of activity on two file systems that differ only in the disk allocation algorithms that they use. At the end of the four month simulation, the file system that used the new allocation algorithm had 3% more file data blocks that were contiguously laid out. 1 Introduction The disk layout of files on a file system is a major determinant of file system performance. Files that are physically contiguous on disk can be read and written at the maximum disk bandwidth. Files that are fragmented cannot be read and written as quickly because of the seek latencies and rotational delays incurred as the disk heads move from one part of the file to another. Recent file systems [7][9] have implemented clustering, which allows the file system to transfer data to or from the disk in units equal to the maximum hardware transfer size. Measurements [7][1] have shown that these clustering enhancements can improve file system performance by a factor of two or three. Over the lifetime of a file system, this increased level of performance can only be maintained if the disk allocation algorithm continues to be able to allocate contiguous disk blocks to new files. It is relatively easy to achieve optimal layout on the newly created, empty file systems that are typically used for benchmarking. Over time, however, contiguous clusters of free space may become scarce on the file system, forcing new files to be fragmented and decreasing file system throughput. A recent study [12] has shown that UNIX file systems that are more than two years old may perform 15% worse than comparable empty file systems. This decline in performance correlates closely with increased fragmentation of newly created files on these file systems. Although the maximum transfer size on these file systems was seven file system blocks, the average cluster size for mid-sized files (32 128KB) was approximately three blocks. Recently a new disk allocation algorithm, intended to improve clustering, has been implemented for the UNIX Fast File System (FFS). In order to understand the long term effect of this algorithm I have built a system that artificially ages a file system applying a simulated work load to the file system. This workload was generated using snapshot and trace data collected from several file systems. I have used this aging technique to simulate four months of activity on two file systems that differed only in the disk allocation algorithms that they used. One file system was an unmodified UNIX file system; the other implemented the improved disk allocation algorithm. The results show that the new disk allocation algorithm provided slight (3%) improvements in file layout after four months of simulated load. Because the file system aging program generates less fragmentation than was seen on real, four-month-old file systems, and because real file systems are in use for much longer 1

2 than four months, I believe that this new disk allocation algorithm will provide noticably improved performance over the life of a file system. In Section 2, I describe the disk allocation algorithm that has traditionally been used by the UNIX Fast File System, and explain the improvements offered by the new system. Section 3 explains the file system aging process, including the methodology used to generate the aging workload and a validation of the aging program by comparing its results to a real file system. In Section 4, I compare the file fragmentation that results from the original FFS allocation algorithm and the new allocation algorithm. Section 5 summarizes this study. 2 FFS Disk Allocation Algorithms A simplified explanation of the FFS disk allocation algorithm is described here. A more detailed explanation may be found in [5]. FFS allocates blocks to a file one at a time. The first free block in a cylinder group is typically allocated as the first block of a file. Each time a file grows, FFS attempts to allocate the block immediately following the previous block of the file on disk. If this block is not available, then a contiguous allocation is not possible, and FFS picks a different free block in the same cylinder group, typically one that is minimizes the seek time from the previous block of the file. The downside of the FFS disk allocation algorithm is that FFS always allocates free space starting at the beginning of a cylinder group. Thus, a multiple block file may be fragmented even if there is enough contiguous free space later in the cylinder group to lay out the file perfectly. For example, consider a cylinder group where every other block is allocated except for the last eight blocks of the cylinder group, which are all free. If a user creates an eight block file in this cylinder group, FFS will allocate the first eight free blocks to the file. Because the resulting file uses every other block on the disk, the throughput when reading or writing the file would be half of that for a file that is allocated on eight contiguous blocks. The drawback of the FFS disk allocation algorithm is that it allocates blocks one at a time, without any knowledge of the ultimate size of the file. In the previous example, if the file system know that eight blocks were going to be allocated to the file, it might allocate the eight block cluster of free space at the end of the cylinder group instead of the first eight free blocks. This observation is the key to the new realloc disk allocation algorithm implemented by Kirk McKusick in 4.4BSD. This allocation scheme initially allocates blocks in the same manner as the traditional FFS disk allocation algorithm. When a block of file data is subsequently flushed from the buffer cache, the realloc code searches the cache for other blocks that belong to the same file and attempts to reallocate them to physically contiguous disk blocks. The goal of this study is to determine the long term effectiveness of this new disk allocation algorithm. I do this by attempting to answer several questions: Does the realloc algorithm reduce the long term fragmentation of an FFS? Are enough contiguous clusters of free space available to be exploited by the realloc code? How does the choice of disk allocation algorithm affect the clustering of free space on the file system? 3 File System Aging In order to understand the effectiveness of a disk allocation algorithm, we must study its long term effect on file system layout. To do this in a laboratory setting, I generated an artificial load consisting of an ordered set of file create and delete operations intended to simulate the pattern of file creations and deletions a file system would see over an extended period of time. This process is called file system aging. After aging a file system, the layout of its files can be analyzed and compared with similarly aged file systems that used different allocation algorithms. 2

3 3.1 Generating a Workload The difficulty with aging a file system is generating a realistic workload. The ideal technique would be to collect extended file system traces and to age a test file system by replaying the exact set of file operations seen in the trace. The duration of the required traces makes this strategy impractical. Aside from the difficulties inherent in collecting even a week-long trace, the time frame of this project prohibited this approach. To reproduce the day-to-day changes in a file system, I used a set of file system snapshots collected from a file systems on a local file servers. These snapshots, which were originally collected for [12], were collected nightly over a period of a year. Each snapshot describes all of the files on a file system at the time of the snapshot. For each file the snapshot includes the file s inode number, generation number, inode change time, file type, and file size. In a test environment, we will typically be starting with an empty file system. Therefore I based the aging workload on a file system (the glan6 file system on virtual12) that was nearly empty at one point during the snapshot collection period. By comparing successive snapshots of the glan6 file system, I generated a list of the files that were created, deleted, or modified on each day. The inode change times provided information about the ordering of many of these events. This data was not complete, however, and some inferences and approximations had to be made: When a file was deleted, there was no way to determine the time at which it had been removed. In this case, I assigned a random time, selected from the interval between the two snapshots, to the delete operation. When an inode has the same generation number in two successive snapshots, but different file sizes and change times, the file must have been modified between the two snapshots. It is impossible to infer, however, whether the file was truncated to zero length and rewritten, was appended, or was partially truncated. Previous studies [2][8] have demonstrated that files are almost always written in their entirety at the time the file is created. Thus, when a file has been modified, I assume that the file was completely truncated and rewritten at the time indicated by the inode s change time. Another shortcoming of the workload generated from these snapshots is that it only captures operations on files that survive across as least one snapshot. Trace-based file system studies [2][8] have shown that most files live for less than the twenty-four hours between successive snapshots. To approximate the additional file creations and deletions generated by these short-lived files, I used a two week trace of NFS requests to a Network Appliance FAServer (attic). This data, which was originally used in a study of cleaning algorithms for log-structured file systems [3], includes all of the create, delete, and write requests issued to the server during the trace period. As with the data gathered from the file system snapshots, this NFS trace provides partial information about some operations: The size of a newly created file must be inferred from the trace by observing all of the write requests to that file. The difficulty arises because write requests specify the file handle of the file they are writing to, but there is no way to ascertain the handle of a newly created file; create requests only specify the name of the new file, and the file handle for the file s directory. The server returns the new file s handle in its response to the create request, but this information was not captured in the trace. I addressed this problem by assuming that most files are written to immediately after being created. Thus I assume that the file handle for a newly created file is the handle specified in the next write request from the client that issued the create request. It is impossible to determine from the trace which NFS requests result in errors. In several places there are multiple requests to create the same file. Usually these requests are separated 3

4 over a short time span with no intervening requests to remove the file. In these cases there is no way to know which of the creates (if any) was successful, and which resulted in an error. In these cases, I have assumed that the first create request was successful. From the NFS trace, I created a list of all of the files created and deleted during each 24-hour period. These files were sorted by the day they were created and the directory they were created in (the directory information is available in the create requests). The result was a file for each of the seven days of the week. Each of these files contained a set of records, each of which described the files created and deleted in one directory on that day of the week. For each file, the creation and deletion times (as offsets from midnight) and the file size were specified. The next step was to integrate these short-lived files into the workload generated from the file system snapshots. For each day in the snapshot period, I selected the file for the appropriate day of the week and randomly selected a set of directories from that file. All of the file operations in these directories were included in the aging workload. For each day, the probability of any directory being selected was equal to the ratio of the size of the file system used in snapshots to the size of the file server. glan6 was approximately 5 MB, and attic had 4 GB of storage 1. Therefore on each day, approximately one eighth of the creates and deletes of short-lived files on attic were included in the aging workload. The final workload simulates five months of activity on the glan6 file system. At the beginning of this period, glan6 was 1% utilized, and during the five month interval utilization reached a high of 98%, before declining to end up at 82%. The workload contains 57,834 file operations which write almost two gigabytes of data to the disk. 3.2 Replaying the Workload To age a file system, I applied the workload described above to an empty file system. A program reads records from the workload file, performing the corresponding file system operation(s) for each one. This task was complicated by the fact that complete pathnames for the created files were not available. Because FFS assigns files to cylinder groups based on the cylinder group of the file s directory, the algorithm used by the aging program to assign files to directories can have a major impact on the verisimilitude of the aged file system. The files generated from the snapshots and those from the NFS trace are handled in different ways. Although the snapshots do not specify which files are in which directories, the inode numbers can be used to determine the cylinder group in which each file and directory was located on the original file system. As the aging program creates new directories, it maintains lists of the directories that were in each cylinder group on the original file system. Whenever a new file is created, the aging program assigns it to a randomly selected directory that was in the same cylinder group as the file on the original glan6 file system. Files from the same cylinder group that were created within five seconds of each other are placed in the same directory, reflecting the expected locality in user s file access patterns. Note that although the inode numbers allow the aging program to determine which cylinder group a directory was in on the original file system, there is no way to guarantee that directories that were in the same cylinder group on the original file system wind up in the same cylinder group on the aged file system. Cylinder group information is not available for files from the NFS trace, and would be of little use if it were available, since these files were on a different file system than the files from the snapshots. Because NFS create requests specify the file handle of the directory where the new file is to be created, we know that certain files were created in the same directory. The aging program places all files created in the same directory in the same directory on the file system that is being aged. This directory is selected at random. A 1. At some point the storage space on attic was doubled from four gigabytes to eight gigabytes. I am unsure of when this happened relative to the time of the NFS trace. I chose to err on the side of overestimating the workload by assuming that attic had four gigabytes of disk at the time the trace was collected. 4

5 possible future improvement to the aging process would attempt to map directories referenced by the NFS trace to directories that exhibit recent file activity in the snapshots. 3.3 Verifying the Aging Process To determine the accuracy of the aging process, I configured an empty FFS file system with the same parameters as the original glan6 file system and ran the aging program on it. The aging program took approximately 16 minutes to run, corresponding to 32 minutes per month of the simulation. When the aging program completed, I took a snapshot of the resulting file system, and compared it to the snapshot of glan6 that was taken at then end of the five month period from which the aging workload was generated. For a comparison of disk allocation algorithms, the most important aspect of the aged file system is the file fragmentation and the distribution of free space. To quantify the fragmentation of a file, I used the layout score introduced in [12]. A file s layout score is defined to be the percentage of blocks in the file that are optimally allocated. A block is optimally allocated if it is physically contiguous with previous block of the file. Because the first block of a file cannot have a previous block, the first block of a file is ignored when computing layout score. A layout score of 1. indicates that a file s layout is completely contiguous. Similarly, a file with a layout score of. has no logically sequential blocks that are physically contiguous. Layout score is not defined for one block files since they do not suffer from external fragmentation. Figure 1 graphs the layout score as a function of file size on glan6 and the aged file system. For most file sizes, the aged file system has a higher layout score than the original, indicating that the files on the aged file system are less fragmented than their counterparts on glan6. Figure 1 also shows that on glan6 small files (two to sixteen blocks) are more fragmented than larger files (especially those with more than 1 blocks). Previous studies [12] have shown that this is a common phenomenon on FFS file systems. The aged file system also exhibits this increased fragmentation of small files. 1.8 Layout Score "Real" "Sim" File Size (in blocks) Figure 1: File fragmentation: Real vs. Simulated file systems. This chart plots layout score as a function of file size (expressed in blocks). The line labeled Real was generated from the snapshot of glan6 at the end of the five month period from which the aging workload was generated. The line labeled Sim was generated from the snapshot of the file system aged using this workload. 5

6 Layout score can also be used to generate an aggregate measure of the fragmentation on a file system. The aggregate layout score for a file system is the percentage of file data blocks that are contiguously allocated. Once again, one block files and the first block of each file are ignored. Figure 2 plots the aggregate layout score for glan6 and the aged file system for each day during the five months of the simulation. The simulated file system has higher layout scores then glan6. At the end of the five month period, the simulated file system s aggregate layout score is only.9, compared to the.81 aggregate layout score of glan6 at the same time. Despite better layout scores, the artificially aged file system behaves similarly to glan6, as can be seen by the similar shapes of the two curves. The simulated file system has many of the same drops and jumps as glan6, although they are often of smaller size. There are also some areas, where the simulated file system has failed to capture changes that occurred on glan6. The clearest example of this is in days 9 11 of the simulation, where the aggregate layout score of glan6 changes from day to day while the layout score of the simulated file system remains relatively constant. The final metric used to compare glan6 to the artificially aged file system is the distribution of free space on the file systems. To examine the distribution of free space in an FFS snapshot, I divided each cylinder group into ten equal-sized pieces called segments. The data for the first segment of each cylinder group were summed together to derive statistics for the free space usage in the first 1% of all cylinder groups. The statistics for other segments were similarly totaled. Figure 3 shows the distribution of free space within the cylinder groups of glan6 and the aged file system at then end of the five month period of study. On glan6 the distribution of free space is skewed toward the ends of the cylinder groups; 44% of the free space on glan6 was located in the final 2% of the cylinder groups. In contrast, the distribution of free space in the simulated file system is much more even; 41% of 1 Aggregate Layout Score "Real" "Sim" Time (Days) Figure 2: Aggregate Layout Score over time: Real vs. Simulated file systems. This chart plots the aggregate layout score for glan6 and the aged file system for each day in the five month period used to generate the aging workload. The line labeled Real was generated from the daily snapshots of glan6 taken during this period. The line labeled Sim was generated from snapshots taken after the simulated workload corresponding to each day was simulated by the aging program. 6

7 1 Percentage of Free Blocks (cumul.) "Real" "Sim" Percentage of Cylinder Group Figure 3: Distribution of Free Space: Real vs. Simulated File Systems. This graph plots the cumulative percentage of file system free space as a function of the offset within the cylinder groups for the glan6 and artificially aged file systems. The curve labeled Real was generated from a snapshot of glan6 taken at the end of the five month simulation period. The curve labeled Sim was generated from a snapshot of the aged file system taken at then end of the aging process. the free space on the aged file system is located in the first 5% of the cylinder groups. This relatively even free space distribution in the aged file system may be the result of excessive randomness in the simulation. Although the aged file system is less fragmented than the file system it was modeled after, the patterns of its fragmentation are similar to those seen in other FFS file systems, indicating that the aging process, while less than ideal as a simulation of a specific file system workload, does generate realistic fragmentation on an FFS. 4 Comparison of Allocation Algorithms To compare the FFS disk allocation algorithm to the realloc algorithm, I ran the aging program on two file systems that differed only in the disk allocation algorithm that they used. These tests were performed on the same hardware configuration as the aging verification described in Section 4.3. Only the first 116 days of aging data were used in these tests due to a bug in the realloc algorithm that causes the operating system to panic during the 117th day. I took snapshots during and after the aging of the two file systems and repeated the measurements used in Section 4.3 to compare the file fragmentation generated by the two disk allocation algorithms. Figure 4 graphs layout score as a function of file size on the two file systems. For all file sizes except two block files, the file system that used the realloc algorithm has less fragmentation. This improved layout score is most pronounced for files from 4 to 128 blocks. The layout score of these files is, on average,.62 higher on the file system that used the realloc algorithm. Although the realloc algorithm improved layout scores for most file sizes, small files still exhibit greater fragmentation than large files. To reduce internal file system fragmentation, FFS allows the final block of a 7

8 file to be sub-divided. These sub-divided blocks, called fragments, are allocated using a different disk allocation algorithm than is used for the allocation of full blocks. As a result, the final fragment of a file is seldom allocated contiguously with the previous full block of the file. Since there can only be one fragment per file, and because files of more than 12 blocks never have fragments, the discontiguity of fragments has a larger impact on the layout scores of small files than on big files [12]. 1.8 Layout Score "FFS" "realloc" File Size (in blocks) Figure 4: Comparison of File Fragmentation with Different Allocation Algorithms. This chart plots layout score as a function of file size (expressed in blocks). The FFS line was generated from a snapshot of an aged file system that used the traditional FFS disk allocation algorithm. The realloc line was generated from a snapshot of an aged file system that used McKusick s new realloc disk allocation algorithm. Figure 5 shows the change in aggregate layout score over the course of the 116 day simulation. Again, the file system that used the realloc algorithm has higher layout scores than the file system that used the traditional FFS disk allocation algorithm. The difference in layout score between the two file systems gradually increases throughout the 116 day simulation. At the end of this simulation, the file system that used the realloc algorithm had an aggregate layout score of.94 compared to an aggregate layout score of.91 for the file system that used the FFS disk allocation algorithm. This difference in aggregate layout score is smaller than for many of the file sizes in Figure 4 because aggregate layout score gives extra weight to the layout scores of large files. For files are more than 256 blocks, the realloc algorithm only improved layout scores by an average of.16. While an improvement in layout score of only.3 may seem small, remember that this simulation only aged the test file systems for approximately four months. If the same amount of improvement is seen over the lifetime of a file system, then after two years a file system using the realloc algorithm might have a layout score that is.18 better than a comparable file system that uses the traditional FFS algorithm. A previous study [12] showed that there is a strong correlation between the layout score of files and the file 8

9 system throughput when reading or writing those files. A.18 improvement in layout score should have a measurable impact on file system performance "FFS" "realloc" Figure 5: Aggregate Layout Score Over Time: FFS vs. realloc algorithm. This chart plots aggregate layout score on each of the 116 days of the aging simulation. The FFS line shows the aggregate layout scores on the file system that used the FFS disk allocation algorithm. The realloc line shows the aggregate layout scores on the file system that used McKusick s new realloc allocation algorithm. During the 116 days simulated by the aging workload, the realloc algorithm is able to exploit the clustering of free space on the file system to achieve better file layout then the traditional FFS disk allocation algorithm. The ability of the realloc algorithm to continue to achieve improved file layout is limited by the continued availability of contiguous free space. I have attempted to understand the effects of the two disk allocation algorithms on the organization of free space by performing two measurements on the aged file systems. The first measurement of free space distribution repeats the analysis of free space distribution within the file system cylinder groups that was used to validate the aging process in Section 4.3. Figure 6 shows the distribution of free space within the cylinder groups of the two aged file systems. On both file systems the distribution of free space is skewed toward the ends of the cylinder groups. The file system that used the original FFS disk allocation algorithm has a more skewed distribution than the file system that used the realloc code. It is worth noting that the free space distribution of the aged file system that used the original FFS disk allocation algorithm is more skewed than the distribution seen on a similar file system in Figure 3. This is due to the differing amounts that the two file systems were aged. In Figure 6, the file system was aged for 116 days, at the end of which it was 93% utilized. In contrast, the file system shown in Figure 3 was aged 153 days, at the end of which it was only 82% utilized. Since both file systems were aged using the same 9

10 workload, we can conclude that during the final 37 days of the workload, a large number of files are removed, and that the location of these files was skewed toward the beginning of the disk. Percentage of File System Free Space (cumul.) "FFS" "realloc" Percent Offset in Cylinder Group Figure 6: Free Space Distribution: FFS vs. realloc algorithm. This graph plots the cumulative percentage of file system free space as a function of position within the file system s cylinder groups. The curve labeled FFS was generated from a snapshot of the aged file system that used the FFS disk allocation algorithm. The curve labeled realloc was generated from a snapshot of the aged file system that used McKusick s realloc algorithm. The second measurement of free space distribution examines the clustering of free space on the two file systems. Free space clustering is of vital importance to the long term ability of a disk allocation algorithm to achieve good file layout. If contiguous clusters of free space are not available on the file system, then no disk allocation algorithm will produce well clustered file layouts. To evaluate the clustering of free space, I divided the cylinder groups into ten equal segments. I computed the layout score for all of the free blocks in each segment as if those blocks represented a file. I then averaged the layout scores for all of the first segments in each file system, and for all of the second segments, and so forth. Figure 7 shows the resulting free space layout scores as a function of cylinder group offset. The two file systems have very similar free space fragmentation patterns, especially for the later parts of their cylinder groups. In the first 6% of the cylinder groups, the file system that used the realloc code has slightly lower free space layout scores, indicating that its free space is more fragmented. This occurs because the realloc code does not reuse small clusters of free space as aggressively as the original FFS allocation algorithm. When small files are deleted, they often create small clusters of free space. Under the traditional FFS disk allocation algorithm, these small clusters of free space are often reused for subsequent allocations, even if the new file is large. When McKusick s realloc code is used, 1

11 large files are not forced into these small clusters of free space, whose presence in the aged file system decreases the free space layout score. 1.8 Layout Score "FFS" "realloc" Percentage Offset in Cylinder Group Figure 7: Free Space Fragmentation: FFS vs. realloc. This graph plots free space layout score as a function of cylinder group offset for the two aged file systems. The curve labeled FFS shows the free space layout score of the aged file system that used the original FFS disk allocation algorithm. The curve labeled realloc shows the free space layout score for the aged file system that used McKusick s new realloc code. 5 Conclusions I have developed a heuristic process that uses file system snapshots collected over a long period of time and short term NFS request traces to generate an artificial file system workload that is representative of the actual workload a UNIX file system experiences over five months. Replaying this workload on an empty file system produces a file system that exhibits patterns of file and free space fragmentation that are similar to those observed on the original file system. This artificially aged file system has slightly less file fragmentation and a more even distribution of free space than the authentic five month old file system from which the aging workload was derived. I have used this file system aging technique to compare the long term effects of two different disk allocation algorithms on the amount of fragmentation in an FFS. When compared to the original FFS disk allocation algorithm, the realloc code in Kirk McKusick s new algorithm improves file layout and free space distribution. Mid-sized files (from 4 to 128 blocks) show the greatest improvement in layout. Smaller files do not see much improvement because most of the fragmentation experienced by these files is the result of the FFS fragment allocation policy. Larger files see smaller improvements in layout because the original FFS disk allocation policy typically generates good layout for large files. The improved file layout achieved using McKusick s reallocation algorithm comes at the expense of increased free space fragmentation. After four months of aging, this increased free space fragmentation does not have an adverse effect of file layout. Longer aging studies are needed to determine whether this trade off between good file clustering and good free space clustering can continue to allow improved file layout over the entire lifetime of a file system. 11

12 6 References [1] Bach, M., The Design and Implementation of the UNIX Operating System, Prentice-Hall, Englewood Cliffs, NJ, [2] Baker, M., Hartman, J., Kupfer, M., Shirriff, K., Ousterhout, J., Measurements of a Distributed File System, Proceedings of the Thirteenth Symposium on Operating System Principles, Monterey, CA, October 1991, pp [3] Blackwell, T., Harris, J., Seltzer, M., Heuristic Cleaning Algorithms in Log-Structured File Systems, Proceedings of the 1995 Usenix, New Orleans, LA, January 1995, pp [4] Hitz, D., Lau, J., Malcolm, M., File System Design for an NFS File Server Appliance, Proceedings of the 1994 Winter Usenix, San Francisco, CA, January 1994, pp [5] Leffler, S., McKusick, M., Karels, M., Quarterman, J., The Design and Implementation of the 4.3BSD UNIX Operating System, Addison-Wesley Publishing Company, Reading, MA, [6] McKusick, M., Joy, W., Leffler, S., Fabry, R., A Fast File System for UNIX, ACM Transactions on Computer Systems, Vol. 2, No. 3, August 1984, pp [7] McVoy, L., Kleiman, S., Extent-like Performance from a UNIX File System, Proceedings of the 199 Summer Usenix, Anaheim, CA, June 199, pp [8] Ousterhout, J., Costa, H., Harrison, D., Kunze, J., Kupfer M., Thompson, J., A Trace-Driven Analysis of the UNIX 4.2BSD File System, Proceedings of the Tenth Symposium on Operating System Principles, Orcas Island, WA, December 1985, pp [9] Peacock, J., The Counterpoint Fast File System, Proceedings of the 1988 Winter Usenix, Dallas, TX, February 1988, pp [1] Seltzer, M., Bostic, K., McKusick, M., Staelin, C., The Design and Implementation of the 4.4BSD Log-Structured File System, Proceedings of the 1993 Winter Usenix, San Diego, CA, January [11] Seltzer, M., Smith, K., Balakrishnan, H., Chang, J., McMains, S., Padmanabhan, Venkata, File System Logging Versus Clustering: A Performance Comparison, Proceedings of the 1995 Usenix, New Orleans, LA, January 1995, pp [12] Smith, K., Seltzer, M., File Layout and File System Performance, Harvard University Computer Science Department Technical Report TR