Drew Schleit

dblp:304/2733 · DBLP profile ↗
← Back
1ranked-venue papers
0as first author
1since 2021 · last 2021
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 1 · 1 since 2021

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 · 100%
Software engineering, system software, and programming languages
1 paper
Program verification · 100%

Topics — the 4 heaviest of 4, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Storage systems
crash consistency
0.512021
Using Lightweight Formal Methods to Validate a Key-Value Storage Node in Amazon S3 · SOSP 2021
Storage systems
key-value storage
0.512021
Using Lightweight Formal Methods to Validate a Key-Value Storage Node in Amazon S3 · SOSP 2021
Storage systems
storage reliability
0.512021
Using Lightweight Formal Methods to Validate a Key-Value Storage Node in Amazon S3 · SOSP 2021
Program verification
lightweight formal methods
0.112021
Using Lightweight Formal Methods to Validate a Key-Value Storage Node in Amazon S3 · SOSP 2021

Methods — techniques the papers use, named apart from their topics

model checking · 1.0lightweight formal methods · 1.0
YearPublicationVenuePosition
2021 Using Lightweight Formal Methods to Validate a Key-Value Storage Node in Amazon S3
abstract
This paper reports our experience applying lightweight formal methods to validate the correctness of ShardStore, a new key-value storage node implementation for the Amazon S3 cloud object storage service. By "lightweight formal methods" we mean a pragmatic approach to verifying the correctness of a production storage node that is under ongoing feature development by a full-time engineering team. We do not aim to achieve full formal verification, but instead emphasize automation, usability, and the ability to continually ensure correctness as both software and its specification evolve over time. Our approach decomposes correctness into independent properties, each checked by the most appropriate tool, and develops executable reference models as specifications to be checked against the implementation. Our work has prevented 16 issues from reaching production, including subtle crash consistency and concurrency problems, and has been extended by non-formal-methods experts to check new features and properties as ShardStore has evolved.
James Bornholt, Rajeev Joshi, Vytautas Astrauskas, Brendan Cully, Bernhard Kragl, Seth Markle, Kyle Sauri, Drew Schleit, Grant Slatton, Serdar Tasiran, Jacob Van Geffen, Andy Warfield
SOSP8