Demo Data from EDBT 2026 / reviewers in the wild / expert
Christopher M. Aycock
dblp:49/857
· DBLP profile ↗
2ranked-venue papers
0as first author
0since 2021 · last 1996
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 2Systems, architecture and hardware · 1
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Computer architecture, parallel and distributed computing, and storage systems
1 paper |
Storage systems · 65% Memory systems · 35% | |
| Software engineering, system software, and programming languages
1 paper |
Operating systems · 100% |
Topics — the 6 heaviest of 7, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Storage systems
crash recovery |
0.0 | 1 | 1996 | The Rio File Cache: Surviving Operating System Crashes · ASPLOS 1996 |
Memory systems › cache management › storage caching
file cache |
0.0 | 1 | 1996 | The Rio File Cache: Surviving Operating System Crashes · ASPLOS 1996 |
Storage systems
file systems |
0.0 | 1 | 1996 | The Rio File Cache: Surviving Operating System Crashes · ASPLOS 1996 |
Storage systems
storage reliability |
0.0 | 1 | 1996 | The Rio File Cache: Surviving Operating System Crashes · ASPLOS 1996 |
Memory systems
main memory |
0.0 | 1 | 1996 | The Rio File Cache: Surviving Operating System Crashes · ASPLOS 1996 |
Memory systems › memory architecture
reliable memory |
0.0 | 1 | 1996 | The Rio File Cache: Surviving Operating System Crashes · ASPLOS 1996 |
Methods — techniques the papers use, named apart from their topics
warm reboot · 0.0memory protection · 0.0
| Year | Publication | Venue | Position |
|---|---|---|---|
| 1996 | The Rio File Cache: Surviving Operating System CrashesabstractOne of the fundamental limits to high-performance, high-reliability file systems is memory's vulnerability to system crashes. Because memory is viewed as unsafe, systems periodically write data back to disk. The extra disk traffic lowers performance, and the delay period before data is safe lowers reliability. The goal of the Rio (RAM I/O) file cache is to make ordinary main memory safe for persistent storage by enabling memory to survive operating system crashes. Reliable memory enables a system to achieve the best of both worlds: reliability equivalent to a write-through file cache, where every write is instantly safe, and performance equivalent to a pure write-back cache, with no reliability-induced writes to disk. To achieve reliability, we protect memory during a crash and restore it during a reboot (a "warm" reboot). Extensive crash tests show that even without protection, warm reboot enables memory to achieve reliability close to that of a write-through file system. Adding protection makes memory even safer than a write-through file system while adding essentially no overhead. By eliminating reliability-induced disk writes, Rio performs 4-22 times as fast as a write-through file system, 2-14 times as fast as a standard Unix file system, and 1-3 times as fast as an optimized system that risks losing 30 seconds of data and metadata. Peter M. Chen, Wee Teck Ng, Subhachandra Chandra, Christopher M. Aycock, Gurushankar Rajamani, David E. Lowell |
ASPLOS | 4 |
| 1996 | Comparing disk and memory's resistance to operating system crashesabstractMemory is commonly viewed as an unreliable place to store permanent data (files) because it is perceived to be vulnerable to system crashes. Yet despite all the negative implications of memory's unreliability, no data exists that quantifies how vulnerable memory actually is to system crashes. This paper quantitatively compares the vulnerability of disk and memory to operating system crashes. We use software fault injection to induce a wide variety of operating system crashes in DEC Alpha workstations running Digital Unix, ranging from bit errors in the kernel stack to deleting branch instructions to C-level allocation management errors. We find that files on disk are rarely corrupted (1.1% corruption rate), which agrees with our intuition. We also find that, surprisingly files in memory are nearly as safe as files on disk. Only 10 of the 650 crashes we observed (1.5%) corrupt any files in memory. Our data contradicts the common assumption that operating system crashes often corrupt files in memory and suggests that memory can be used to store permanent data rather than needing to write it back to disk. Wee Teck Ng, Christopher M. Aycock, Gurushankar Rajamani, Peter M. Chen |
ISSRE | 2 |