DistOS 2023W 2023-02-06: Difference between revisions
|  Created page with "==Discussion questions==  * Discuss what you think was interesting about Sprite relative to past systems.  What was new?  What was old? * How does AFS compare to NFS, in terms of their design, implementation, and ambition? * What is the role of UNIX in the design and implementation of Sprite and AFS? * What else came to mind when reading and discussing these papers?" | No edit summary | ||
| Line 5: | Line 5: | ||
| * What is the role of UNIX in the design and implementation of Sprite and AFS? | * What is the role of UNIX in the design and implementation of Sprite and AFS? | ||
| * What else came to mind when reading and discussing these papers? | * What else came to mind when reading and discussing these papers? | ||
| ==Notes== | |||
| <pre> | |||
| Sprite and AFS | |||
| -------------- | |||
|  - Sprite is similar to LOCUS in high-level design | |||
|  - but Sprite has optimized for performance in various ways | |||
|    - when migrating processes, only copy pages that you need | |||
|      (if executable is already on other workstation in memory can just use those pages) | |||
|    - caching on both client and server | |||
|    - caching of files in memory (we have more RAM) | |||
|    - efficient distribution of filesystem namespace | |||
|  - still not running on many workstations (100 workstations, 6 servers) | |||
|  - note the tradeoff between RAM and disks | |||
|    - do as much with RAM as possible, just use disks for persistence | |||
|      (very much what we do today) | |||
|  - Sprite seems very familiar because its caching architecture is very much how we do things today | |||
| AFS | |||
|  - Andrew is for Andrew Carnegie, this came out of CMU (Carnegie Mellon Univ) | |||
|  - AFS was trying for web scale before the web | |||
|    - global filesystem | |||
|    - every organization was a "cell" and AFS allowed for inter-cell communication | |||
|    - but authentication normally didn't work outside a cell so you | |||
|      mostly wouldn't see anything except public files | |||
|  - took security seriously, integrated with Kerberos for authentication | |||
|  - takes a very different approach to accessing files | |||
|    - workstation assumed to have a local disk | |||
|    - so on open, a file would be copied to the local disk | |||
|    - all work on the file would happen locally | |||
|    - on close, file would be copied back to the server | |||
|  - quirk of the AFS model - close could fail! | |||
|    - do you check close for failure normally? | |||
| In AFS, the servers are very different from the clients | |||
|  - complex Vice and Venus setup, for managing data blocks and metadata separately | |||
|  - designed for large installations | |||
| AFS workstations couldn't work disconnected, but later systems tried to fix this (Coda, which didn't get that widely used) | |||
| </pre> | |||
Revision as of 16:59, 6 February 2023
Discussion questions
- Discuss what you think was interesting about Sprite relative to past systems. What was new? What was old?
- How does AFS compare to NFS, in terms of their design, implementation, and ambition?
- What is the role of UNIX in the design and implementation of Sprite and AFS?
- What else came to mind when reading and discussing these papers?
Notes
Sprite and AFS
--------------
 - Sprite is similar to LOCUS in high-level design
 - but Sprite has optimized for performance in various ways
   - when migrating processes, only copy pages that you need
     (if executable is already on other workstation in memory can just use those pages)
   - caching on both client and server
   - caching of files in memory (we have more RAM)
   - efficient distribution of filesystem namespace
 - still not running on many workstations (100 workstations, 6 servers)
 - note the tradeoff between RAM and disks
   - do as much with RAM as possible, just use disks for persistence
     (very much what we do today)
 - Sprite seems very familiar because its caching architecture is very much how we do things today
AFS
 - Andrew is for Andrew Carnegie, this came out of CMU (Carnegie Mellon Univ)
 - AFS was trying for web scale before the web
   - global filesystem
   - every organization was a "cell" and AFS allowed for inter-cell communication
   - but authentication normally didn't work outside a cell so you
     mostly wouldn't see anything except public files
 - took security seriously, integrated with Kerberos for authentication
 - takes a very different approach to accessing files
   - workstation assumed to have a local disk
   - so on open, a file would be copied to the local disk
   - all work on the file would happen locally
   - on close, file would be copied back to the server
 - quirk of the AFS model - close could fail!
   - do you check close for failure normally?
In AFS, the servers are very different from the clients
 - complex Vice and Venus setup, for managing data blocks and metadata separately
 - designed for large installations
AFS workstations couldn't work disconnected, but later systems tried to fix this (Coda, which didn't get that widely used)