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

Muthukaruppan Annamalai

dblp:45/3276 · DBLP profile ↗
← Back
3ranked-venue papers
1as first author
0since 2021 · last 2018
—ORCID · none

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

Software engineering, systems software and programming languages · 2 · 1 first-authorSystems, architecture and hardware · 1

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
2 papers
Storage systems · 69% Cloud and datacenter computing · 21% Distributed systems · 10%
Software engineering, system software, and programming languages
2 papers
Operating systems · 100%

Topics — the 4 heaviest of 5, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Storage systems
distributed storage
0.312018
Sharding the Shards: Managing Datastore Locality at Scale with Akkio · OSDI 2018
Operating systems › i/o › i/o subsystem
device drivers
0.122006
Recovering device drivers · ACM Trans. Comput. Syst. 2006
Recovering Device Drivers (Awarded Best Paper!) · OSDI 2004
Cloud and datacenter computing
cluster resource management and scheduling
0.112018
Sharding the Shards: Managing Datastore Locality at Scale with Akkio · OSDI 2018
Distributed systems
fault tolerance
0.012004
Recovering Device Drivers (Awarded Best Paper!) · OSDI 2004

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

sharding · 0.3shadow driver · 0.1fault injection · 0.1
YearPublicationVenuePosition
2018 Sharding the Shards: Managing Datastore Locality at Scale with Akkio
Muthukaruppan Annamalai, Kaushik Ravichandran 0003, Harish Srinivas, Igor Zinkovsky, Luning Pan, Tony Savor, David Nagle, Michael Stumm
OSDI1
2006 Recovering device drivers
abstract
This article presents a new mechanism that enables applications to run correctly when device drivers fail. Because device drivers are the principal failing component in most systems, reducing driver-induced failures greatly improves overall reliability. Earlier work has shown that an operating system can survive driver failures [Swift et al. 2005], but the applications that depend on them cannot. Thus, while operating system reliability was greatly improved, application reliability generally was not.To remedy this situation, we introduce a new operating system mechanism called ashadow driver. A shadow driver monitors device drivers and transparently recovers from driver failures. Moreover, it assumes the role of the failed driver during recovery. In this way, applications using the failed driver, as well as the kernel itself, continue to function as expected.We implemented shadow drivers for the Linux operating system and tested them on over a dozen device drivers. Our results show that applications and the OS can indeed survive the failure of a variety of device drivers. Moreover, shadow drivers impose minimal performance overhead. Lastly, they can be introduced with only modest changes to the OS kernel and with no changes at all to existing device drivers.
Michael M. Swift, Muthukaruppan Annamalai, Brian N. Bershad, Henry M. Levy
ACM Trans. Comput. Syst.2
2004 Recovering Device Drivers (Awarded Best Paper!)
Michael M. Swift, Muthukaruppan Annamalai, Brian N. Bershad, Henry M. Levy
OSDI2