Pilot

Redell, David D.; Dalal, Yogen K.; Horsley, Thomas R.; Lauer, Hugh C.; Lynch, William C.; McJones, Paul; Murray, Hal; Purcell, S.

doi:10.1145/358818.358822

Cited by 129 publications

(34 citation statements)

References 16 publications

(16 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…For example, most file system superblocks include a "magic number" and some older file systems such as Pilot even include a header per data block [48]. By checking whether a block has the correct type information, a file system can guard against some forms of block corruption.…”

Section: Levels Of Detectionmentioning

confidence: 99%

IRON file systems

Arpaci-Dusseau

Prabhakaran

2005

Proceedings of the Twentieth ACM Symposium on Operating Systems Principles

135

View full text Add to dashboard Cite

Commodity file systems trust disks to either work or fail completely, yet modern disks exhibit more complex failure modes. We suggest a new fail-partial failure model for disks, which incorporates realistic localized faults such as latent sector errors and block corruption. We then develop and apply a novel failure-policy fingerprinting framework, to investigate how commodity file systems react to a range of more realistic disk failures. We classify their failure policies in a new taxonomy that measures their Internal RObustNess (IRON), which includes both failure detection and recovery techniques. We show that commodity file system failure policies are often inconsistent, sometimes buggy, and generally inadequate in their ability to recover from partial disk failures. Finally, we design, implement, and evaluate a prototype IRON file system, Linux ixt3, showing that techniques such as in-disk checksumming, replication, and parity greatly enhance file system robustness while incurring minimal time and space overheads.

show abstract

Section: Levels Of Detectionmentioning

confidence: 99%

IRON file systems

Arpaci-Dusseau

Prabhakaran

2005

Proceedings of the Twentieth ACM Symposium on Operating Systems Principles

135

View full text Add to dashboard Cite

show abstract

“…Singularity differs from other single address operating system, such as Pilot, Cedar, Smalltalk, Lisp Machines, Oberon, or Inferno [12,20,35,39,44], which encouraged sharing objects between processes and did not segregate a process's objects. These systems presented a programming model similar to threads in a process, rather than SIPs' process-like, segmented object spaces.…”

Section: Discussionmentioning

confidence: 99%

Deconstructing process isolation

Aiken

Fähndrich

Hawblitzel

et al. 2006

Proceedings of the 2006 Workshop on Memory System Performance and Correctness

View full text Add to dashboard Cite

Most operating systems enforce process isolation through hardware protection mechanisms such as memory segmentation, page mapping, and differentiated user and kernel instructions. Singularity is a new operating system that uses software mechanisms to enforce process isolation. A software isolated process (SIP) is a process whose boundaries are established by language safety rules and enforced by static type checking. SIPs provide a low cost isolation mechanism that provides failure isolation and fast inter-process communication.To compare the performance of Singularity's SIPs against traditional isolation techniques, we implemented an optional hardware isolation mechanism. Protection domains are hardware-enforced address spaces, which can contain one or more SIPs. Domains can either run at the kernel's privilege level or be fully isolated from the kernel and run at the normal application privilege level. With protection domains, we can construct Singularity configurations that are similar to micro-kernel and monolithic kernel systems. We found that hardware-based isolation incurs non-trivial performance costs (up to 25-33%) and complicates system implementation. Software isolation has less than 5% overhead on these benchmarks.The lower run-time cost of SIPs makes their use feasible at a finer granularity than conventional processes. However, hardware isolation remains valuable as a defense-in-depth against potential failures in software isolation mechanisms. Singularity's ability to employ hardware isolation selectively enables careful balancing of the costs and benefits of each isolation technique.

show abstract

“…For example, SOLO was written in concurrent Pascal instead of assembly [19]. Early work around the Mesa language focused on memory safety through garbage collection, type safety, and modularity as well as features such as coroutines and recursion that would be burdensome to implement without runtime and language support [18,30,35]. The SPIN micro-kernel used Modula-3 to grant application specific extensions to run directly in the kernel to optimize performance [7].…”

Section: Related Workmentioning

confidence: 99%

Language support for fast and reliable message-based communication in singularity OS

Fähndrich

Aiken

Hawblitzel

et al. 2006

SIGOPS Oper. Syst. Rev.

111

180

View full text Add to dashboard Cite

Message-based communication offers the potential benefits of providing stronger specification and cleaner separation between components. Compared with shared-memory interactions, message passing has the potential disadvantages of more expensive data exchange (no direct sharing) and more complicated programming.In this paper we report on the language, verification, and run-time system features that make messages practical as the sole means of communication between processes in the Singularity operating system. We show that using advanced programming language and verification techniques, it is possible to provide and enforce strong system-wide invariants that enable efficient communication and low-overhead software-based process isolation. Furthermore, specifications on communication channels help in detecting programmer mistakes early-namely at compile-time-thereby reducing the difficulty of the message-based programming model.The paper describes our communication invariants, the language and verification features that support them, as well as implementation details of the infrastructure. A number of benchmarks show the competitiveness of this approach.

show abstract

Pilot

Cited by 129 publications

References 16 publications

IRON file systems

IRON file systems

Deconstructing process isolation

Language support for fast and reliable message-based communication in singularity OS

Contact Info

Product

Resources

About