Stan Park

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

TopicWeightPapersLastEvidence papers
Storage systems
file systems
0.422015
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.322013
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.212014
Journaling of journal is (almost) free · FAST 2014
Storage systems › transaction support › transactional storage
failure atomicity
0.212013
Failure-atomic msync(): a simple and efficient mechanism for preserving the integrity of durable data · EuroSys 2013
Storage systems
flash and SSD
0.212013
FlashFQ: A Fair Queueing I/O Scheduler for Flash-Based SSDs · USENIX ATC 2013
Storage systems
key-value storage
0.212013
Failure-atomic msync(): a simple and efficient mechanism for preserving the integrity of durable data · EuroSys 2013
Storage systems
storage reliability
0.212013
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.212013
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.112012
FIOS: a fair, efficient flash I/O scheduler · FAST 2012
Storage systems
crash consistency
0.012013
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.012013
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
YearPublicationVenuePosition
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
FAST3
2014 Journaling of journal is (almost) free
Stan Park
FAST2
2013 Failure-atomic msync(): a simple and efficient mechanism for preserving the integrity of durable data
abstract
Preserving 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
EuroSys1
2013 FlashFQ: A Fair Queueing I/O Scheduler for Flash-Based SSDs
Stan Park
USENIX ATC2
2012 FIOS: a fair, efficient flash I/O scheduler
Stan Park
FAST1
2009 A performance evaluation of scientific I/O workloads on Flash-based SSDs
abstract
Flash-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
CLUSTER1