Logging versus Soft Updates: Asynchronous Meta-data Protection in File Systems The Harvard community has made this article openly available. Please share how this access benefits you. Your story matters Citation Seltzer, Margo I., Gregory R. Granger, M. Kirk McKusick, Keith A. Smith, Craig A.N. Soules, and Christopher A. Stein. 1999. Logging versus Soft Updates: Asynchronous Meta-data Protection in File Systems. Harvard Computer Science Group Technical Report TR-07-99. Citable link http://nrs.harvard.edu/urn-3:HUL.InstRepos:24829598 Terms of Use This article was downloaded from Harvard University’s DASH repository, and is made available under the terms and conditions applicable to Other Posted Material, as set forth at http:// nrs.harvard.edu/urn-3:HUL.InstRepos:dash.current.terms-of- use#LAA Logging versus Soft Updates: Asynchronous Meta-data Protection in File Systems Margo I. Seltzer, Gregory R. Ganger, M. Kirk McKusick, Keith A. Smith, Craig A. N. Soules, Christopher A. Stein Abstract or file system improvements are compared to the The UNIX Fast File System (FFS) is probably the performance of some derivative of the 4.2BSD Fast most widely-used file system for performance File System (FFS) [McKusick84]. However, such comparisons. However, such comparisons comparisons ignore significant improvements that frequently overlook many of the performance have been made to FFS during the past decade. enhancements that have been added over the past There are three major performance barriers in decade. In this paper, we explore the two most the original FFS: I/Os are issued in small (i.e., commonly used approaches for improving the block size) units, disk seeks are often required performance of meta-data operations and recovery: between accesses to different files, and meta-data logging and Soft Updates. operations (e.g., creates, deletes) are performed The commercial sector has moved en masse to synchronously. It is frequently argued that large logging file systems, as evidenced by their caches address the issues around read performance presence on nearly every server platform available (small I/Os and seeks between accesses to small today: Solaris, AIX, Digital UNIX, HP-UX, Irix, files), so much of the literature has focused on and Windows NT. On all but Solaris, the default addressing these first two issues in the context of file system uses logging. In the meantime, Soft writes. The first of these barriers (small I/O sizes) Updates holds the promise of providing stronger reliability guarantees than logging, with faster has largely been overcome by clustering sequential recovery and superior performance in certain reads and writes to the same file [Peacock88, boundary cases. McVoy91, Seltzer93]. This solves the problem for large files. Log-structured file systems optimize all In this paper, we explore the benefits of both Soft writes and avoid synchronous meta-data updates Updates and logging, comparing their behavior on both microbenchmarks and workload-based [Rosenblum92]. They also improve read perfor- macrobenchmarks. We find that logging alone is mance when the read pattern matches the write pat- not sufficient to “solve” the meta-data update tern. The Co-locating FFS [Ganger97] solves the problem. If synchronous semantics are required inter-file access problem for both reads and writes (i.e., meta-data operations are durable once the when the data access pattern matches the system call returns), then the logging systems namespace locality; that is, when small files in the cannot realize their full potential. Only when this same directory are accessed together. The synchro- synchronicity requirement is relaxed can logging nous update problem has been addressed most systems approach the performance of systems like directly through logging systems [Hagmann87, Soft Updates. Our asynchronous logging and Soft Chutani92] and Soft Updates systems [Ganger94]. Updates systems perform comparably in most Unfortunately, none of the previous work quanti- cases. While Soft Updates excels in some meta- data intensive microbenchmarks, it outperforms fies how much each of these barriers actually con- logging on only two of the four workloads we tributes to end-to-end application performance. examined and performs less well on one. Furthermore, there is no indication as to which approach, Soft Updates or logging, offers the supe- 1 Introduction rior solution to the synchronous meta-data prob- lem. For the past several decades, a recurring theme In this paper, we focus on the performance in operating system research has been file system impact of synchronous meta-data operations and performance. With the large volume of operating evaluate the alternative solutions to this problem. systems papers that focus on file systems and their In particular, we compare Soft Updates to logging performance, we do not see any change in this under a variety of conditions and find that while trend. Conventionally, any new file system designs their performance is comparable, each provides a different set of semantic guarantees. The contributions of this work are: The design written to disk before which other pieces of data, and evaluation of two logging file systems, both and the system ensures that these ordering con- FFS-compatible; a novel logging architecture straints are met [Ganger94]. This section provides where the log is implemented as a stand-alone file a brief description of Soft Updates; much more system whose services may be used by other file detail can be found in other publications systems or applications apart from the file system; [Ganger95, McKusick99, Ganger00]. and a quantitative comparison between Soft When using Soft Updates to maintain meta- Updates and logging. data consistency, the file system uses delayed The rest of this paper is organized as follows. writes (i.e., write-back caching) for meta-data In Section 2, we discuss how to maintain the integ- changes. Because most meta-data blocks contain rity of file system data structures. In Section 3, we many pointers, cyclic dependencies occur fre- discuss our two logging implementations. In Sec- quently if dependencies are recorded only at the tion 4, we describe our benchmarking methodol- block level. Therefore, Soft Updates tracks depen- ogy and framework. In Section 5, we present our dencies on a per-pointer basis instead. Each block experimental results, and in Section 6 we discuss in the system has a list of all the meta-data depen- related work. In Section 7, we conclude. dencies that are associated with that block. The system is free to use any algorithm it wants to 2 Meta-Data Integrity select the order in which the blocks are written. When the system selects a block to be written, it File system operations can broadly be divided allows the Soft Updates code to review the list of into two categories, data operations and meta-data dependencies associated with that block. If there operations. Data operations act upon actual user are any dependencies that require other blocks to data, reading or writing data from/to files. Meta- be written before the meta-data in the current block data operations modify the structure of the file sys- can be written to disk, then that piece of meta-data tem, creating, deleting, or renaming files, directo- in the current block is rolled back to an earlier, safe ries, or special files (e.g., links, named pipes, etc.). state. When all needed rollbacks are completed, the During a meta-data operation, the system must initially selected block is written to disk. After the ensure that data are written to disk in such a way write has completed, the system deletes any depen- that the file system can be recovered to a consistent dencies that are fulfilled by the write. In addition, state after a system crash. FFS provides this guar- the system restores any rolled back values to their antee by requiring that when an operation (e.g., a current value so that applications inspecting the create) modifies multiple pieces of meta-data, it block will see the value that they expect. This must write those data to disk in a fixed order. (E.g., dependency-required rollback allows the system to Create writes the new inode before writing the break dependency cycles. With Soft Updates, directory that references that inode.) Historically, applications always see the most recent copies of FFS has met this requirement by synchronously meta-data blocks and the disk always sees copies writing each block of meta-data. Unfortunately, that are consistent with its other contents. synchronous writes can significantly impair the Soft Updates rollback operations may cause ability of a file system to achieve high performance more writes than would be minimally required if in the presence of meta-data operations. There has integrity were ignored. Specifically, when an been much effort, in both the research community update dependency causes a rollback of the con- and industry, to remove this performance bottle- tents of an inode or a directory block before a write neck. In the following sections, we discuss some of operation, it must roll the value forward when the the most common approaches to solving the meta- write completes. The effect of doing the roll for- data update problem, beginning with a discussion ward immediately makes the block dirty again. If of Soft Updates [Ganger94] and logging no other changes are made to the block before it is [Hagmann87], the two techniques under analysis again written to the disk, then the roll forward has here. generated an extra write operation that would not otherwise have occurred. To minimize the fre- 2.1 Soft Updates quency of such extra writes, the syncer task and cache reclamation algorithms attempt to write dirty With Soft Updates, systems maintain depen- blocks from the cache in an order that minimizes dency information in memory. This dependency the number of rollbacks Soft Updates incurs.