Soma-notes - User contributions [en]

WebOS, PlanetLab, Starfish

2008-03-19T19:55:49Z

Jmahonin: /* Learning from PlanetLab */

==Readings==

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-03-17/vahat-webos-hpdc98.pdf Amin Vahat et al., "WebOS: Operating System Services for Wide Area Applications" (1998)]

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-03-17/starfish.pdf Adnan Agbaria and Roy Friedman, "Starﬁsh: Fault-Tolerant Dynamic MPI Programs on Clusters of Workstations" (2003)]

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-03-17/peterson-planetlab-osdi06.pdf Larry Peterson et al., "Experiences Building PlanetLab" (2006)]

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-03-17/anderson-planetlab-learning.pdf Thomas Anderson and Timothy Roscoe, "Learning from PlanetLab" (2006)]

----

== WebOS ==

=== Key features ===
* High Availability
* Lower Latency
* Fault Tolerance

Consensus: WebOS isn't really an distributed OS

=== Main components ===
* Smart Client
* WebFS
* Global naming scheme based on URLs
* Process control system
* CRISIS authentication/authorization system (Certificates with ACLs)

=== Key ideas that were/were not not adopted from WebFS ===

Adopted:
* General idea of wide area dynamic distribution -> Akamai (but primarily for static content)
* Global naming using URLs

Not Adopted:
* CRISIS
* WebFS (Although WebDAV could be said to be related)
* Smart client (for web sites)

=== What are the pros and cons of using smart clients to do load balancing? ===

Pro:
* Distributes computation
* More flexible

Con:
* Vulnerable to Denial of Service or other forms of attacks
* Extra network overhead to locate a service

== Starfish ==

=== Key features ===
===== MPI =====
* Fast message passing
* Allows the programmers more control
===== OCaml =====
====== Pros ======
* Recursive algorithms
* Uses Bytecodes - portable in theory
* Same code on heterogenous hardware
* Well known language
====== Cons ======
* Slow performance?
* Not entirely portable, maybe Just-In-Time?
==== Checkpointing ====
* Save / resume state
* Provides process migration
* Maybe better suited to be implemented in the application, not OS?
==== Management ====
* Had a Java interface which allowed any node to login and see full system status
* Used the distributed nature of daemons to communicate this information

== Experiences Building PlanetLab ==
=== Key ideas ===
* Global platform to distribute/test network services
* Scale
* Should be able to monitor and stop disruptive traffic
=== Challenges ===
* Resource allocation is significant, especially in a distributed system such as PlanetLab
* Providing a global platform for long-term services
* Implementing a trust relationship between node owners and service developers (users)
=== PLC ===
==== Summary ====
* Fulfills the trust mechanism required for the network
* Acts as a middle man / mediator between node owners and users
* If someone breaks into the PLC however, entire system is compromised
==== Implementation ====
* Nodes are split into slices using VServers, lightweight process groups
==== Criticisms ====
* Bandwidth allocation was slice-based, not node based

== Learning from PlanetLab==
=== Centralized Trusts ===
==== Pro ====
* Easier to manage, one entity to trust
==== Con ====
* One point of control, no competition as to who to trust

=== Centralized resource control ===
==== Pro ====
* All resources are controlled by PLC
==== Con ====
* No incentive for users or administrators to conservce resources

=== Decentralized management ===
==== Pro ====
* Provide bare-bones management, try to foster competition between 3rd party services
==== Con ====
* No motivation to do so, it's hard work

=== Treat bandwidth as free ===
==== Pro ====
* Free bandwidth!
==== Con ====
* No incentive to conserve bandwidth

=== Provide only best-effort service ===
==== Pro ====
* No limit on the number of processes which can be run
==== Con ====
* Other processes may crowd out computation of other processes (cpu/disk hogging)

=== Linux is the execution environment ===
==== Pro ====
* Provides a familiar programming environment
==== Con ====
* Weak isolation between experiments
* No global allocation for resources
* Having a homogenous test-bed is poor for distributed experimentation

=== Don't provide distributed OS services ===
==== Pro ====
*
==== Con ====
*

=== Evolve the API ===
==== Pro ====
* Adaptable API, ground-up
==== Con ====
* Never had a good API, inconsistent, ever changing, unstable programming environment

=== Focus on the machine room ===
==== Pro ====
* Allocate big machine here, other there, etc...
==== Con ====
* Bad for distributed OSes

WebOS, PlanetLab, Starfish

2008-03-19T19:55:11Z

Jmahonin: /* Learning from PlanetLab */

==Readings==

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-03-17/vahat-webos-hpdc98.pdf Amin Vahat et al., "WebOS: Operating System Services for Wide Area Applications" (1998)]

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-03-17/starfish.pdf Adnan Agbaria and Roy Friedman, "Starﬁsh: Fault-Tolerant Dynamic MPI Programs on Clusters of Workstations" (2003)]

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-03-17/peterson-planetlab-osdi06.pdf Larry Peterson et al., "Experiences Building PlanetLab" (2006)]

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-03-17/anderson-planetlab-learning.pdf Thomas Anderson and Timothy Roscoe, "Learning from PlanetLab" (2006)]

----

== WebOS ==

=== Key features ===
* High Availability
* Lower Latency
* Fault Tolerance

Consensus: WebOS isn't really an distributed OS

=== Main components ===
* Smart Client
* WebFS
* Global naming scheme based on URLs
* Process control system
* CRISIS authentication/authorization system (Certificates with ACLs)

=== Key ideas that were/were not not adopted from WebFS ===

Adopted:
* General idea of wide area dynamic distribution -> Akamai (but primarily for static content)
* Global naming using URLs

Not Adopted:
* CRISIS
* WebFS (Although WebDAV could be said to be related)
* Smart client (for web sites)

=== What are the pros and cons of using smart clients to do load balancing? ===

Pro:
* Distributes computation
* More flexible

Con:
* Vulnerable to Denial of Service or other forms of attacks
* Extra network overhead to locate a service

== Starfish ==

=== Key features ===
===== MPI =====
* Fast message passing
* Allows the programmers more control
===== OCaml =====
====== Pros ======
* Recursive algorithms
* Uses Bytecodes - portable in theory
* Same code on heterogenous hardware
* Well known language
====== Cons ======
* Slow performance?
* Not entirely portable, maybe Just-In-Time?
==== Checkpointing ====
* Save / resume state
* Provides process migration
* Maybe better suited to be implemented in the application, not OS?
==== Management ====
* Had a Java interface which allowed any node to login and see full system status
* Used the distributed nature of daemons to communicate this information

== Experiences Building PlanetLab ==
=== Key ideas ===
* Global platform to distribute/test network services
* Scale
* Should be able to monitor and stop disruptive traffic
=== Challenges ===
* Resource allocation is significant, especially in a distributed system such as PlanetLab
* Providing a global platform for long-term services
* Implementing a trust relationship between node owners and service developers (users)
=== PLC ===
==== Summary ====
* Fulfills the trust mechanism required for the network
* Acts as a middle man / mediator between node owners and users
* If someone breaks into the PLC however, entire system is compromised
==== Implementation ====
* Nodes are split into slices using VServers, lightweight process groups
==== Criticisms ====
* Bandwidth allocation was slice-based, not node based

== Learning from PlanetLab==
=== Centralized Trusts ===
==== Pro ====
* Easier to manage, one entity to trust
==== Con ====
* One point of control, no competition as to who to trust

=== Centralized resource control ===
==== Pro ====
* All resources are controlled by PLC
==== Con ====
* No incentive for users or administrators to conservce resources

=== Decentralized management ===
==== Pro ====
* Provide bare-bones management, try to foster competition between 3rd party services
==== Con ====
* No motivation to do so, it's hard work

=== Treat bandwidth as free ===
==== Pro ====
* Free bandwidth!
==== Con ====
* No incentive to conserve bandwidth

=== Provide only best-effort service ===
==== Pro ====
* No limit on the number of processes which can be run
==== Con ====
* Other processes may crowd out computation of other processes (cpu/disk hogging)

=== Linux is the execution environment ===
==== Pro ====
* Provides a familiar programming environment
==== Con ====
* Weak isolation between experiments
* No global allocation for resources
* Having a homogenous test-bed is poor for distributed experimentation

=== Don't provide distributed OS services ===
==== Pro ====
*
==== Con ====
*

=== Evolve the API ===
==== Pro ====
* Adaptable API, ground-up
==== Con ====
* Never had a good API, inconsistent, ever changing, unstable programming environment

=== Focus on the machine room
==== Pro ====
* Allocate big machine here, other there, etc...
==== Con ====
* Bad for distributed OSes

WebOS, PlanetLab, Starfish

2008-03-19T19:50:08Z

Jmahonin: /* Learning from PlanetLab */

==Readings==

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-03-17/vahat-webos-hpdc98.pdf Amin Vahat et al., "WebOS: Operating System Services for Wide Area Applications" (1998)]

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-03-17/starfish.pdf Adnan Agbaria and Roy Friedman, "Starﬁsh: Fault-Tolerant Dynamic MPI Programs on Clusters of Workstations" (2003)]

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-03-17/peterson-planetlab-osdi06.pdf Larry Peterson et al., "Experiences Building PlanetLab" (2006)]

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-03-17/anderson-planetlab-learning.pdf Thomas Anderson and Timothy Roscoe, "Learning from PlanetLab" (2006)]

----

== WebOS ==

=== Key features ===
* High Availability
* Lower Latency
* Fault Tolerance

Consensus: WebOS isn't really an distributed OS

=== Main components ===
* Smart Client
* WebFS
* Global naming scheme based on URLs
* Process control system
* CRISIS authentication/authorization system (Certificates with ACLs)

=== Key ideas that were/were not not adopted from WebFS ===

Adopted:
* General idea of wide area dynamic distribution -> Akamai (but primarily for static content)
* Global naming using URLs

Not Adopted:
* CRISIS
* WebFS (Although WebDAV could be said to be related)
* Smart client (for web sites)

=== What are the pros and cons of using smart clients to do load balancing? ===

Pro:
* Distributes computation
* More flexible

Con:
* Vulnerable to Denial of Service or other forms of attacks
* Extra network overhead to locate a service

== Starfish ==

=== Key features ===
===== MPI =====
* Fast message passing
* Allows the programmers more control
===== OCaml =====
====== Pros ======
* Recursive algorithms
* Uses Bytecodes - portable in theory
* Same code on heterogenous hardware
* Well known language
====== Cons ======
* Slow performance?
* Not entirely portable, maybe Just-In-Time?
==== Checkpointing ====
* Save / resume state
* Provides process migration
* Maybe better suited to be implemented in the application, not OS?
==== Management ====
* Had a Java interface which allowed any node to login and see full system status
* Used the distributed nature of daemons to communicate this information

== Experiences Building PlanetLab ==
=== Key ideas ===
* Global platform to distribute/test network services
* Scale
* Should be able to monitor and stop disruptive traffic
=== Challenges ===
* Resource allocation is significant, especially in a distributed system such as PlanetLab
* Providing a global platform for long-term services
* Implementing a trust relationship between node owners and service developers (users)
=== PLC ===
==== Summary ====
* Fulfills the trust mechanism required for the network
* Acts as a middle man / mediator between node owners and users
* If someone breaks into the PLC however, entire system is compromised
==== Implementation ====
* Nodes are split into slices using VServers, lightweight process groups
==== Criticisms ====
* Bandwidth allocation was slice-based, not node based

== Learning from PlanetLab==
=== Centralized Trusts ===
==== Pro ====
* Easier to manage, one entity to trust
==== Con ====
* One point of control, no competition as to who to trust

=== Centralized resource control ===
==== Pro ====
* All resources are controlled by PLC
==== Con ====
* No incentive for users or administrators to conservce resources

=== Decentralized management ===
==== Pro ====
* Provide bare-bones management, try to foster competition between 3rd party services
==== Con ====
* No motivation to do so, it's hard work

=== Treat bandwidth as free ===
==== Pro ====
* Free bandwidth!
==== Con ====
* No incentive to conserve bandwidth

=== Provide only best-effort service ===
==== Pro ====
* No limit on the number of processes which can be run
==== Con ====
* Other processes may crowd out computation of other processes (cpu/disk hogging)

=== Linux is the execution environment ===
==== Pro ====
* Provides a familiar programming environment
==== Con ====
* Weak isolation between experiments
* Having a homogenous test-bed is poor for distributed experimentation
*

WebOS, PlanetLab, Starfish

2008-03-19T19:42:11Z

Jmahonin: /* Learning from PlanetLab */

==Readings==

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-03-17/vahat-webos-hpdc98.pdf Amin Vahat et al., "WebOS: Operating System Services for Wide Area Applications" (1998)]

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-03-17/starfish.pdf Adnan Agbaria and Roy Friedman, "Starﬁsh: Fault-Tolerant Dynamic MPI Programs on Clusters of Workstations" (2003)]

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-03-17/peterson-planetlab-osdi06.pdf Larry Peterson et al., "Experiences Building PlanetLab" (2006)]

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-03-17/anderson-planetlab-learning.pdf Thomas Anderson and Timothy Roscoe, "Learning from PlanetLab" (2006)]

----

== WebOS ==

=== Key features ===
* High Availability
* Lower Latency
* Fault Tolerance

Consensus: WebOS isn't really an distributed OS

=== Main components ===
* Smart Client
* WebFS
* Global naming scheme based on URLs
* Process control system
* CRISIS authentication/authorization system (Certificates with ACLs)

=== Key ideas that were/were not not adopted from WebFS ===

Adopted:
* General idea of wide area dynamic distribution -> Akamai (but primarily for static content)
* Global naming using URLs

Not Adopted:
* CRISIS
* WebFS (Although WebDAV could be said to be related)
* Smart client (for web sites)

=== What are the pros and cons of using smart clients to do load balancing? ===

Pro:
* Distributes computation
* More flexible

Con:
* Vulnerable to Denial of Service or other forms of attacks
* Extra network overhead to locate a service

== Starfish ==

=== Key features ===
===== MPI =====
* Fast message passing
* Allows the programmers more control
===== OCaml =====
====== Pros ======
* Recursive algorithms
* Uses Bytecodes - portable in theory
* Same code on heterogenous hardware
* Well known language
====== Cons ======
* Slow performance?
* Not entirely portable, maybe Just-In-Time?
==== Checkpointing ====
* Save / resume state
* Provides process migration
* Maybe better suited to be implemented in the application, not OS?
==== Management ====
* Had a Java interface which allowed any node to login and see full system status
* Used the distributed nature of daemons to communicate this information

== Experiences Building PlanetLab ==
=== Key ideas ===
* Global platform to distribute/test network services
* Scale
* Should be able to monitor and stop disruptive traffic
=== Challenges ===
* Resource allocation is significant, especially in a distributed system such as PlanetLab
* Providing a global platform for long-term services
* Implementing a trust relationship between node owners and service developers (users)
=== PLC ===
==== Summary ====
* Fulfills the trust mechanism required for the network
* Acts as a middle man / mediator between node owners and users
* If someone breaks into the PLC however, entire system is compromised
==== Implementation ====
* Nodes are split into slices using VServers, lightweight process groups
==== Criticisms ====
* Bandwidth allocation was slice-based, not node based

== Learning from PlanetLab==
=== Centralized Trusts ===
==== Pro ====
* Easier to manage, one entity to trust
==== Con ====
* One point of control, no competition as to who to trust

=== Centralized resource control ===
==== Pro ====
* All resources are controlled by PLC
==== Con ====
* No incentive for users or administrators to conservce resources

=== Decentralized management ===
==== Pro ====
* Provide bare-bones management, try to foster competition between 3rd party services
==== Con ====
* No motivation to do so, it's hard work

=== Treat bandwidth as free ===
==== Pro ====
* Free bandwidth!
==== Con ====
* No incentive to conserve bandwidth

=== Provide only best-effort service ===
=== Pro ===
* No limit on the number of processes which can be run
=== Con ===
* Other processes may crowd out computation of other processes

WebOS, PlanetLab, Starfish

2008-03-19T19:40:05Z

Jmahonin: /* PlanetLab Learning */

==Readings==

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-03-17/vahat-webos-hpdc98.pdf Amin Vahat et al., "WebOS: Operating System Services for Wide Area Applications" (1998)]

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-03-17/starfish.pdf Adnan Agbaria and Roy Friedman, "Starﬁsh: Fault-Tolerant Dynamic MPI Programs on Clusters of Workstations" (2003)]

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-03-17/peterson-planetlab-osdi06.pdf Larry Peterson et al., "Experiences Building PlanetLab" (2006)]

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-03-17/anderson-planetlab-learning.pdf Thomas Anderson and Timothy Roscoe, "Learning from PlanetLab" (2006)]

----

== WebOS ==

=== Key features ===
* High Availability
* Lower Latency
* Fault Tolerance

Consensus: WebOS isn't really an distributed OS

=== Main components ===
* Smart Client
* WebFS
* Global naming scheme based on URLs
* Process control system
* CRISIS authentication/authorization system (Certificates with ACLs)

=== Key ideas that were/were not not adopted from WebFS ===

Adopted:
* General idea of wide area dynamic distribution -> Akamai (but primarily for static content)
* Global naming using URLs

Not Adopted:
* CRISIS
* WebFS (Although WebDAV could be said to be related)
* Smart client (for web sites)

=== What are the pros and cons of using smart clients to do load balancing? ===

Pro:
* Distributes computation
* More flexible

Con:
* Vulnerable to Denial of Service or other forms of attacks
* Extra network overhead to locate a service

== Starfish ==

=== Key features ===
===== MPI =====
* Fast message passing
* Allows the programmers more control
===== OCaml =====
====== Pros ======
* Recursive algorithms
* Uses Bytecodes - portable in theory
* Same code on heterogenous hardware
* Well known language
====== Cons ======
* Slow performance?
* Not entirely portable, maybe Just-In-Time?
==== Checkpointing ====
* Save / resume state
* Provides process migration
* Maybe better suited to be implemented in the application, not OS?
==== Management ====
* Had a Java interface which allowed any node to login and see full system status
* Used the distributed nature of daemons to communicate this information

== Experiences Building PlanetLab ==
=== Key ideas ===
* Global platform to distribute/test network services
* Scale
* Should be able to monitor and stop disruptive traffic
=== Challenges ===
* Resource allocation is significant, especially in a distributed system such as PlanetLab
* Providing a global platform for long-term services
* Implementing a trust relationship between node owners and service developers (users)
=== PLC ===
==== Summary ====
* Fulfills the trust mechanism required for the network
* Acts as a middle man / mediator between node owners and users
* If someone breaks into the PLC however, entire system is compromised
==== Implementation ====
* Nodes are split into slices using VServers, lightweight process groups
==== Criticisms ====
* Bandwidth allocation was slice-based, not node based

== Learning from PlanetLab==
=== Centralized Trusts ===
==== Pro ====
* Easier to manage, one entity to trust
==== Con ====
* One point of control, no competition as to who to trust

=== Centralized resource control ===
==== Pro ====
* All resources are controlled by PLC
==== Con ====
* No incentive for users or administrators to conservce resources

=== Decentralized management ===
==== Pro ====
* Provide bare-bones management, try to foster competition between 3rd party services
==== Con =====
* No motivation to do so, it's hard work

=== Treat bandwidth as free ===
==== Pro ====
* Free bandwidth!
==== Con =====
* No incentive to conserve bandwidth

=== Provide only best-effort service ===
=== Pro ===

=== Con ===

WebOS, PlanetLab, Starfish

2008-03-19T19:27:27Z

Jmahonin: /* Experiences Building PlanetLab */

WebOS, PlanetLab, Starfish

2008-03-19T19:13:31Z

Jmahonin: /* PlanetLab */

WebOS, PlanetLab, Starfish

2008-03-19T19:03:29Z

Jmahonin:

WebOS, PlanetLab, Starfish

2008-03-19T19:00:29Z

Jmahonin: /* Starfish */

WebOS, PlanetLab, Starfish

2008-03-19T18:56:46Z

Jmahonin: /* Starfish */

WebOS, PlanetLab, Starfish

2008-03-19T18:45:40Z

Jmahonin: /* Key features */

WebOS, PlanetLab, Starfish

2008-03-19T18:40:51Z

Jmahonin: /* WebOS */

NASD, GoogleFS, Farsite

2008-03-12T18:39:28Z

Jmahonin: /* Questions for Farsite */

==Readings==

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-03-10/gibson-nasd.pdf Garth A. Gibson et al., "A Cost-Effective, High-Bandwidth Storage Architecture" (1998)]

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-03-10/gfs-sosp2003.pdf Sanjay Ghemawat et al., "The Google File System" (2003)]

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-03-10/adya-farsite-intro.pdf Atul Adya et al.,"FARSITE: Federated, Available, and Reliable Storage for an Incompletely Trusted Environment" (2002)]

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-03-10/bolosky-farsite-retro.pdf William J. Bolosky et al., "The Farsite Project: A Retrospective" (2007)]

==Questions==

# What were the target environments for these filesystems? How did these environments shape their assumptions?
# What are the key ideas behind each filesystem?
# What are the strengths and weaknesses of each design?
# What are the strengths and weaknesses of each implementation?
# Which system is best suited for today's Internet? How about tomorrow's?

==Questions for NASD==
# Is giving direct access between client and drive a good idea?
# Are there substantial advantages in storing variable-length objects over fixed-sized blocks?
# Is putting the filesystem on the drive a good idea? Should more control and awareness be given to hardware devices?
# What are the strengths and weaknesses of the capability-based cryptography which NASD makes use of?

==Questions for GoogleFS==
# How does the Google file system implement security?
# Is using a central server (point of access) a good design decision?
# Is removing random writes a good idea?
# Is the speedup attained by GFS's record-append method worth the sacrifice of Application overhead?

==Questions for Farsite==
# Byzantine fault tolerance?
# How similar and different compared to OceanStore?
# What's up with the file lease mechanism?

==Questions for Farsite retrospective==
# If using different programming methods... how does this file-system work given different programming models
# Details of buyzantine fault tolerance

DSM Review, NFS, AFS

2008-02-13T20:34:05Z

Jmahonin: /* In Class Notes */

==Readings==

* [http://homeostasis.scs.carleton.ca/~soma/distos/2008-02-11/protic-overview.pdf Jelica Protic et al., "Distributed Shared Memory: Concepts and Systems" (1996)] This paper reviews work in the area of distributed shared memory.

* [http://homeostasis.scs.carleton.ca/~soma/distos/2008-02-11/sandberg-nfs.pdf Russel Sandberg et al., "Design and Implementation of the Sun Network Filesystem" (1985)] This is the original NFS paper.

* [http://homeostasis.scs.carleton.ca/~soma/distos/2008-02-11/howard-afs.pdf John H. Howard et al., "Scale and Performance in a Distributed File System" (1988)] This paper describes AFS and compares it to NFS.

==Questions==

For the Protic paper, consider the following:
# What were the major problems addressed in DSM research following Kai Li's dissertation?
# Did these advances change the scope of environments and problems appropriate for DSM?
# Why aren't DSM systems commonly in use today?

For the NFS and AFS papers, consider these questions:
# What were the key design goals of NFS and AFS?
# How well did they achieve their goals?
# What are their limitations?
# How suitable are NFS and AFS in modern small networks? Enterprise networks? Internet-scale applications? Why?

== In Class Notes ==
=== Goals of NFS and AFS ===
==== NFS ====
* Remote access like local access
* Scale to ~50 clients
* Portability
* Lightweight

==== AFS ====
* Remote access like local access
* Scale to 5000 - 10000 hosts
* Portability (POSIX)

=== Differences ===
==== NFS ====
# NFS does a system call for every read/write
# NFS can operate with diskless clients
# Lightweight clients
# Files are up-to-date, can be inconsistent
# Trusted clients
# Stateless

==== AFS ====
# AFS does a system call only on retrieving and storing a file
# AFS assumes clients have a hard disk
# Heavier-weight client
# Files may be stale, but data is consistent
# Untrusted clients
# Stateful

=== Contributions ===
==== NFS ====
* Kmalloc
* VFS
* (XDR, SunRPC)

=== Aside: Kerberos for Dummies ===
<pre>
1. Client Identification: <client> ==> <kerberos>
2. Client Request Ticket: <client> <== <kerberos>
3. Authenticate with Ticket: <client> ==> <server>
</pre>

DSM Review, NFS, AFS

2008-02-13T20:14:23Z

Jmahonin: /* In Class Notes */

==Readings==

* [http://homeostasis.scs.carleton.ca/~soma/distos/2008-02-11/protic-overview.pdf Jelica Protic et al., "Distributed Shared Memory: Concepts and Systems" (1996)] This paper reviews work in the area of distributed shared memory.

* [http://homeostasis.scs.carleton.ca/~soma/distos/2008-02-11/sandberg-nfs.pdf Russel Sandberg et al., "Design and Implementation of the Sun Network Filesystem" (1985)] This is the original NFS paper.

* [http://homeostasis.scs.carleton.ca/~soma/distos/2008-02-11/howard-afs.pdf John H. Howard et al., "Scale and Performance in a Distributed File System" (1988)] This paper describes AFS and compares it to NFS.

==Questions==

For the Protic paper, consider the following:
# What were the major problems addressed in DSM research following Kai Li's dissertation?
# Did these advances change the scope of environments and problems appropriate for DSM?
# Why aren't DSM systems commonly in use today?

For the NFS and AFS papers, consider these questions:
# What were the key design goals of NFS and AFS?
# How well did they achieve their goals?
# What are their limitations?
# How suitable are NFS and AFS in modern small networks? Enterprise networks? Internet-scale applications? Why?

== In Class Notes ==
=== Goals of NFS and AFS ===
==== NFS ====
* Remote access like local access
* Scale to ~50 clients
* Portability
* Lightweight

==== AFS ====
* Remote access like local access
* Scale to 5000 - 10000 hosts
* Portability (POSIX)

=== Differences ===
==== NFS ====
# NFS does a system call for every read/write
# NFS can operate with diskless clients
# Lightweight clients
# Files are up-to-date, can be inconsistent
# Trusted clients

==== AFS ====
# AFS does a system call only on retrieving and storing a file
# AFS assumes clients have a hard disk
# Heavier-weight client
# Files may be stale, but data is consistent
# Untrusted clients

=== Aside: Kerberos for Dummies ===
<pre>
1. Client Identification: <client> ==> <kerberos>
2. Client Request Ticket: <client> <== <kerberos>
3. Authenticate with Ticket: <client> ==> <server>
</pre>

DSM Review, NFS, AFS

2008-02-13T19:57:47Z

Jmahonin:

==Readings==

* [http://homeostasis.scs.carleton.ca/~soma/distos/2008-02-11/protic-overview.pdf Jelica Protic et al., "Distributed Shared Memory: Concepts and Systems" (1996)] This paper reviews work in the area of distributed shared memory.

* [http://homeostasis.scs.carleton.ca/~soma/distos/2008-02-11/sandberg-nfs.pdf Russel Sandberg et al., "Design and Implementation of the Sun Network Filesystem" (1985)] This is the original NFS paper.

* [http://homeostasis.scs.carleton.ca/~soma/distos/2008-02-11/howard-afs.pdf John H. Howard et al., "Scale and Performance in a Distributed File System" (1988)] This paper describes AFS and compares it to NFS.

==Questions==

For the Protic paper, consider the following:
# What were the major problems addressed in DSM research following Kai Li's dissertation?
# Did these advances change the scope of environments and problems appropriate for DSM?
# Why aren't DSM systems commonly in use today?

For the NFS and AFS papers, consider these questions:
# What were the key design goals of NFS and AFS?
# How well did they achieve their goals?
# What are their limitations?
# How suitable are NFS and AFS in modern small networks? Enterprise networks? Internet-scale applications? Why?

== In Class Notes ==
=== Goals of NFS and AFS ===

====NFS====
* Remote access like local access
* Scale to ~50 clients
* Portability
* Lightweight

====AFS====
* Seamless
* Scale to 5000 - 10000 hosts
* Portability (POSIX)

=== Differences ===

====NFS====
# NFS does a system call for every read/write
# NFS can operate with diskless clients
# Lightweight clients

====AFS====
# AFS does a system call only on retrieving and storing a file
# AFS assumes clients have a hard disk
# Heavier-weight client

DSM Review, NFS, AFS

2008-02-13T19:55:28Z

Jmahonin: /* Goals of NFS and AFS */

==Readings==

* [http://homeostasis.scs.carleton.ca/~soma/distos/2008-02-11/protic-overview.pdf Jelica Protic et al., "Distributed Shared Memory: Concepts and Systems" (1996)] This paper reviews work in the area of distributed shared memory.

* [http://homeostasis.scs.carleton.ca/~soma/distos/2008-02-11/sandberg-nfs.pdf Russel Sandberg et al., "Design and Implementation of the Sun Network Filesystem" (1985)] This is the original NFS paper.

* [http://homeostasis.scs.carleton.ca/~soma/distos/2008-02-11/howard-afs.pdf John H. Howard et al., "Scale and Performance in a Distributed File System" (1988)] This paper describes AFS and compares it to NFS.

==Questions==

For the Protic paper, consider the following:
# What were the major problems addressed in DSM research following Kai Li's dissertation?
# Did these advances change the scope of environments and problems appropriate for DSM?
# Why aren't DSM systems commonly in use today?

For the NFS and AFS papers, consider these questions:
# What were the key design goals of NFS and AFS?
# How well did they achieve their goals?
# What are their limitations?
# How suitable are NFS and AFS in modern small networks? Enterprise networks? Internet-scale applications? Why?

== Goals of NFS and AFS==

===NFS===
* Remote access like local access
* Scale to ~50 clients
* Portability
* Lightweight

===AFS===
* Seamless
* Scale to 5000 - 10000 hosts
* Portability (POSIX)

== Differences ==

===NFS===
# NFS does a system call for every read/write
# NFS can operate with diskless clients

===AFS===
# AFS does a system call only on retrieving and storing a file
# AFS assumes clients have a hard disk

DSM Review, NFS, AFS

2008-02-13T19:50:50Z

Jmahonin: