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

Pandian Raju

dblp:207/1870 · DBLP profile ↗
← Back
4ranked-venue papers
2as first author
0since 2021 · last 2019
—ORCID · none

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

Systems, architecture and hardware · 2 · 1 first-authorSoftware engineering, systems software and programming languages · 2 · 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
3 papers
Storage systems · 100%
Software engineering, system software, and programming languages
2 papers
Software testing · 100%

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

TopicWeightPapersLastEvidence papers
Storage systems
crash consistency
0.722019
CrashMonkey and ACE: Systematically Testing File-System Crash Consistency · ACM Trans. Storage 2019
Finding Crash-Consistency Bugs with Bounded Black-Box Crash Testing · OSDI 2018
Storage systems
storage reliability
0.622018
Finding Crash-Consistency Bugs with Bounded Black-Box Crash Testing · OSDI 2018
PebblesDB: Building Key-Value Stores using Fragmented Log-Structured Merge Trees · SOSP 2017
Software testing › system software testing
crash consistency testing
0.412019
CrashMonkey and ACE: Systematically Testing File-System Crash Consistency · ACM Trans. Storage 2019
Software testing › system software testing
file system testing
0.412019
CrashMonkey and ACE: Systematically Testing File-System Crash Consistency · ACM Trans. Storage 2019
Software testing
test generation
0.412019
CrashMonkey and ACE: Systematically Testing File-System Crash Consistency · ACM Trans. Storage 2019
Storage systems
file systems
0.412019
CrashMonkey and ACE: Systematically Testing File-System Crash Consistency · ACM Trans. Storage 2019
Storage systems › crash consistency
crash-consistency bug detection
0.312018
Finding Crash-Consistency Bugs with Bounded Black-Box Crash Testing · OSDI 2018
Storage systems
key-value storage
0.312017
PebblesDB: Building Key-Value Stores using Fragmented Log-Structured Merge Trees · SOSP 2017
Storage systems › key-value storage
LSM-tree
0.312017
PebblesDB: Building Key-Value Stores using Fragmented Log-Structured Merge Trees · SOSP 2017
Storage systems › flash and SSD › flash memory management › garbage collection
write amplification
0.312017
PebblesDB: Building Key-Value Stores using Fragmented Log-Structured Merge Trees · SOSP 2017
Software testing
black-box testing
0.112018
Finding Crash-Consistency Bugs with Bounded Black-Box Crash Testing · OSDI 2018
Storage systems › storage engine
NoSQL storage engine
0.112017
PebblesDB: Building Key-Value Stores using Fragmented Log-Structured Merge Trees · SOSP 2017

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

record and replay · 0.8bounded black-box testing · 0.8
YearPublicationVenuePosition
2019 CrashMonkey and ACE: Systematically Testing File-System Crash Consistency
abstract
We present C rash M onkey and A ce , a set of tools to systematically find crash-consistency bugs in Linux file systems. C rash M onkey is a record-and-replay framework which tests a given workload on the target file system by simulating power-loss crashes while the workload is being executed, and checking if the file system recovers to a correct state after each crash. A ce automatically generates all the workloads to be run on the target file system. We build C rash M onkey and A ce based on a new approach to test file-system crash consistency: bounded black-box crash testing ( B 3 ). B 3 tests the file system in a black-box manner using workloads of file-system operations. Since the space of possible workloads is infinite, B 3 bounds this space based on parameters such as the number of file-system operations or which operations to include, and exhaustively generates workloads within this bounded space. B 3 builds upon insights derived from our study of crash-consistency bugs reported in Linux file systems in the last 5 years. We observed that most reported bugs can be reproduced using small workloads of three or fewer file-system operations on a newly created file system, and that all reported bugs result from crashes after fsync()-related system calls. C rash M onkey and A ce are able to find 24 out of the 26 crash-consistency bugs reported in the last 5 years. Our tools also revealed 10 new crash-consistency bugs in widely used, mature Linux file systems, 7 of which existed in the kernel since 2014. Additionally, our tools found a crash-consistency bug in a verified file system, FSCQ. The new bugs result in severe consequences like broken rename atomicity, loss of persisted files and directories, and data loss.
Jayashree Mohan, Ashlie Martinez, Soujanya Ponnapalli, Pandian Raju, Vijay Chidambaram
ACM Trans. Storage4
2018 mLSM: Making Authenticated Storage Faster in Ethereum
Pandian Raju, Soujanya Ponnapalli, Evan Kaminsky, Gilad Oved, Zachary Keener, Vijay Chidambaram, Ittai Abraham
HotStorage1
2018 Finding Crash-Consistency Bugs with Bounded Black-Box Crash Testing
Jayashree Mohan, Ashlie Martinez, Soujanya Ponnapalli, Pandian Raju, Vijay Chidambaram
OSDI4
2017 PebblesDB: Building Key-Value Stores using Fragmented Log-Structured Merge Trees
abstract
Key-value stores such as LevelDB and RocksDB offer excellent write throughput, but suffer high write amplification. The write amplification problem is due to the Log-Structured Merge Trees data structure that underlies these key-value stores. To remedy this problem, this paper presents a novel data structure that is inspired by Skip Lists, termed Fragmented Log-Structured Merge Trees (FLSM). FLSM introduces the notion of guards to organize logs, and avoids rewriting data in the same level. We build PebblesDB, a high-performance key-value store, by modifying HyperLevelDB to use the FLSM data structure. We evaluate PebblesDB using micro-benchmarks and show that for write-intensive workloads, PebblesDB reduces write amplification by 2.4-3x compared to RocksDB, while increasing write throughput by 6.7x. We modify two widely-used NoSQL stores, MongoDB and HyperDex, to use PebblesDB as their underlying storage engine. Evaluating these applications using the YCSB benchmark shows that throughput is increased by 18-105% when using PebblesDB (compared to their default storage engines) while write IO is decreased by 35-55%.
Pandian Raju, Rohan Kadekodi, Vijay Chidambaram, Ittai Abraham
SOSP1