Thanumalayan Sankaranarayana Pillai

Optimistic crash consistency

We introduce optimistic crash consistency, a new approach to crash consistency in journaling file systems. Using an array of novel techniques, we demonstrate how to build an optimistic commit protocol that correctly recovers from crashes and delivers high performance. We implement this optimistic approach within a Linux ext4 variant which we call OptFS. We introduce two new file-system primitives, osync() and dsync(), that decouple ordering of writes from their durability. We show through experiments that OptFS improves performance for many workloads, sometimes by an order of magnitude; we confirm its correctness through a series of robustness tests, showing it recovers to a consistent state after crashes. Finally, we show that osync() and dsync() are useful in atomic file system and database update scenarios, both improving performance and meeting application-level consistency demands.

WiscKey: Separating Keys from Values in SSD-Conscious Storage

We present WiscKey, a persistent LSM-tree-based key-value store with a performance-oriented data layout that separates keys from values to minimize I/O amplification. The design of WiscKey is highly SSD optimized, leveraging both the sequential and random performance characteristics of the device. We demonstrate the advantages of WiscKey with both microbenchmarks and YCSB workloads. Microbenchmark results show that WiscKey is 2.5×-111× faster than LevelDB for loading a database and 1.6×-14× faster for random lookups. WiscKey is faster than both LevelDB and RocksDB in all six YCSB workloads.

Application Crash Consistency and Performance with CCFS

Recent research has shown that applications often incorrectly implement crash consistency. We present the Crash-Consistent File System (ccfs), a file system that improves the correctness of application-level crash consistency protocols while maintaining high performance. A key idea in ccfs is the abstraction of a stream. Within a stream, updates are committed in program order, improving correctness; across streams, there are no ordering restrictions, enabling scheduling flexibility and high performance. We empirically demonstrate that applications running atop ccfs achieve high levels of crash consistency. Further, we show that ccfs performance under standard file-system benchmarks is excellent, in the worst case on par with the highest performing modes of Linux ext4, and in some cases notably better. Overall, we demonstrate that both application correctness and high performance can be realized in a modern file system.

Crash consistency

The reading and writing of data, one of the most fundamental aspects of any Von Neumann computer, is surprisingly subtle and full of nuance. For example, consider access to a shared memory in a system with multiple processors. While a simple and intuitive approach known as strong consistency is easiest for programmers to understand, many weaker models are in widespread use (e.g., x86 total store ordering); such approaches improve system performance, but at the cost of making reasoning about system behavior more complex and error-prone. Fortunately, a great deal of time and effort has gone into thinking about such memory models, and, as a result, most multiprocessor applications are not caught unaware.

How file systems differ, why this affects application-level consistency, and what we can do about it

Many applications have consistency mechanisms that allow them to recover after a power failure or a system crash. Such mechanisms inherently depend on some behaviors of the underlying file system. These file system behaviors are often misunderstood, and more importantly, differ between file systems. In our research, we studied six (single-node) Linux file systems, so as to understand their behavior. We also studied eleven widely-used applications (including key-value stores and virtualization software) to understand whether their consistency mechanisms were correct. The tool we developed for studying applications (named ALICE) finds crash vulnerabilities, i.e., places where an applications consistency mechanism depends on behaviors obeyed by only some file systems. We found 60 vulnerabilities in the applications, by assuming a file system that has particularly bad behavior (from the perspective of the applications); 30 of those vulnerabilities are exposed when assuming popular, widely-used file systems. We are now focusing our efforts on making application-level consistency work, without affecting performance, and without requiring an application programmer to change much of the existing code.