Persisting OS Final

7/31/2019 Persisting OS Final

1/27

Persisting OS: Grasshopper


2/27

INTRODUCTION

The Computational Model of ConventionalSystems

The Computational Model of PersistentSystemsThe Grasshopper Model


3/27

The Computational Model of Conventional Systems

o Most existing operating systems provide the resourcemanagement, permanent data maintenance, and execution

environment, but there are two common inadequacies:the discontinuity between permanent and temporary dataand lack of resilience to failure.

o The file system is the model for permanent data andvirtual memory is the model for data supported in theexecution environment.


4/27

o Permanent data have to be accessed via the file system,which makes it difficult to maintain complex data

structures like graphs. On the other hand, complex datastructures can be created and manipulated in the virtualmemory but can only persist in the lifetime of theprogram that is creating them .

This creates three major problems for the programmer. One the programmer must know the duration for which the data will persistat design time.


5/27

Secondly, if the data amended in a complex data structure is to be stored inthe permanent storage, the programmer must write code to flatten thedata and as well as code to reload the structure.

Finally, the programmer must work with two different protection models.


6/27

The Computational Modelof Persistent Systems

In persistent operating systems, data is treateduniformly for as long as it persists in the system.

In a persistence system, the programmer does notsee any difference between data in RAM and that in

the secondary storage. This extends the same ideaof virtual memory in that the programmer does notknow what part of the code is in the virtual memoryor in RAM.


7/27

For over 10 years, researchers have been attemptingto construct an operating system that supportsorthogonal persistence. This brings about a two

basic questions.? What is orthogonal persistence??Why does it require support from the operating

system?

There are two basic principles behind orthogonalpersistence:-objects may persist for as long as they are needed in the system orfor as long as they are required.objects may be manipulated uniformly irrespective of the duration

for which they have persisted in the system.


8/27

The support for orthogonal persistence requiresuniform treatment of data structures, data resilience,location independence and protection of data.

Uniform treatment of data means that all datairrespective of how long it has persisted in thesystem should be treated the same. The programmerneed not know how long the data has persisted andthe various mapping since the data is already in the

system.


9/27

As for data resilience, the OS must provide acertain level of resilience from failure. Inconventional OSs like UNIX, a utility like FSCK

may be used to recover data in the stable storage.

Location independence works more or less likethe virtual memory. Programmers do not have to

know the location of the data in order tomanipulate it. All data is accessed in a uniformmanner irrespective of whether it is in the RAMor Disk.


10/27

Persistent systems provide a large store of datamore like a repository, in which all data resideand against which all the processes execute.

This calls for a protection mechanism thatprotects the data from accidental or maliciousmisuse. This is achieved in persistent systemsby Encapsulation and use of capabilities.


11/27

PL

RealWorld

PersistentSystem

RealWorld

DataBase

Traditional Systems Persistent Systems

ADVANTAGES

Reduced complexity in code


12/27

Reduced code size

In a persistent system arbitrary structures can be

preserved between invocations of a program. Thesestructures do not have to be decomposed intosimpler structures to be stored in the long termstorage. This means that references between itemsdo not have to be broken, preserving the referentialintegrity of the data structures.


13/27

Providing Persistence

Persistence can be provided in two fashions:As an application programming environment thatis layered above a separate, possibly non-

persistent, operating system, orby the native operating system.

An example of a language supporting thepersistence paradigm is Napier. Currentnative operating systems that supportpersistence include: Monads, Clouds, Opal,and Mungi.


14/27

Recovery in a Persistent System

In persistent systems it is important that databe preserved across failures. Failures include:Hardware Failures: Disk crashes, machine

crashes, power outages.Software Failures: Operating system bugs,incorrect programs.

These failures can be classed into threecategories: disaster , corrupting , andnoncritical .


15/27

A disaster failure is one that is impossible torecover from without external aid.The destruction of physical hardware such as theCPU or disks would be classified as a disasterfailure.The strategy for recovering from disaster failures isto replace the destroyed hardware and recover thesystem to a previous consistent state by using

backups.It is possible to have standby hardware to allow

automated recovery for disaster failures. Forexample, RAID techniques can provide on-line

backups for single, or limited multiple disk failures.


16/27

A corrupting failure is one in which data iscorrupted or lost.

For example, an unexpected power failure to amachine would result in the loss of the informationin transient storage. To recover from these types of

failures the machine would be shut down, if notalready down, and restarted. The start up codewould reconstruct a previous consistent state andcomputation would progress from that state.


17/27

A non-critical failure is one that can berecovered from without loss of information.

An example of a non-critical failure is abroken network cable. The computationwould halt until the cable is repaired; no datawould be lost, and no recovery step isnecessary by the operating system.


18/27

The Grasshopper Model

Grasshopper is an operating system explicitlydesigned to support orthogonal persistence,and is an attempt to explore some of thepersistent system design space.

The fundamental goal of the Grasshopperproject was to design and develop anoperating system to support orthogonalpersistence across a large network .


19/27

Basic Abstraction of Grasshopper

Containers

Containers are the abstraction over datastorage and access in Grasshopper.

In Grasshopper, containers are mutated byloci, an orthogonal concept. A locus maymove between containers, and a containermay have many loci executing in itsimultaneously.


20/27

Container Mapping Hierarchy


21/27

Loci

A locus is simply the contents of the registers of themachine on which it is executing.

A locus is associated with a container, its hostcontainer. The locus perceives the host containers contents plus any containers mapped by locus privatemappings within its own address space.

Any number of loci may execute within a givencontainer


22/27

Containers, Loci, Invocation


23/27

In Grasshopper a capability refers to a singleentity and contains a set of permissions whichdescribe the access which is permitted usingthat capability.A capability list may be associated with eachlocus and container.A capability is specified by a tuple identifying a

capability list, associated with either the currentlocus or the host container, and the index of thecapability in the list.

oCapabilities


24/27

Managers

In Grasshopper the backing storage for the dataheld in containers is not controlled by the kernel.Instead, user level programs called managers

control the movement of data between backingstore and main memory.

Each container has a manager associated with itwhich, amongst other things, handles the page faultrequests for the containers it manages.


25/27

When a page fault occurs, the kernel traversesthe mapping graph of the faulting locus to

determine which container holds the page. Thekernel then invokes the relevant manager,requesting the page. The manager returns thepage to the kernel which sets up the hardwaretranslation unit to allow the data to beaccessed.


26/27

Managers are also responsible for theresilience of the data in a container. Theyare required to implement a stabilityalgorithm on the data, and, incooperation with the kernel and othermanagers, ensure that consistent data isstored on stable storage.


27/27

THANK YOU ANY QUERIES?

Persisting OS Final

Documents

Transcript of Persisting OS Final