No abstract

We analyze the I/O behavior of iBench , a new collection of productivity and multimedia application workloads. Our analysis reveals a number of differences between iBench and typical file-system workload studies, including the complex organization of modern files, the lack of pure sequential access, the influence of underlying frameworks on I/O patterns, the widespread use of file synchronization and atomic operations, and the prevalence of threads. Our results have strong ramifications for the design of next generation local and cloud-based storage systems.

Failures, errors, and bugs can corrupt file systems and cause data loss, despite the presence of journals and similar preventive techniques. While consistency checkers such as fsck can detect corruption and repair a damaged image, they are generally created as an afterthought, to be run only at rare intervals. Thus, checkers operate slowly, causing significant downtime for large scale storage systems. We address this dilemma by treating the checker as a key component of the overall file system, rather than a peripheral add-on. To this end, we present a modified ext3 file system, rext 3, to directly support the fast file-system checker, ffsck . Rext3 colocates and self-identifies its metadata blocks, removing the need for costly seeks and tree traversals during checking. These modifications allow ffsck to scan and repair the file system at rates approaching the full sequential bandwidth of the underlying device. In addition, we demonstrate that rext3 generally performs competitively with ext3 and exceeds it in handling random reads and large writes. Finally, we apply our principles to FreeBSD’s FFS file system and its checker, doing so in a lightweight fashion that preserves the file-system layout while still providing some of the performance gains from ffsck.