Specifying and Checking File System Crash-Consistency Models

Abstract

Applications depend on persistent storage to recover state after system crashes. But the POSIX file system interfaces do not define the possible outcomes of a crash. As a result, it is difficult for application writers to correctly understand the ordering of and dependencies between file system operations, which can lead to corrupt application state and, in the worst case, catastrophic data loss.This paper presents crash-consistency models, analogous to memory consistency models, which describe the behavior of a file system across crashes. Crash-consistency models include both litmus tests, which demonstrate allowed and forbidden behaviors, and axiomatic and operational specifications. We present a formal framework for developing crash-consistency models, and a toolkit, called FERRITE, for validating those models against real file system implementations. We develop a crash-consistency model for ext4, and use FERRITE to demonstrate unintuitive crash behaviors of the ext4 implementation. To demonstrate the utility of crashconsistency models to application writers, we use our models to prototype proof-of-concept verification and synthesis tools, as well as new library interfaces for crash-safe applications.

Understanding configuration dependencies of file systems

“…Moreover, we have found one Reliability of File Systems. Great efforts have been made to improve the reliability of file systems [3,22,35,39,51] and their utilities [27,28,30,56,57]. For example, Prabhakaran et al [51] analyze the failure policies of four file systems and propose improved designs based on the IRON taxonomy; Spiffy [56] creates an annotation language for developing correct utilities; SQCK [30] and RFSCK [27] improve file system checkers to avoid inaccurate fixes.…”