Sprite, Amoeba, Clouds - Revision history

Oka: /* Solutions */

2008-02-10T19:26:00Z

Solutions

← Older revision		Revision as of 19:26, 10 February 2008
Line 46:		Line 46:
	* Distributed File Systems		* Distributed File Systems
	* - File Locks		* - File Locks
	* - Metadata servers ~~(*)~~		* - Metadata servers
	* - File versioning / conflict resolution		* - File versioning / conflict resolution
	* Dynamic prefix tables (zones of authority) [name resolution]		* Dynamic prefix tables (zones of authority) [name resolution]
Line 60:		Line 60:
	* multi-cast		* multi-cast
	* lightweight + RPC		* lightweight + RPC

	~~FootNote (*): Ameoba dataserver knew the file and contents, but not the location of the file (directory hierarchy).~~

	===Quotables===		===Quotables===
	'Mainframe is back. It is called "google"'.		'Mainframe is back. It is called "google"'.

Oka at 19:02, 10 February 2008

2008-02-10T19:02:38Z

← Older revision		Revision as of 19:02, 10 February 2008
Line 16:		Line 16:
	# To what extent does their design work in the context of the modern Internet? Discuss wins and limitations.		# To what extent does their design work in the context of the modern Internet? Discuss wins and limitations.
	# What concepts from the paper have been adopted by today's systems? What concepts should be adopted? What should be ignored?		# What concepts from the paper have been adopted by today's systems? What concepts should be adopted? What should be ignored?

			== Putting All Together==
			[''oka's note''] Sorry, I could not put it in a two column tabular format, which could have demonstrated the interaction between the columns better. You might want to consider "reading" it that way, though: For most of the entries in the lists ("problems" and "solutions"), the items in each list are usually related to one-another, in a "leap-frog way" (that is, problem item-i is addressed by solution item-i, which in turn creates/exposes problem item-(i+1), etc.)


			We have discussed a number of systems that have been developed to address certain problems.

			===Problems===
			* Accessing remote files (like local files)
			** File Consistency
			** Uniform Naming
			* Fault Tolerance
			** hot-spots/load distribution
			* '''Performance'''
			* - Slow Kernel Switches
			* - kernel modularity
			* - kernel extensibility
			* - kernel robustness/security
			*'''Security'''
			*'''Manageability'''
			* - inaccessible resources
			* - dangling resources
			*'''Scalability'''
			* - high latency (in communications)
			*Synchronization
			*Legacy Support

			===Solutions===
			* Distributed File Systems
			* - File Locks
			* - Metadata servers (*)
			* - File versioning / conflict resolution
			* Dynamic prefix tables (zones of authority) [name resolution]
			* Redundant Execution
			* Caching
			* - Immutable files
			* - Process migration
			* micro-kernels
			* garbage collection
			* data replication
			* support for parallel processing
			* caching
			* multi-cast
			* lightweight + RPC

			FootNote (*): Ameoba dataserver knew the file and contents, but not the location of the file (directory hierarchy).

			===Quotables===
			'Mainframe is back. It is called "google"'.

Soma at 17:22, 23 January 2008

2008-01-23T17:22:31Z

New page

==Readings==

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-01-28/ousterhout-sprite.pdf John Ousterhout et al., "The Sprite Network Operating System" (1987)]

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-01-28/tanenbaum-amoeba.pdf Andrew Tannenbaum et al., "The Amoeba System" (1990)]

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-01-28/clouds-dasgupta.pdf Partha Dasgupta et al., "The Clouds Distributed Operating System" (1991)]

==Questions to be discussed==

# What did the (technical) world look like when this distributed OS was designed & implemented?
# What are the key design features of the OS? What are the key compromises?
# To what extent is their system a "distributed operating system"?
# What is the basic argument for their design choices? What evidence do they cite in their favor?
# To what extent do you "believe" their design choices were right? Why?
# To what extent does their design work in the context of the modern Internet? Discuss wins and limitations.
# What concepts from the paper have been adopted by today's systems? What concepts should be adopted? What should be ignored?