DistOS 2015W Session 3: Difference between revisions

From Soma-notes
Jasons (talk | contribs)
Jasons (talk | contribs)
Line 64: Line 64:


'''Team''': Eric
'''Team''': Eric
*LOCUS was capable of distribute file and processes among the nodes but not the computing power.


= Sprite =
= Sprite =

Revision as of 09:43, 20 April 2015

Multics

Team: Sameer, Shivjot, Ambalica, Veena

It came into being in the 1960s and it completely vanished in 2000s. It was started by Bell, General Electric and MIT but Bell backed out of the project in 1969. Multics is a time sharing OS which provides multitasking and multiprogramming. It is not a distributed OS but it a centralized system which was written in machine-specific assembly.

It provides the following features:

  1. Utility Computing
  2. Access Control Lists
  3. Single level storage
  4. Dynamic linking
    • Sharded libraries or files can be loaded and linked to Random Access Memory at run time
  5. Hot swapping
  6. Multiprocessing System
  7. Ring oriented Security
    • It provides number of levels of authorization within the computer system
    • Still present in some form today, inside both processors (like x86) and operating systems

Unix

Unix in its original conception is a small, minimal API system designed by two guys from Bell Labs. It was essentially an OS that was optimized for the needs of programmers but not much beyond that. The UNIX OS ran on one computer, and terminals ran from that one computer. Thus it is not a distributed operating system as it is centralized and implements time sharing. In fact, it didn't even have support for networking in the first version.

The C language was created specifically for Unix, as the creators wanted to create a machine-agnostic language for the operating system.

Most features from Unix are still available in present day Unix-based systems. For example, the shell, with its piping capabilities, is still used today in its original form.

NFS

NFS is a protocol for working with distributed file systems transparently using RPC. These connections are not secure. Sun wanted to encrypt these RPC connections but encryption would result in government regulations that Sun wanted to avoid in order to sell NFS over seas.

Sun wanted to secure their NFS with encryption, but at the time encryption was regulated like munitions in the United States. Exporting any product that had encryption was impossible, but Sun needed those sales abroad. To avoid these regulations, Sun decided to sell the insecure NFS version of the system.

Team: Mert

  • Sun used "open protocol" approach to develop NFS
    • Simply specified the exact message formats that clients and servers would use to communicate.
    • Different groups could develop their own NFS servers and thus compete in an NFS marketplace.
    • ex. Sun, NetApp, EMC, IBM, etc.
  • NFSv2, simple and fast server crash recovery
    • Any minute that the server is down (or unavailable) makes all the clients unproductive.
    • The protocol is designed to deliver in each protocol request all the information that is needed in order to complete the request.
    • stateless approach: the server does not track anything about what clients are doing
    • no fancy crash recovery is needed, the server just starts running again, and a client, at worst, might have to retry a request.

Locus

  1. Not scalable
    • The synchronization algorithms were so slow, they only managed to run it on five computers
    • Every computer stores a copy of every file
    • Also used CAS to manage files
  2. Not efficient with abstractions
    • Trying to distribute files and processes
  3. Allowed for process migration
  4. Transparency
    • It provided network transparency to “disguise” its distributed context.
  5. Dynamic reconfiguration. (It adapts topology changes.)


Locus has lots of similarities with the today's systems. It uses replication and partitioning which are employed in cloud and distributed systems.

Team: Eric

  • LOCUS was capable of distribute file and processes among the nodes but not the computing power.

Sprite

Team: Jamie, Hassan, Khaled

Sprite had the following Design Features:

  1. Network Transparency
  2. Process Migration, file transfer between computers
    • User could initiate a process migration to an idle machine, and if the machine was no longer idle; due to it being used by another user, the system would take care of the process migration to another machine
  3. Handling Cache Consistency
    • Sequential file sharing ==> By using a version number for each file
    • Concurrent write sharing ==> Disable cache to clients, enable write-blocking and other methods
  4. Implemented a caching system that sped up performance
  5. Implemented a log structured file system
    • They realized that with increasing amounts of RAM in computers which can be used for caching, writes to the disk were the main bottleneck, not reads.
    • Log structured file-systems are optimized for writes, as changes to previous data are appended at the current position.
    • This allows for very fast, sequential writes.
    • Example: SSD (Solid-state disks)

The main features to take away from the Sprite system is that it implemented a log structured file system, and implemented caching to increase performance.