Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Christopher M. Aycock

dblp:49/857 · DBLP profile ↗
← Back
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

TopicWeightPapersLastEvidence papers
Storage systems
crash recovery
0.011996
The Rio File Cache: Surviving Operating System Crashes · ASPLOS 1996
Memory systems › cache management › storage caching
file cache
0.011996
The Rio File Cache: Surviving Operating System Crashes · ASPLOS 1996
Storage systems
file systems
0.011996
The Rio File Cache: Surviving Operating System Crashes · ASPLOS 1996
Storage systems
storage reliability
0.011996
The Rio File Cache: Surviving Operating System Crashes · ASPLOS 1996
Memory systems
main memory
0.011996
The Rio File Cache: Surviving Operating System Crashes · ASPLOS 1996
Memory systems › memory architecture
reliable memory
0.011996
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
YearPublicationVenuePosition
1996 The Rio File Cache: Surviving Operating System Crashes
abstract
One 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
ASPLOS4
1996 Comparing disk and memory's resistance to operating system crashes
abstract
Memory 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
ISSRE2