Demo Data from EDBT 2026 / reviewers in the wild / expert
Swapnil Patil 0001
dblp:09/48-1 · also Swapnil V. Patil
· DBLP profile ↗
6ranked-venue papers
2as first author
0since 2021 · last 2014
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Systems, architecture and hardware · 4 · 2 first-authorComputer networks · 1Software engineering, systems software and programming languages · 1Databases, data management, data science and information retrieval · 1 · 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 · 76% Distributed systems · 11% Memory systems · 10% | |
| Computer networks
2 papers |
Internet architecture and protocols · 59% Transport protocols and congestion control · 41% |
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
distributed file system |
0.3 | 2 | 2014 | IndexFS: Scaling File System Metadata Performance with Stateless Caching and Bulk Insertion · SC 2014 On the duality of data-intensive file system design: reconciling HDFS and PVFS · SC 2011 |
Storage systems › metadata management
metadata scalability |
0.2 | 1 | 2014 | IndexFS: Scaling File System Metadata Performance with Stateless Caching and Bulk Insertion · SC 2014 |
Storage systems › file systems › distributed file system
cloud file system |
0.1 | 1 | 2011 | On the duality of data-intensive file system design: reconciling HDFS and PVFS · SC 2011 |
Distributed systems
concurrency |
0.1 | 1 | 2011 | Scale and Concurrency of GIGA+: File System Directories with Millions of Files · FAST 2011 |
Storage systems
file systems |
0.1 | 1 | 2011 | Scale and Concurrency of GIGA+: File System Directories with Millions of Files · FAST 2011 |
Storage systems › file systems › distributed file system
parallel file system |
0.1 | 1 | 2011 | On the duality of data-intensive file system design: reconciling HDFS and PVFS · SC 2011 |
Memory systems
cache |
0.1 | 1 | 2014 | IndexFS: Scaling File System Metadata Performance with Stateless Caching and Bulk Insertion · SC 2014 |
Memory systems › cache management › storage caching
metadata caching |
0.1 | 1 | 2014 | IndexFS: Scaling File System Metadata Performance with Stateless Caching and Bulk Insertion · SC 2014 |
Transport protocols and congestion control
transport protocols |
0.1 | 1 | 2005 | What the protocol stack missed: the transfer service · SOSP 2005 |
High-performance computing
data-intensive computing |
0.0 | 1 | 2011 | On the duality of data-intensive file system design: reconciling HDFS and PVFS · SC 2011 |
Internet architecture and protocols › protocol design
protocol stack design |
0.0 | 1 | 2005 | What the protocol stack missed: the transfer service · SOSP 2005 |
Methods — techniques the papers use, named apart from their topics
namespace partitioning · 0.2log-structured layout · 0.2bulk insertion · 0.2replication · 0.1performance benchmarking · 0.1directory indexing · 0.1
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2014 | IndexFS: Scaling File System Metadata Performance with Stateless Caching and Bulk InsertionabstractThe growing size of modern storage systems is expected to exceed billions of objects, making metadata scalability critical to overall performance. Many existing distributed file systems only focus on providing highly parallel fast access to file data, and lack a scalable metadata service. In this paper, we introduce a middleware design called Index FS that adds support to existing file systems such as PVFS, Lustre, and HDFS for scalable high-performance operations on metadata and small files. Index FS uses a table-based architecture that incrementally partitions the namespace on a per-directory basis, preserving server and disk locality for small directories. An optimized log-structured layout is used to store metadata and small files efficiently. We also propose two client-based storm free caching techniques: bulk namespace insertion for creation intensive workloads such as N-N check pointing, and stateless consistent metadata caching for hot spot mitigation. By combining these techniques, we have demonstrated Index FS scaled to 128 metadata servers. Experiments show our out-of-core metadata throughput out-performing existing solutions such as PVFS, Lustre, and HDFS by 50% to two orders of magnitude. Kai Ren 0001, Qing Zheng, Swapnil Patil 0001, Garth A. Gibson |
SC | 3 |
| 2011 | YCSB++: benchmarking and performance debugging advanced features in scalable table storesabstractInspired by Google's BigTable, a variety of scalable, semi-structured, weak-semantic table stores have been developed and optimized for different priorities such as query speed, ingest speed, availability, and interactivity. As these systems mature, performance benchmarking will advance from measuring the rate of simple workloads to understanding and debugging the performance of advanced features such as ingest speed-up techniques and function shipping filters from client to servers. This paper describes YCSB++, a set of extensions to the Yahoo! Cloud Serving Benchmark (YCSB) to improve performance understanding and debugging of these advanced features. YCSB++ includes multi-tester coordination for increased load and eventual consistency measurement, multi-phase workloads to quantify the consequences of work deferment and the benefits of anticipatory configuration optimization such as B-tree pre-splitting or bulk loading, and abstract APIs for explicit incorporation of advanced features in benchmark tests. To enhance performance debugging, we customized an existing cluster monitoring tool to gather the internal statistics of YCSB++, table stores, system services like HDFS, and operating systems, and to offer easy post-test correlation and reporting of performance behaviors. YCSB++ features are illustrated in case studies of two BigTable-like table stores, Apache HBase and Accumulo, developed to emphasize high ingest rates and finegrained security. Swapnil Patil 0001, Milo Polte, Kai Ren 0001, Wittawat Tantisiriroj, Julio López 0002, Garth A. Gibson, Adam Fuchs, Billie Rinaldi |
SoCC | 1 |
| 2011 | Scale and Concurrency of GIGA+: File System Directories with Millions of Files
Swapnil Patil 0001, Garth A. Gibson |
FAST | 1 |
| 2011 | On the duality of data-intensive file system design: reconciling HDFS and PVFSabstractData-intensive applications fall into two computing styles: Internet services (cloud computing) or high-performance computing (HPC). In both categories, the underlying file system is a key component for scalable application performance. In this paper, we explore the similarities and differences between PVFS, a parallel file system used in HPC at large scale, and HDFS, the primary storage system used in cloud computing with Hadoop. We integrate PVFS into Hadoop and compare its performance to HDFS using a set of data-intensive computing benchmarks. We study how HDFS-specific optimizations can be matched using PVFS and how consistency, durability, and persistence tradeoffs made by these file systems affect application performance. We show how to embed multiple replicas into a PVFS file, including a mapping with a complete copy local to the writing client, to emulate HDFS's file layout policies. We also highlight implementation issues with HDFS's dependence on disk bandwidth and benefits from pipelined replication. Wittawat Tantisiriroj, Seung Woo Son 0001, Swapnil Patil 0001, Samuel Lang, Garth A. Gibson, Robert B. Ross |
SC | 3 |
| 2006 | An Architecture for Internet Data Transfer
Niraj Tolia, Michael Kaminsky, David G. Andersen, Swapnil Patil 0001 |
NSDI | 4 |
| 2005 | What the protocol stack missed: the transfer serviceabstractThis WIP proposes a new architecture for applications that perform bulk data transfers. This architecture, called DOT (for data-oriented transfer), cleanly separates out two functions that are comingled in today's applications. Using DOT, applications perform content negotiation to determine what content to send. They then pass that data object to the transfer service to perform the actual data transmission. This separation increases application flexibility, enables the rapid development of innovative transfer mechanisms, reduces developer effort, and allows increased efficiency through cross-application sharing. Niraj Tolia, David G. Andersen, Michael Kaminsky, Swapnil Patil 0001 |
SOSP | 4 |