EDBT 2026 Demo / reviewers in the wild / expert
Stan Park
dblp:86/7892
· DBLP profile ↗
6ranked-venue papers
3as first author
0since 2021 · last 2015
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Systems, architecture and hardware · 6 · 3 first-authorDatabases, data management, data science and information retrieval · 3 · 1 first-author
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
5 papers |
Storage systems · 98% Memory systems · 2% | |
| Software engineering, system software, and programming languages
1 paper |
Operating systems · 100% |
Topics — the 11 heaviest of 12, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Storage systems
file systems |
0.4 | 2 | 2015 | Failure-Atomic Updates of Application Data in a Linux File System · FAST 2015 Journaling of journal is (almost) free · FAST 2014 |
Storage systems
i/o scheduling |
0.3 | 2 | 2013 | FlashFQ: A Fair Queueing I/O Scheduler for Flash-Based SSDs · USENIX ATC 2013 FIOS: a fair, efficient flash I/O scheduler · FAST 2012 |
Storage systems › file systems
journaling file system |
0.2 | 1 | 2014 | Journaling of journal is (almost) free · FAST 2014 |
Storage systems › transaction support › transactional storage
failure atomicity |
0.2 | 1 | 2013 | Failure-atomic msync(): a simple and efficient mechanism for preserving the integrity of durable data · EuroSys 2013 |
Storage systems
flash and SSD |
0.2 | 1 | 2013 | FlashFQ: A Fair Queueing I/O Scheduler for Flash-Based SSDs · USENIX ATC 2013 |
Storage systems
key-value storage |
0.2 | 1 | 2013 | Failure-atomic msync(): a simple and efficient mechanism for preserving the integrity of durable data · EuroSys 2013 |
Storage systems
storage reliability |
0.2 | 1 | 2013 | Failure-atomic msync(): a simple and efficient mechanism for preserving the integrity of durable data · EuroSys 2013 |
Storage systems › key-value storage
transactional key-value store |
0.2 | 1 | 2013 | Failure-atomic msync(): a simple and efficient mechanism for preserving the integrity of durable data · EuroSys 2013 |
Storage systems › flash and SSD › flash memory
flash storage |
0.1 | 1 | 2012 | FIOS: a fair, efficient flash I/O scheduler · FAST 2012 |
Storage systems
crash consistency |
0.0 | 1 | 2013 | Failure-atomic msync(): a simple and efficient mechanism for preserving the integrity of durable data · EuroSys 2013 |
Memory systems
fairness and quality of service |
0.0 | 1 | 2013 | FlashFQ: A Fair Queueing I/O Scheduler for Flash-Based SSDs · USENIX ATC 2013 |
Methods — techniques the papers use, named apart from their topics
journaling · 0.2fair queueing · 0.2scheduling · 0.1
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2015 | Failure-Atomic Updates of Application Data in a Linux File System
Rajat Verma, Anton Ajay Mendez, Stan Park, Sandya Mannarswamy, Terence Kelly, Charles B. Morrey III |
FAST | 3 |
| 2014 | Journaling of journal is (almost) free
Stan Park |
FAST | 2 |
| 2013 | Failure-atomic msync(): a simple and efficient mechanism for preserving the integrity of durable dataabstractPreserving the integrity of application data across updates is difficult if power outages and system crashes may occur during updates. Existing approaches such as relational databases and transactional key-value stores restrict programming flexibility by mandating narrow data access interfaces. We have designed, implemented, and evaluated an approach that strengthens the semantics of a standard operating system primitive while maintaining conceptual simplicity and supporting highly flexible programming: Failureatomic msync() commits changes to a memory-mapped file atomically, even in the presence of failures. Our Linux implementation of failure-atomic msync() has preserved application data integrity across hundreds of whole-machine power interruptions and exhibits good microbenchmark performance on both spinning disks and solid-state storage. Failure-atomic msync() supports higher layers of fully general programming abstraction, e.g., a persistent heap that easily slips beneath the C++ Standard Template Library. An STL built atop failure-atomic msync() outperforms several local key-value stores that support transactional updates. We integrated failure-atomic msync() into the Kyoto Tycoon key-value server by modifying exactly one line of code; our modified server reduces response times by 26--43% compared to Tycoon's existing transaction support while providing the same data integrity guarantees. Compared to a Tycoon server setup that makes almost no I/O (and therefore provides no support for data durability and integrity over failures), failure-atomic msync() incurs a three-fold response time increase on a fast Flash-based SSD---an acceptable cost of data reliability for many. Stan Park, Terence Kelly |
EuroSys | 1 |
| 2013 | FlashFQ: A Fair Queueing I/O Scheduler for Flash-Based SSDs
Stan Park |
USENIX ATC | 2 |
| 2012 | FIOS: a fair, efficient flash I/O scheduler
Stan Park |
FAST | 1 |
| 2009 | A performance evaluation of scientific I/O workloads on Flash-based SSDsabstractFlash-based solid state disks (SSDs) are an alternative form of storage device that promises to deliver higher performance than the traditional mechanically rotating hard drives. While SSDs have seen utilization in embedded, consumer, and server computer systems, there has been little understanding of its performance effects with scientific I/O workloads. This paper provides a trace driven performance evaluation of scientific I/O workloads on SSDs. We find that SSDs only provide modest performance gains over mechanical hard drives due to the write-intensive nature of many scientific workloads. Other workloads (like read-mostly web servers) would likely see much larger gains. Additionally, we observe that the concurrent I/O (when multiple parallel processes simultaneously access a single storage device) may significantly affect the SSD performance. However, such effects appear to be dependent on specific SSD implementation features and they are hard to predict in a general fashion. These results suggest that abundant cautions are needed when supporting high-performance scientific I/O workloads on Flash-based SSDs. Stan Park |
CLUSTER | 1 |