Demo Data from EDBT 2026 / reviewers in the wild / expert
Pandian Raju
dblp:207/1870
· DBLP profile ↗
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
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Storage systems
crash consistency |
0.7 | 2 | 2019 | 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.6 | 2 | 2018 | 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.4 | 1 | 2019 | CrashMonkey and ACE: Systematically Testing File-System Crash Consistency · ACM Trans. Storage 2019 |
Software testing › system software testing
file system testing |
0.4 | 1 | 2019 | CrashMonkey and ACE: Systematically Testing File-System Crash Consistency · ACM Trans. Storage 2019 |
Software testing
test generation |
0.4 | 1 | 2019 | CrashMonkey and ACE: Systematically Testing File-System Crash Consistency · ACM Trans. Storage 2019 |
Storage systems
file systems |
0.4 | 1 | 2019 | CrashMonkey and ACE: Systematically Testing File-System Crash Consistency · ACM Trans. Storage 2019 |
Storage systems › crash consistency
crash-consistency bug detection |
0.3 | 1 | 2018 | Finding Crash-Consistency Bugs with Bounded Black-Box Crash Testing · OSDI 2018 |
Storage systems
key-value storage |
0.3 | 1 | 2017 | PebblesDB: Building Key-Value Stores using Fragmented Log-Structured Merge Trees · SOSP 2017 |
Storage systems › key-value storage
LSM-tree |
0.3 | 1 | 2017 | 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.3 | 1 | 2017 | PebblesDB: Building Key-Value Stores using Fragmented Log-Structured Merge Trees · SOSP 2017 |
Software testing
black-box testing |
0.1 | 1 | 2018 | Finding Crash-Consistency Bugs with Bounded Black-Box Crash Testing · OSDI 2018 |
Storage systems › storage engine
NoSQL storage engine |
0.1 | 1 | 2017 | 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
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2019 | CrashMonkey and ACE: Systematically Testing File-System Crash ConsistencyabstractWe 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. Storage | 4 |
| 2018 | mLSM: Making Authenticated Storage Faster in Ethereum
Pandian Raju, Soujanya Ponnapalli, Evan Kaminsky, Gilad Oved, Zachary Keener, Vijay Chidambaram, Ittai Abraham |
HotStorage | 1 |
| 2018 | Finding Crash-Consistency Bugs with Bounded Black-Box Crash Testing
Jayashree Mohan, Ashlie Martinez, Soujanya Ponnapalli, Pandian Raju, Vijay Chidambaram |
OSDI | 4 |
| 2017 | PebblesDB: Building Key-Value Stores using Fragmented Log-Structured Merge TreesabstractKey-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 |
SOSP | 1 |