DistOS 2015W Session 5: Difference between revisions
Formatted the clouds section |
Formatted and edited Plan 9 section |
||
Line 37: | Line 37: | ||
= Plan 9 = | = Plan 9 = | ||
Plan 9 is a general purpose, | Plan 9 is a general purpose, multi-user and mobile computing environment physically distributed across machines. Development of the system began in the late 1980s. The system was built at Bell Labs - the birth place of Unix. The original Unix OS had no support for networking, and there were many attempts over the years by others to create distributed systems with Unix compatibility. Plan 9, however, is distributed systems done following the original Unix philosophy. | ||
The | |||
The goals of this system were: | |||
# To built a distributed system that can be centrally administered. | |||
# Be cost effective using cheap, modern microcomputers. | |||
The distribution itself is transparent to most programs. This property is made possible by 2 properties: | |||
# A per process group namespace. | |||
# Uniform access to most resources by representing them as a file. | |||
Plan 9 is divided along the lines of service function. | == Unix Compatibility == | ||
* CPU services and terminals use same kernel | |||
* Users may choose to run programs locally or remotely on CPU servers | The commands, libraries and system calls are similar to that of Unix and therefore a casual user cannot distinguish between these two. The problems in UNIX were too deep to fix but still the various ideas were brought along. The problems addressed badly by UNIX were improved. Old tools were dropped and others were polished and reused. | ||
* | |||
== Unique Features == | |||
What actually distinguishes Plan 9 is its '''organization'''. Plan 9 is divided along the lines of service function. | |||
* CPU services and terminals use same kernel. | |||
* Users may choose to run programs locally or remotely on CPU servers. | |||
* It lets the user choose whether they want a distributed or centralized system. | |||
The design of Plan 9 is based on 3 principles: | The design of Plan 9 is based on 3 principles: | ||
# Resources are named and accessed like files in hierarchical file system. | |||
# Standard protocol 9P. | |||
# Disjoint hierarchical provided by different services are joined together into single private hierarchical file name space. | |||
=== Virtual Namespaces === | |||
In a virtual namespace, a user boots a terminal or connects to a CPU server and then a new process group is created. Processes in group can either add to or rearrange their name space using two system calls - mount and bind. | |||
* '''Mount''' is used to attach new file system to a point in name space. | * '''Mount''' is used to attach new file system to a point in name space. | ||
*'''Bind''' is used to attach a kernel resident file system to name space and also arrange pieces of name space. | * '''Bind''' is used to attach a kernel resident (existing, mounted) file system to name space and also arrange pieces of name space. | ||
* There is also '''unbind''' which undoes the effects of the other two calls. | |||
Namespaces in Plan 9 are on a per-process basis. While everything had a way reference resources with a unique name, using mount and bind, every process could also build their namespace as they saw fit. | |||
'''Parallel Programming | Since most resources are in the form of files (and folders), the term ''namespace'' really only refers to the filesystem layout. | ||
=== Parallel Programming === | |||
The parallel programming has two aspects: | The parallel programming has two aspects: | ||
* Kernel provides simple process model and carefully designed system calls for synchronization. | * Kernel provides simple process model and carefully designed system calls for synchronization. | ||
*Programming language supports concurrent programming. | * Programming language supports concurrent programming. | ||
== Legacy == | |||
'' | Even though Plan 9 is no longer developed, the good ideas from the system still exist today. For example, the ''/proc'' virtual filesystem which displays current process information in the form of files exists in moden Linux kernels. | ||
Revision as of 15:23, 7 February 2015
The Clouds Distributed Operating System
It is a distributed OS running on a set of computers that are interconnected by a group of network. It basically unifies different computers into a single component.
The OS is based on 2 patterns:
- Message Based OS
- Object Based OS
Object Thread Model
The structure of this is based on object thread model. It has set of objects which are defined by the class. Objects respond to messages. Sending message to object causes object to execute the method and then reply back.
The system has active objects and passive objects.
- Active objects are the objects which have one or more processes associated with them and further they can communicate with the external environment.
- Passive objects are those that currently do not have an active thread executing in them.
The content of the Clouds data is long lived. Since the memory is implemented as a single-level store, the data exists forever and can survive system crashes and shut downs.
Threads
The threads are the logical path of execution that traverse objects and executes code in them. The Clouds thread is not bound to a single address space. Several threads can enter an object simultaneously and execute concurrently. The nature of the Clouds object prohibits a thread from accessing any data outside the current address space in which it is executing.
Interaction Between Objects and Threads
- Inter object interfaces are procedural
- Invocations work across machine boundaries
- Objects in clouds unify concept of persistent storage and memory to create address space, thus making the programming simpler.
- Control flow achieved by threads invoking objects.
Clouds Environment
- Integrates set of homogeneous machines into one seamless environment
- There are three logical categories of machines- Compute Server, User Workstation and Data server.
Plan 9
Plan 9 is a general purpose, multi-user and mobile computing environment physically distributed across machines. Development of the system began in the late 1980s. The system was built at Bell Labs - the birth place of Unix. The original Unix OS had no support for networking, and there were many attempts over the years by others to create distributed systems with Unix compatibility. Plan 9, however, is distributed systems done following the original Unix philosophy.
The goals of this system were:
- To built a distributed system that can be centrally administered.
- Be cost effective using cheap, modern microcomputers.
The distribution itself is transparent to most programs. This property is made possible by 2 properties:
- A per process group namespace.
- Uniform access to most resources by representing them as a file.
Unix Compatibility
The commands, libraries and system calls are similar to that of Unix and therefore a casual user cannot distinguish between these two. The problems in UNIX were too deep to fix but still the various ideas were brought along. The problems addressed badly by UNIX were improved. Old tools were dropped and others were polished and reused.
Unique Features
What actually distinguishes Plan 9 is its organization. Plan 9 is divided along the lines of service function.
- CPU services and terminals use same kernel.
- Users may choose to run programs locally or remotely on CPU servers.
- It lets the user choose whether they want a distributed or centralized system.
The design of Plan 9 is based on 3 principles:
- Resources are named and accessed like files in hierarchical file system.
- Standard protocol 9P.
- Disjoint hierarchical provided by different services are joined together into single private hierarchical file name space.
Virtual Namespaces
In a virtual namespace, a user boots a terminal or connects to a CPU server and then a new process group is created. Processes in group can either add to or rearrange their name space using two system calls - mount and bind.
- Mount is used to attach new file system to a point in name space.
- Bind is used to attach a kernel resident (existing, mounted) file system to name space and also arrange pieces of name space.
- There is also unbind which undoes the effects of the other two calls.
Namespaces in Plan 9 are on a per-process basis. While everything had a way reference resources with a unique name, using mount and bind, every process could also build their namespace as they saw fit.
Since most resources are in the form of files (and folders), the term namespace really only refers to the filesystem layout.
Parallel Programming
The parallel programming has two aspects:
- Kernel provides simple process model and carefully designed system calls for synchronization.
- Programming language supports concurrent programming.
Legacy
Even though Plan 9 is no longer developed, the good ideas from the system still exist today. For example, the /proc virtual filesystem which displays current process information in the form of files exists in moden Linux kernels.
Google File System
It is scalable file system for large distributed data intensive applications. The design is driven by providing previous applications workloads and technical environments, both current and anticipated.
The architecture of the Google file system consists of a single master, multiple chunk-servers and multiple clients. These chunk-servers store the data or file in unit of named chunks. Each chunk is identified by globally unique 64 bit chunk handle assigned by master at the end of the time of chunk creation. For more reliability and availability chunks are replicated on more chunk servers. The master maintains all the file system meta data which include the name space, chunk location and also the access control information.
Master and Chunk-Server Communication: a) To check whether there is any chunk-server is down b) To check if any file is corrupted. c) Whether to create or delete any chunk.
Operation of GFS: a) Client communicate with master to get the matadata. b) client get chunk location from matadata. c) Communicate with the one of that chunk-server to retrieve the data to perform operations on it.