No abstract

No abstract

The viability of storage outsourcing is critically dependent on the access performance of remote storage. We study this issue by measuring the behavior of a broad variety of I/O-intensive benchmarks as they access remote storage over an IP network. We measure the effect of network latencies that correspond to distances ranging from a local neighborhood to halfway across a continent.We then measure the effect of latency-hiding mechanisms. Our results indicate that, in many cases, the adverse effects of network delay can be rendered inconsequential by clever file system and operating system techniques.

No abstract

Senior Member, IEEE AbstractÐToday's file systems are limited in speed and reliability by memory's vulnerability to operating system crashes. Because memory is viewed as unsafe, systems periodically write modified file data back to disk. These extra disk writes lower system performance and the delay period before data is safe lowers reliability. The goal of the Rio (RAM I/O) file cache is to make ordinary main memory safe for persistent storage by enabling memory to survive operating system crashes. Reliable main memory enables the Rio file cache to be as reliable as a write-through file cache, where every write is safe instantly, and as fast as a pure write-back file cache, with no reliability-induced writes to disk. This paper describes the systematic, quantitative process we used to design and verify the Rio file cache on Intel PCs running FreeBSD and the reliability and performance of the resulting system.

Recent results in the Rio project at the University of Michigan show that it is possible to create an area of main memory that is as safe as disk from operating system crashes. This paper explores how to integrate the reliable memory provided by the Rio file cache into a database system. Prior studies have analyzed the performance benefits of reliable memory; we focus instead on how different designs affect reliability. We propose three designs for integrating reliable memory into databases: non-persistent database buffer cache, persistent database buffer cache, and persistent database buffer cache with protection. Non-persistent buffer caches use an I/O interface to reliable memory and require the fewest modifications to existing databases. However, they waste memory capacity and bandwidth due to double buffering. Persistent buffer caches use a memory interface to reliable memory by mapping it into the database address space. This places reliable memory under complete database control and eliminates double buffering, but it may expose the buffer cache to database errors. Our third design reduces this exposure by write protecting the buffer pages. Extensive fault tests show that mapping reliable memory into the database address space does not significantly hurt reliability. This is because wild stores rarely touch dirty, committed pages written by previous transactions. As a result, we believe that databases should use a memory interface to reliable memory.

Appliances are special purpose systems that offer high processing speed, ease of configuration, safety, fault isolation, and minimal need for administration by human experts. Traditional approaches to building an appliance operating system have been either building it from scratch [CacheOS] or stripping down a monolithic kernel to its basic components [Jaeger99]. The former approach is costly and the resulting product is likely to be highly specialized and not easily extensible. The latter approach is not easy, as the OS code and data structures are often shared and closely intertwined. The resulting OS is also likely to be coarse-grained and not easily customizable. Most appliances are network-centric (e.g. HTTP caches, proxies, file servers, routers) in the sense that they require high-performance network connections. Such performance is often achieved with application-specific specialization of system I/O [Cao95] requiring a modification of a portion of the operating system, such as the protocol stack or the file system.Safety is a major concern for appliances, since new functions are constantly added, and there is never enough time to debug all possible interactions, especially when third party software is running on the appliance. The problem is more severe with legacy software written in C or other unsafe languages (in contrast with type-safe languages such as Java). Extensible routers are an example of network appliances where custom software processing has to be quickly added and safety is paramount. Diagnostic code and custom (e.g. multimedia) schedulers are also examples of extensions that appliances will need to support.Resource management is especially important for appliances. New operating system abstractions such as paths [Mosberger96], resource containers [Banga99], reservation domains [Bruno98] and activities [Jones95] have been proposed for resource management and control. We believe that an appliance operating system should be flexible enough to support such abstractions. It should also be able to overlay resource management in modular operating systems without such support.Pebble [Gabber99] is a component-based operating system that combines efficient IPC with strong modularity and safety features. Pebble provides the necessary infrastructure for building fine-grained, modular operating systems for appliances out of reusable components. We found that a typical network appliance application (e.g. a Web server) built on Pebble using components has comparable performance to a traditional monolithic kernel. In this way, there is no performance reason not to use a safer, more modular component structure for such appliances. Moreover, we claim that Pebble is a general purpose operating system framework that allows us to implement diverse OS structures and mechanisms, alleviating the need for writing specialized operating systems from scratch. Challenges and Opportunities in Component-Based SystemsWe believe that fine grain decomposition of system services allows easier specialization and customizat...

--We estimate the availability, reliability, and mean transaction time (response time) for repairable database configurations, centralized or distributed, in which each service component is continuously available for repair. Reliability, the probability that the entire transaction can execute properly without failure, is computed as a function of mean time to failure (MTTF) and mean time to repair (MTTR). Mean transaction time in the system is a function of the mean service delay time for the transaction over all components, plus restart delays due to component failures, plus queuing delays for contention. These estimates are potentially applicable to more generalized distributed systems.