Verifying a high-performance crash-safe file system using a tree specification

Abstract

DFSCQ is the first file system that (1) provides a precise specification for fsync and fdatasync, which allow applications to achieve high performance and crash safety, and (2) provides a machine-checked proof that its implementation meets this specification. DFSCQ's specification captures the behavior of sophisticated optimizations, including logbypass writes, and DFSCQ's proof rules out some of the common bugs in file-system implementations despite the complex optimizations. The key challenge in building DFSCQ is to write a specification for the file system and its internal implementation without exposing internal file-system details. DFSCQ introduces a metadata-prefix specification that captures the properties of fsync and fdatasync, which roughly follows the behavior of Linux ext4. This specification uses a notion of tree sequences-logical sequences of file-system tree states-for succinct description of the possible states after a crash and to describe how data writes can be reordered with respect to metadata updates. This helps application developers prove the crash safety of their own applications, avoiding application-level bugs such as forgetting to invoke fsync on both the file and the containing directory. An evaluation shows that DFSCQ achieves 103 MB/s on large file writes to an SSD and durably creates small files at a rate of 1,618 files per second. This is slower than Linux ext4 (which achieves 295 MB/s for large file writes and 4,977 files/s for small file creation) but much faster than two recent verified file systems, Yggdrasil and FSCQ. Evaluation results from application-level benchmarks, including TPC-C on SQLite, mirror these microbenchmarks.

QED at Large: A Survey of Engineering of Formally Verified Software

“…Verification has also reached file systems, such as FSCQ (Chen et al, 2015), a file system with guarantees about crash safety that have been verified in Coq, and DFSCQ (Chen et al, 2017), an efficient crashsafe file system with several verified optimizations. Using the Cogent Why Proof Engineering Matters language and its certifying compiler (Section 3.1.1), Amani et al (2016) developed a file system called BilbyFS in Isabelle/HOL with executable code in C; they also implemented and verified the legacy Linux file system ext2.…”

Argosy: verifying layered storage systems with recovery refinement

“…There are several existing systems that support reasoning about crashes and recovery, particularly in the context of file-system verification [7,8,11,26,28]. Most have no support for layered recovery, since they consider only a single recovery procedure at a time.…”

“…To prove recovery refinement within a single layer, Argosy supports a variant of Crash Hoare Logic (CHL), the logic used in the FSCQ verified file system [7,8]. Argosy generalizes FSCQ's CHL by supporting non-deterministic crash behavior, whereas FSCQ modeled only persistent state and assumed it was unaffected by a crash.…”

“…These examples are intended to illustrate how CHL enables recovery reasoning within Argosy for individual refinements. The logging design we use is comparable to the log used in the original FSCQ paper [8] and in Yggdrasil [28], although it is simplified compared to the followup system DFSCQ [7] or the journaling in Linux's ext4 file system. We believe both implementations demonstrate the main issues that arise in crash and recovery reasoning and that Argosy could be used to verify designs that give better performance with more engineering work.…”

CrashMonkey and ACE

“…Thus, given a set of constraints, Ace generates an exhaustive set of workloads, each of which is tested with CrashMonkey on the target file system. B 3 offers a new point in the spectrum of techniques addressing file-system crash consistency, alongside verified file systems [12,13,82] and model checking [94,95]. Unlike these approaches, B 3 targets widely deployed file systems written in low-level languages, and does not require annotating or modifying file-system code.…”