Venti: a new approach to archival storage

This paper describes a network storage system, called
Venti, intended for archival data. In this system, a
unique hash of a block’s contents acts as the block
identifier for read and write operations. This approach
enforces a write-once policy, preventing accidental or
malicious destruction of data. In addition, duplicate
copies of a block can be coalesced, reducing the
consumption of storage and simplifying the
implementation of clients. Venti is a building block for
constructing a variety of storage applications such as
logical backup, physical backup, and snapshot file
systems.
We have built a prototype of the system and present
some preliminary performance results. The system uses
magnetic disks as the storage technology, resulting in
an access time for archival data that is comparable to
non-archival data. The feasibility of the write-once
model for storage is demonstrated using data from over
a decade’s use of two Plan 9 file systems.

Source: https://plan9.io/sys/doc/venti/venti.pdf

Advertisements

The 64-bit Standalone Plan 9 File Server

This paper is a revision of Thompsons The Plan 9 File Server, and
describes the structure and the operation of the new 64-bit Plan 9 file
servers. Some specifics apply to the 32-bit Plan 9 file server Emelie,
which code is also the basis for the user-level file server kfs.
In 2004, Collyer created a 64-bit version of Thompsons 32-bit file
server, updating all file offsets, sizes and block numbers to 64 bits. In
addition, triple- and quadruple-indirect blocks were implemented. File
name components were extended from 27 to 55 bytes. This code is also
the basis for the user-level file server cwfs(4).

Source: https://plan9.io/sys/doc/fs/fs.pdf

Security in Plan 9

The security architecture of the Plan 9″ operating system has
recently been redesigned to address some technical shortcomings. This
redesign provided an opportunity also to make the system more convenient to use securely. Plan 9 has thus improved in two ways not usually
seen together: it has become more secure and easier to use.
The central component of the new architecture is a per-user selfcontained agent called factotum. Factotum securely holds a copy of
the users keys and negotiates authentication protocols, on behalf of the
user, with secure services around the network. Concentrating security
code in a single program offers several advantages including: ease of
update or repair to broken security software and protocols; the ability to
run secure services at a lower privilege level; uniform management of
keys for all services; and an opportunity to provide single sign on, even
to unchanged legacy applications. Factotum has an unusual architecture: it is implemented as a Plan 9 file server.

Source: https://plan9.io/sys/doc/auth.pdf

The Organization of Networks in Plan 9

In a distributed system networks are of paramount importance. This
paper describes the implementation, design philosophy, and organization
of network support in Plan 9. Topics include network requirements for
distributed systems, our kernel implementation, network naming, user
interfaces, and performance. We also observe that much of this organization is relevant to current systems.

Source: https://plan9.io/sys/doc/net/net.pdf

The Use of Name Spaces in Plan 9

Plan 9 is a distributed system built at the Computing Sciences
Research Center of AT&T Bell Laboratories (now Lucent Technologies, Bell
Labs) over the last few years. Its goal is to provide a production-quality
system for software development and general computation using heterogeneous hardware and minimal software. A Plan 9 system comprises CPU
and file servers in a central location connected together by fast networks.
Slower networks fan out to workstation-class machines that serve as user
terminals. Plan 9 argues that given a few carefully implemented abstractions it is possible to produce a small operating system that provides
support for the largest systems on a variety of architectures and networks. The foundations of the system are built on two ideas: a perprocess name space and a simple message-oriented file system protocol.

Source: https://plan9.io/sys/doc/names.pdf

Genode – Genode Operating System Framework

The Genode OS Framework is a tool kit for building highly secure special-purpose operating systems. It scales from embedded systems with as little as 4 MB of memory to highly dynamic general-purpose workloads.

Genode is based on a recursive system structure. Each program runs in a dedicated sandbox and gets granted only those access rights and resources that are needed for its specific purpose. Programs can create and manage sub-sandboxes out of their own resources, thereby forming hierarchies where policies can be applied at each level. The framework provides mechanisms to let programs communicate with each other and trade their resources, but only in strictly-defined manners. Thanks to this rigid regime, the attack surface of security-critical functions can be reduced by orders of magnitude compared to contemporary operating systems.

The framework aligns the construction principles of L4 with Unix philosophy. In line with Unix philosophy, Genode is a collection of small building blocks, out of which sophisticated systems can be composed. But unlike Unix, those building blocks include not only applications but also all classical OS functionalities including kernels, device drivers, file systems, and protocol stacks.

Source: https://genode.org/index