<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://homeostasis.scs.carleton.ca/wiki/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Ambalica</id>
	<title>Soma-notes - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://homeostasis.scs.carleton.ca/wiki/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Ambalica"/>
	<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php/Special:Contributions/Ambalica"/>
	<updated>2026-05-12T16:40:54Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.42.1</generator>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_9&amp;diff=20168</id>
		<title>DistOS 2015W Session 9</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_9&amp;diff=20168"/>
		<updated>2015-04-09T23:08:31Z</updated>

		<summary type="html">&lt;p&gt;Ambalica: /* BOINC */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== BOINC ==&lt;br /&gt;
&lt;br /&gt;
*Public Resource Computing Platform&lt;br /&gt;
*Gives scientists the ability to use large amounts of computation resources.&lt;br /&gt;
*The clients do not connect directly with each other but instead they talk to a central server located at Berkley&lt;br /&gt;
*The goals of Boinc are: &lt;br /&gt;
:*1) reduce the barriers of entry&lt;br /&gt;
:*2) Share resources among autonomous projects&lt;br /&gt;
:*3) Support diverse applications&lt;br /&gt;
:*4) Reward participants.&lt;br /&gt;
:*5) Provide screensaver graphics&lt;br /&gt;
&lt;br /&gt;
*It can run as applications in common language with no modifications&lt;br /&gt;
*A BOINC application can be identified by a single master URL, which serves as the homepage as well as the directory of the servers.&lt;br /&gt;
*Servers perform set of function using:&lt;br /&gt;
**Scheduling servers: handles Remote Procedure Call from clients&lt;br /&gt;
** Data servers:helps to manage the uploads&lt;br /&gt;
&lt;br /&gt;
== SETI@Home ==&lt;br /&gt;
&lt;br /&gt;
*Uses public resource computing to analyze radio signals to find extraterrestrial intelligence&lt;br /&gt;
*Need good quality telescope to search for radio signals, and lots of computational power, which was unavailable locally&lt;br /&gt;
*It has not yet found extraterrestrial intelligence, but its has established credibility of public resource computing projects&lt;br /&gt;
*Originally custom, now uses BOINC as a backbone for the project&lt;br /&gt;
*Uses relational database to store information on a large scale, further it uses a multi-threaded server to distribute work to clients&lt;br /&gt;
*Quality of data in this architecture is untrustworthy, the main incentive to use it, however, is that it is a cheap and easy way of scaling the work exponentially.&lt;br /&gt;
*Provided social incentives to encourage users to join the system.&lt;br /&gt;
*This computation model still exists but not in the legitimate world.&lt;br /&gt;
*Formed a good concept of public resource computing and a distributed computing by providing a platform independent framework&lt;br /&gt;
&lt;br /&gt;
== MapReduce ==&lt;br /&gt;
&lt;br /&gt;
*A programming model presented by Google to do large scale parallel computations&lt;br /&gt;
*Uses the &amp;lt;code&amp;gt;Map()&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;Reduce()&amp;lt;/code&amp;gt; functions from functional style programming languages&lt;br /&gt;
:*Map (Filtering)&lt;br /&gt;
::*Takes a function and applies it to a bunch of keys to produce values&lt;br /&gt;
* Hides parallelization, fault tolerance, locality optimization and load balancing&lt;br /&gt;
:*Reduce (Summary)&lt;br /&gt;
::*Accumulates results from the data set using a given function&lt;br /&gt;
* Very easy to use and understand, with many classic problems fitting this pattern&lt;br /&gt;
* Otherwise quite constrained in what exactly can be done&lt;br /&gt;
* Uses hashing to distribute similar keys to similar machines, but otherwise spread the load&lt;br /&gt;
&lt;br /&gt;
== Naiad ==&lt;br /&gt;
&lt;br /&gt;
*A programming model similar to &amp;lt;code&amp;gt;MapReduce&amp;lt;/code&amp;gt; but with streaming capabilities so that data results are almost instantaneous&lt;br /&gt;
*A distributed system for executing data parallel cyclic dataflow programs offering high throughput and low latency&lt;br /&gt;
*Aims to provide a general purpose system which will fulfill the requirements and the will also support wide variety of high level programming models.&lt;br /&gt;
*Highly used for parallel execution of data&lt;br /&gt;
*Provides the functionality of checkpoint and restoring&lt;br /&gt;
*A complex framework that can be the backend for simpler models of computation like LINQ or MapReduce to be built on top of.&lt;br /&gt;
*Real Time Applications:&lt;br /&gt;
:*Batch iterative Machine Learning: &lt;br /&gt;
VW, an open source distributed machine learning performs iteration in 3 phases: each process updates local state; processes independently training on local data; and process jointly performed global average which is All Reduce.&lt;br /&gt;
:*Streaming Acyclic Computation&lt;br /&gt;
When compared to a system called [http://research.microsoft.com/apps/pubs/default.aspx?id=163832 Kineograph] ( also done by Microsoft ), which processes twitter handles and provides counts of the occurrence of hashtags as well as links between popular tags, was written using Naiad in 26 lines of code and ran close to 2X faster.&lt;br /&gt;
* Naiad paper won the best paper award in SOSP 2013, check-out this link in Microsoft Research website http://research.microsoft.com/en-us/projects/naiad/ . Down in this page you can see some videos that explains naiad including Derek&#039;s Murray presentation at SOSP 2013.&lt;/div&gt;</summary>
		<author><name>Ambalica</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_9&amp;diff=20167</id>
		<title>DistOS 2015W Session 9</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_9&amp;diff=20167"/>
		<updated>2015-04-09T23:06:18Z</updated>

		<summary type="html">&lt;p&gt;Ambalica: /* BOINC */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== BOINC ==&lt;br /&gt;
&lt;br /&gt;
*Public Resource Computing Platform&lt;br /&gt;
*Gives scientists the ability to use large amounts of computation resources.&lt;br /&gt;
*The clients do not connect directly with each other but instead they talk to a central server located at Berkley&lt;br /&gt;
*The goals of Boinc are: &lt;br /&gt;
:*1) reduce the barriers of entry&lt;br /&gt;
:*2) Share resources among autonomous projects&lt;br /&gt;
:*3) Support diverse applications&lt;br /&gt;
:*4) Reward participants.&lt;br /&gt;
:*5) Provide screensaver graphics&lt;br /&gt;
&lt;br /&gt;
*It can run as applications in common language with no modifications&lt;br /&gt;
*A BOINC application can be identified by a single master URL, &amp;lt;br/&amp;gt;which serves as the homepage as well as the directory of the servers.&lt;br /&gt;
*Servers perform set of function using:&lt;br /&gt;
**Scheduling servers: handles Remote Process Call from clients&lt;br /&gt;
** Data servers:helps to manage the uploads&lt;br /&gt;
&lt;br /&gt;
== SETI@Home ==&lt;br /&gt;
&lt;br /&gt;
*Uses public resource computing to analyze radio signals to find extraterrestrial intelligence&lt;br /&gt;
*Need good quality telescope to search for radio signals, and lots of computational power, which was unavailable locally&lt;br /&gt;
*It has not yet found extraterrestrial intelligence, but its has established credibility of public resource computing projects&lt;br /&gt;
*Originally custom, now uses BOINC as a backbone for the project&lt;br /&gt;
*Uses relational database to store information on a large scale, further it uses a multi-threaded server to distribute work to clients&lt;br /&gt;
*Quality of data in this architecture is untrustworthy, the main incentive to use it, however, is that it is a cheap and easy way of scaling the work exponentially.&lt;br /&gt;
*Provided social incentives to encourage users to join the system.&lt;br /&gt;
*This computation model still exists but not in the legitimate world.&lt;br /&gt;
*Formed a good concept of public resource computing and a distributed computing by providing a platform independent framework&lt;br /&gt;
&lt;br /&gt;
== MapReduce ==&lt;br /&gt;
&lt;br /&gt;
*A programming model presented by Google to do large scale parallel computations&lt;br /&gt;
*Uses the &amp;lt;code&amp;gt;Map()&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;Reduce()&amp;lt;/code&amp;gt; functions from functional style programming languages&lt;br /&gt;
:*Map (Filtering)&lt;br /&gt;
::*Takes a function and applies it to a bunch of keys to produce values&lt;br /&gt;
* Hides parallelization, fault tolerance, locality optimization and load balancing&lt;br /&gt;
:*Reduce (Summary)&lt;br /&gt;
::*Accumulates results from the data set using a given function&lt;br /&gt;
* Very easy to use and understand, with many classic problems fitting this pattern&lt;br /&gt;
* Otherwise quite constrained in what exactly can be done&lt;br /&gt;
* Uses hashing to distribute similar keys to similar machines, but otherwise spread the load&lt;br /&gt;
&lt;br /&gt;
== Naiad ==&lt;br /&gt;
&lt;br /&gt;
*A programming model similar to &amp;lt;code&amp;gt;MapReduce&amp;lt;/code&amp;gt; but with streaming capabilities so that data results are almost instantaneous&lt;br /&gt;
*A distributed system for executing data parallel cyclic dataflow programs offering high throughput and low latency&lt;br /&gt;
*Aims to provide a general purpose system which will fulfill the requirements and the will also support wide variety of high level programming models.&lt;br /&gt;
*Highly used for parallel execution of data&lt;br /&gt;
*Provides the functionality of checkpoint and restoring&lt;br /&gt;
*A complex framework that can be the backend for simpler models of computation like LINQ or MapReduce to be built on top of.&lt;br /&gt;
*Real Time Applications:&lt;br /&gt;
:*Batch iterative Machine Learning: &lt;br /&gt;
VW, an open source distributed machine learning performs iteration in 3 phases: each process updates local state; processes independently training on local data; and process jointly performed global average which is All Reduce.&lt;br /&gt;
:*Streaming Acyclic Computation&lt;br /&gt;
When compared to a system called [http://research.microsoft.com/apps/pubs/default.aspx?id=163832 Kineograph] ( also done by Microsoft ), which processes twitter handles and provides counts of the occurrence of hashtags as well as links between popular tags, was written using Naiad in 26 lines of code and ran close to 2X faster.&lt;br /&gt;
* Naiad paper won the best paper award in SOSP 2013, check-out this link in Microsoft Research website http://research.microsoft.com/en-us/projects/naiad/ . Down in this page you can see some videos that explains naiad including Derek&#039;s Murray presentation at SOSP 2013.&lt;/div&gt;</summary>
		<author><name>Ambalica</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_9&amp;diff=20166</id>
		<title>DistOS 2015W Session 9</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_9&amp;diff=20166"/>
		<updated>2015-04-09T22:55:16Z</updated>

		<summary type="html">&lt;p&gt;Ambalica: /* BOINC */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== BOINC ==&lt;br /&gt;
&lt;br /&gt;
*Public Resource Computing Platform&lt;br /&gt;
*Gives scientists the ability to use large amounts of computation resources.&lt;br /&gt;
*The clients do not connect directly with each other but instead they talk to a central server located at Berkley&lt;br /&gt;
*The goals of Boinc are: &lt;br /&gt;
:*1) reduce the barriers of entry&lt;br /&gt;
:*2) Share resources among autonomous projects&lt;br /&gt;
:*3) Support diverse applications&lt;br /&gt;
:*4) Reward participants.&lt;br /&gt;
:*5) Provide screensaver graphics&lt;br /&gt;
&lt;br /&gt;
*It can run as applications in common language with no modifications&lt;br /&gt;
 A BOINC application can be identified by a single master URL, &amp;lt;br/&amp;gt;which serves as the homepage as well as the directory of the servers.&lt;br /&gt;
&lt;br /&gt;
== SETI@Home ==&lt;br /&gt;
&lt;br /&gt;
*Uses public resource computing to analyze radio signals to find extraterrestrial intelligence&lt;br /&gt;
*Need good quality telescope to search for radio signals, and lots of computational power, which was unavailable locally&lt;br /&gt;
*It has not yet found extraterrestrial intelligence, but its has established credibility of public resource computing projects&lt;br /&gt;
*Originally custom, now uses BOINC as a backbone for the project&lt;br /&gt;
*Uses relational database to store information on a large scale, further it uses a multi-threaded server to distribute work to clients&lt;br /&gt;
*Quality of data in this architecture is untrustworthy, the main incentive to use it, however, is that it is a cheap and easy way of scaling the work exponentially.&lt;br /&gt;
*Provided social incentives to encourage users to join the system.&lt;br /&gt;
*This computation model still exists but not in the legitimate world.&lt;br /&gt;
*Formed a good concept of public resource computing and a distributed computing by providing a platform independent framework&lt;br /&gt;
&lt;br /&gt;
== MapReduce ==&lt;br /&gt;
&lt;br /&gt;
*A programming model presented by Google to do large scale parallel computations&lt;br /&gt;
*Uses the &amp;lt;code&amp;gt;Map()&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;Reduce()&amp;lt;/code&amp;gt; functions from functional style programming languages&lt;br /&gt;
:*Map (Filtering)&lt;br /&gt;
::*Takes a function and applies it to a bunch of keys to produce values&lt;br /&gt;
* Hides parallelization, fault tolerance, locality optimization and load balancing&lt;br /&gt;
:*Reduce (Summary)&lt;br /&gt;
::*Accumulates results from the data set using a given function&lt;br /&gt;
* Very easy to use and understand, with many classic problems fitting this pattern&lt;br /&gt;
* Otherwise quite constrained in what exactly can be done&lt;br /&gt;
* Uses hashing to distribute similar keys to similar machines, but otherwise spread the load&lt;br /&gt;
&lt;br /&gt;
== Naiad ==&lt;br /&gt;
&lt;br /&gt;
*A programming model similar to &amp;lt;code&amp;gt;MapReduce&amp;lt;/code&amp;gt; but with streaming capabilities so that data results are almost instantaneous&lt;br /&gt;
*A distributed system for executing data parallel cyclic dataflow programs offering high throughput and low latency&lt;br /&gt;
*Aims to provide a general purpose system which will fulfill the requirements and the will also support wide variety of high level programming models.&lt;br /&gt;
*Highly used for parallel execution of data&lt;br /&gt;
*Provides the functionality of checkpoint and restoring&lt;br /&gt;
*A complex framework that can be the backend for simpler models of computation like LINQ or MapReduce to be built on top of.&lt;br /&gt;
*Real Time Applications:&lt;br /&gt;
:*Batch iterative Machine Learning: &lt;br /&gt;
VW, an open source distributed machine learning performs iteration in 3 phases: each process updates local state; processes independently training on local data; and process jointly performed global average which is All Reduce.&lt;br /&gt;
:*Streaming Acyclic Computation&lt;br /&gt;
When compared to a system called [http://research.microsoft.com/apps/pubs/default.aspx?id=163832 Kineograph] ( also done by Microsoft ), which processes twitter handles and provides counts of the occurrence of hashtags as well as links between popular tags, was written using Naiad in 26 lines of code and ran close to 2X faster.&lt;br /&gt;
* Naiad paper won the best paper award in SOSP 2013, check-out this link in Microsoft Research website http://research.microsoft.com/en-us/projects/naiad/ . Down in this page you can see some videos that explains naiad including Derek&#039;s Murray presentation at SOSP 2013.&lt;/div&gt;</summary>
		<author><name>Ambalica</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_12&amp;diff=20165</id>
		<title>DistOS 2015W Session 12</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_12&amp;diff=20165"/>
		<updated>2015-04-09T22:20:54Z</updated>

		<summary type="html">&lt;p&gt;Ambalica: /* Comet */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Haystack=&lt;br /&gt;
* Facebook&#039;s Photo Application Storage System. &lt;br /&gt;
* Previous Fb photo storage based on NFS design. The reason why NFS didn&#039;t work is that it took 3 file-system accesses per logical photo read. Haystack only needs one access.&lt;br /&gt;
*Main goals of Haystack:&lt;br /&gt;
** High throughput with low latency. It uses one disk operation to provide these.&lt;br /&gt;
**Fault tolerance&lt;br /&gt;
**Cost effective&lt;br /&gt;
**Simple&lt;br /&gt;
*Facebook stored all images in haystack with a CDN in front to cache hot data. Haystack still needs to be fast since accessing non-cached data is still common.&lt;br /&gt;
*Haystack reduces the memory used for &#039;&#039;filesystem metadata&#039;&#039; &lt;br /&gt;
*It has 2 types of metadata:&lt;br /&gt;
**&#039;&#039;Application metadata&#039;&#039;&lt;br /&gt;
**&#039;&#039;File System metadata&#039;&#039;&lt;br /&gt;
* The architecture consists of 3 components:&lt;br /&gt;
**Haystack Store&lt;br /&gt;
**Haystack Directory&lt;br /&gt;
**Haystack Cache&lt;br /&gt;
*Pitchfork and bulk sync were used to tolerate faults. theTfault tolerance works in a very profound way to make haystack feasible and reliable&lt;br /&gt;
&lt;br /&gt;
=Comet=&lt;br /&gt;
*Introduced the concept of distributed shared memory (DSM). In a DSM, RAMs from multiple servers would appear as if they are all belonging to one server, allowing better scalability for caching.&lt;br /&gt;
*DSM provides advatage over RPC(Remote Procedure Call)  including multi threading suuport, thread migration during execution. &lt;br /&gt;
*client and server model maintain consistency using DSM&lt;br /&gt;
*Comet model works by offloading the computation intensive process from the mobile to only one server.&lt;br /&gt;
*The offloading process works by passing the computation intensive process to the server and hold it on the mobile device. Once the process on the server completes, it returns the results and the handle back to the mobile device. In other words, the process does not get physically offloaded to the server but instead it runs on the server and stopped on the mobile device.&lt;br /&gt;
&lt;br /&gt;
=F4=&lt;br /&gt;
* Warm Blob Storage System.&lt;br /&gt;
** Warm Blob is a store for large quantities of immutable data that isn&#039;t frequently accessed, but must still be available.&lt;br /&gt;
** Built to reduce the overhead of haystack for old data that doesn&#039;t need to be quite as available. Generally data that is a few months old is moved from Haystack to Warm Blob.&lt;br /&gt;
** F4 reduce the space usage of Haystack from a replication factor of 3.6 to 2.8 or 2.1 using Reed Solomon coding and XOR coding respectively but still provides consistency.&lt;br /&gt;
** Less robust to data center failures as a result.&lt;br /&gt;
*Reed Solomon coding basically use(10,4) which means 10 data and 4 parity blocks in a stripe, and can thus tolerate losing up to 4 blocks which means it can tolerate 4 rack failure and use 1.4 expansion factor.Two copies of this would be 2* 1.4= 2.8 effective replication factor.&lt;br /&gt;
*XOR coding use(2,1) across three data center and use 1.5 expansion factor which gives 1.5*1.4= 2.1 effective replication factor.&lt;br /&gt;
*The caching mechanism provides the reduction in load on storage system and it makes BLOB scaleable.&lt;br /&gt;
&lt;br /&gt;
=Sapphire=&lt;br /&gt;
*Represents a building block towards building this global distributed systems. The main critique to it is that it didn’t present a specific use case upon which their design is built upon.&lt;br /&gt;
*Sapphire does not show their scalability boundaries. There is no such distributed system model that can be “one size fits all”, most probably it will break in some large scale distributed application.&lt;br /&gt;
*Reaching this global distributed system that address all the distributed OS use cases will be a cumulative work of many big bodies and building it block by block and then this system will evolve by putting all these different building blocks together. In other words, reaching a global distributed system will come from a “bottom up not top down approach” [Somayaji, 2015].&lt;br /&gt;
*The concept of separate application logic from deployment logic helps programmers in making a flexible system. The other important part that makes it as a scalable system was that it is object based and could be integrated with any object oriented language.&lt;/div&gt;</summary>
		<author><name>Ambalica</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_12&amp;diff=20164</id>
		<title>DistOS 2015W Session 12</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_12&amp;diff=20164"/>
		<updated>2015-04-09T22:15:15Z</updated>

		<summary type="html">&lt;p&gt;Ambalica: /* Comet */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Haystack=&lt;br /&gt;
* Facebook&#039;s Photo Application Storage System. &lt;br /&gt;
* Previous Fb photo storage based on NFS design. The reason why NFS didn&#039;t work is that it took 3 file-system accesses per logical photo read. Haystack only needs one access.&lt;br /&gt;
*Main goals of Haystack:&lt;br /&gt;
** High throughput with low latency. It uses one disk operation to provide these.&lt;br /&gt;
**Fault tolerance&lt;br /&gt;
**Cost effective&lt;br /&gt;
**Simple&lt;br /&gt;
*Facebook stored all images in haystack with a CDN in front to cache hot data. Haystack still needs to be fast since accessing non-cached data is still common.&lt;br /&gt;
*Haystack reduces the memory used for &#039;&#039;filesystem metadata&#039;&#039; &lt;br /&gt;
*It has 2 types of metadata:&lt;br /&gt;
**&#039;&#039;Application metadata&#039;&#039;&lt;br /&gt;
**&#039;&#039;File System metadata&#039;&#039;&lt;br /&gt;
* The architecture consists of 3 components:&lt;br /&gt;
**Haystack Store&lt;br /&gt;
**Haystack Directory&lt;br /&gt;
**Haystack Cache&lt;br /&gt;
*Pitchfork and bulk sync were used to tolerate faults. theTfault tolerance works in a very profound way to make haystack feasible and reliable&lt;br /&gt;
&lt;br /&gt;
=Comet=&lt;br /&gt;
*Introduced the concept of distributed shared memory (DSM). In a DSM, RAMs from multiple servers would appear as if they are all belonging to one server, allowing better scalability for caching.&lt;br /&gt;
*DSM provides advatage over Rpc(Remote Procedure Call)  including multi threading suuport, thread migration during execution. &lt;br /&gt;
*client and server model maintain consistency using DSM&lt;br /&gt;
*Comet model works by offloading the computation intensive process from the mobile to only one server.&lt;br /&gt;
*The offloading process works by passing the computation intensive process to the server and hold it on the mobile device. Once the process on the server completes, it returns the results and the handle back to the mobile device. In other words, the process does not get physically offloaded to the server but instead it runs on the server and stopped on the mobile device.&lt;br /&gt;
&lt;br /&gt;
=F4=&lt;br /&gt;
* Warm Blob Storage System.&lt;br /&gt;
** Warm Blob is a store for large quantities of immutable data that isn&#039;t frequently accessed, but must still be available.&lt;br /&gt;
** Built to reduce the overhead of haystack for old data that doesn&#039;t need to be quite as available. Generally data that is a few months old is moved from Haystack to Warm Blob.&lt;br /&gt;
** F4 reduce the space usage of Haystack from a replication factor of 3.6 to 2.8 or 2.1 using Reed Solomon coding and XOR coding respectively but still provides consistency.&lt;br /&gt;
** Less robust to data center failures as a result.&lt;br /&gt;
*Reed Solomon coding basically use(10,4) which means 10 data and 4 parity blocks in a stripe, and can thus tolerate losing up to 4 blocks which means it can tolerate 4 rack failure and use 1.4 expansion factor.Two copies of this would be 2* 1.4= 2.8 effective replication factor.&lt;br /&gt;
*XOR coding use(2,1) across three data center and use 1.5 expansion factor which gives 1.5*1.4= 2.1 effective replication factor.&lt;br /&gt;
*The caching mechanism provides the reduction in load on storage system and it makes BLOB scaleable.&lt;br /&gt;
&lt;br /&gt;
=Sapphire=&lt;br /&gt;
*Represents a building block towards building this global distributed systems. The main critique to it is that it didn’t present a specific use case upon which their design is built upon.&lt;br /&gt;
*Sapphire does not show their scalability boundaries. There is no such distributed system model that can be “one size fits all”, most probably it will break in some large scale distributed application.&lt;br /&gt;
*Reaching this global distributed system that address all the distributed OS use cases will be a cumulative work of many big bodies and building it block by block and then this system will evolve by putting all these different building blocks together. In other words, reaching a global distributed system will come from a “bottom up not top down approach” [Somayaji, 2015].&lt;br /&gt;
*The concept of separate application logic from deployment logic helps programmers in making a flexible system. The other important part that makes it as a scalable system was that it is object based and could be integrated with any object oriented language.&lt;/div&gt;</summary>
		<author><name>Ambalica</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_12&amp;diff=20090</id>
		<title>DistOS 2015W Session 12</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_12&amp;diff=20090"/>
		<updated>2015-04-02T04:58:19Z</updated>

		<summary type="html">&lt;p&gt;Ambalica: /* F4 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Haystack=&lt;br /&gt;
* Facebook&#039;s Photo Application Storage System. &lt;br /&gt;
* Previous Fb photo storage based on NFS design. The reason why NFS dint work is because it gave 3 reads for every photo. The issue here was that they needed 1 read per photo.&lt;br /&gt;
*Main goals of Haystack:&lt;br /&gt;
** High throughput with low latency&lt;br /&gt;
**Fault tolerance&lt;br /&gt;
**Cost effective&lt;br /&gt;
**SImple&lt;br /&gt;
*Facebook utilises CDN to serve popular images and further uses haystack to respond to photo requests in the long tail effectively. &lt;br /&gt;
*Haystack reduces the memory used for &#039;&#039;filesystem metadata&#039;&#039; &lt;br /&gt;
*It has 2 types of metadata:&lt;br /&gt;
**&#039;&#039;Application metadata&#039;&#039;&lt;br /&gt;
**&#039;&#039;File System metadata&#039;&#039;&lt;br /&gt;
* The architecture consists of 3 components:&lt;br /&gt;
**Haystack Store&lt;br /&gt;
**Haystack Directory&lt;br /&gt;
**Haystack Cache&lt;br /&gt;
&lt;br /&gt;
=Comet=&lt;br /&gt;
*Introduced the concept of distributed shared memory (DSM). In a DSM, RAMs from multiple servers would appear as if they are all belonging to one server, allowing better scalability for caching.&lt;br /&gt;
*Comet model works by offloading the computation intensive process from the mobile to only one server.&lt;br /&gt;
*The offloading process works by passing the computation intensive process to the server and hold it on the mobile device. Once the process on the server completes, it returns the results and the handle back to the mobile device. In other words, the process does not get physically offloaded to the server but instead it runs on the server and stopped on the mobile device. &lt;br /&gt;
=F4=&lt;br /&gt;
* Warm Blob Storage System.&lt;br /&gt;
** Warm Blob is a immutable data that gets cool very rapidly.&lt;br /&gt;
** F4 reduce the space usage by 3.6 to 2.8 or 2.1 replication factor using Reed Solomon coding and XOR coding respectively but still provides consistency.&lt;br /&gt;
&lt;br /&gt;
=Sapphire=&lt;br /&gt;
*Represents a building block towards building this global distributed systems. The main critique to it is that it didn’t present a specific use case upon which their design is built upon.&lt;br /&gt;
*Sapphire does not show their scalability boundaries. There is no such distributed system model that can be “one size fits all”, most probably it will break in some large scale distributed application.&lt;br /&gt;
*Reaching this global distributed system that address all the distributed OS use cases will be a cumulative work of many big bodies and building it block by block and then this system will evolve by putting all these different building blocks together. In other words, reaching a global distributed system will come from a “bottom up not top down approach” [Somayaji, 2015].&lt;/div&gt;</summary>
		<author><name>Ambalica</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_12&amp;diff=20089</id>
		<title>DistOS 2015W Session 12</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_12&amp;diff=20089"/>
		<updated>2015-04-02T04:51:41Z</updated>

		<summary type="html">&lt;p&gt;Ambalica: /* F4 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Haystack=&lt;br /&gt;
* Facebook&#039;s Photo Application Storage System. &lt;br /&gt;
* Previous Fb photo storage based on NFS design. The reason why NFS dint work is because it gave 3 reads for every photo. The issue here was that they needed 1 read per photo.&lt;br /&gt;
*Main goals of Haystack:&lt;br /&gt;
** High throughput with low latency&lt;br /&gt;
**Fault tolerance&lt;br /&gt;
**Cost effective&lt;br /&gt;
**SImple&lt;br /&gt;
*Facebook utilises CDN to serve popular images and further uses haystack to respond to photo requests in the long tail effectively. &lt;br /&gt;
*Haystack reduces the memory used for &#039;&#039;filesystem metadata&#039;&#039; &lt;br /&gt;
*It has 2 types of metadata:&lt;br /&gt;
**&#039;&#039;Application metadata&#039;&#039;&lt;br /&gt;
**&#039;&#039;File System metadata&#039;&#039;&lt;br /&gt;
* The architecture consists of 3 components:&lt;br /&gt;
**Haystack Store&lt;br /&gt;
**Haystack Directory&lt;br /&gt;
**Haystack Cache&lt;br /&gt;
&lt;br /&gt;
=Comet=&lt;br /&gt;
*Introduced the concept of distributed shared memory (DSM). In a DSM, RAMs from multiple servers would appear as if they are all belonging to one server, allowing better scalability for caching.&lt;br /&gt;
*Comet model works by offloading the computation intensive process from the mobile to only one server.&lt;br /&gt;
*The offloading process works by passing the computation intensive process to the server and hold it on the mobile device. Once the process on the server completes, it returns the results and the handle back to the mobile device. In other words, the process does not get physically offloaded to the server but instead it runs on the server and stopped on the mobile device. &lt;br /&gt;
=F4=&lt;br /&gt;
* Warm Blob Storage System.&lt;br /&gt;
** Warm Blob is a immutable data that gets cool very rapidly.&lt;br /&gt;
** F4 reduce the space usage by 3.6 to 2.8 or 2.1 replication factor but still provides consistency.&lt;br /&gt;
&lt;br /&gt;
=Sapphire=&lt;br /&gt;
*Represents a building block towards building this global distributed systems. The main critique to it is that it didn’t present a specific use case upon which their design is built upon.&lt;br /&gt;
*Sapphire does not show their scalability boundaries. There is no such distributed system model that can be “one size fits all”, most probably it will break in some large scale distributed application.&lt;br /&gt;
*Reaching this global distributed system that address all the distributed OS use cases will be a cumulative work of many big bodies and building it block by block and then this system will evolve by putting all these different building blocks together. In other words, reaching a global distributed system will come from a “bottom up not top down approach” [Somayaji, 2015].&lt;/div&gt;</summary>
		<author><name>Ambalica</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_12&amp;diff=20088</id>
		<title>DistOS 2015W Session 12</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_12&amp;diff=20088"/>
		<updated>2015-04-02T04:38:33Z</updated>

		<summary type="html">&lt;p&gt;Ambalica: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Haystack=&lt;br /&gt;
* Facebook&#039;s Photo Application Storage System. &lt;br /&gt;
* Previous Fb photo storage based on NFS design. The reason why NFS dint work is because it gave 3 reads for every photo. The issue here was that they needed 1 read per photo.&lt;br /&gt;
*Main goals of Haystack:&lt;br /&gt;
** High throughput with low latency&lt;br /&gt;
**Fault tolerance&lt;br /&gt;
**Cost effective&lt;br /&gt;
**SImple&lt;br /&gt;
*Facebook utilises CDN to serve popular images and further uses haystack to respond to photo requests in the long tail effectively. &lt;br /&gt;
*Haystack reduces the memory used for &#039;&#039;filesystem metadata&#039;&#039; &lt;br /&gt;
*It has 2 types of metadata:&lt;br /&gt;
**&#039;&#039;Application metadata&#039;&#039;&lt;br /&gt;
**&#039;&#039;File System metadata&#039;&#039;&lt;br /&gt;
* The architecture consists of 3 components:&lt;br /&gt;
**Haystack Store&lt;br /&gt;
**Haystack Directory&lt;br /&gt;
**Haystack Cache&lt;br /&gt;
&lt;br /&gt;
=Comet=&lt;br /&gt;
*Introduced the concept of distributed shared memory (DSM). In a DSM, RAMs from multiple servers would appear as if they are all belonging to one server, allowing better scalability for caching.&lt;br /&gt;
*Comet model works by offloading the computation intensive process from the mobile to only one server.&lt;br /&gt;
*The offloading process works by passing the computation intensive process to the server and hold it on the mobile device. Once the process on the server completes, it returns the results and the handle back to the mobile device. In other words, the process does not get physically offloaded to the server but instead it runs on the server and stopped on the mobile device. &lt;br /&gt;
=F4=&lt;br /&gt;
* Warm Blob Storage System.&lt;br /&gt;
** Warm Blob is a immutable data that gets cool very rapidly.&lt;br /&gt;
** F4 reduce the space usage by 3.6 to 2.8 or 1.4 replication factor but still provides consistency. &lt;br /&gt;
&lt;br /&gt;
=Sapphire=&lt;br /&gt;
*Represents a building block towards building this global distributed systems. The main critique to it is that it didn’t present a specific use case upon which their design is built upon.&lt;br /&gt;
*Sapphire does not show their scalability boundaries. There is no such distributed system model that can be “one size fits all”, most probably it will break in some large scale distributed application.&lt;br /&gt;
*Reaching this global distributed system that address all the distributed OS use cases will be a cumulative work of many big bodies and building it block by block and then this system will evolve by putting all these different building blocks together. In other words, reaching a global distributed system will come from a “bottom up not top down approach” [Somayaji, 2015].&lt;/div&gt;</summary>
		<author><name>Ambalica</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_12&amp;diff=20087</id>
		<title>DistOS 2015W Session 12</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_12&amp;diff=20087"/>
		<updated>2015-04-02T04:37:26Z</updated>

		<summary type="html">&lt;p&gt;Ambalica: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Haystack=&lt;br /&gt;
* Facebook&#039;s Photo Application Storage System. &lt;br /&gt;
* Previous Fb photo storage based on NFS design. The reason why NFS dint work is because it gave 3 reads for every photo. The issue here was that they needed 1 read per photo.&lt;br /&gt;
*Main goals of Haystack:&lt;br /&gt;
** High throughput with low latency&lt;br /&gt;
**Fault tolerance&lt;br /&gt;
**Cost effective&lt;br /&gt;
**SImple&lt;br /&gt;
*Facebook utilises CDN to serve popular images and further uses haystack to respond to photo requests in the long tail effectively. &lt;br /&gt;
*Haystack reduces the memory used for &#039;&#039;filesystem metadata&#039;&#039; &lt;br /&gt;
*It has 2 types of metadata:&lt;br /&gt;
**&#039;&#039;Application metadata&#039;&#039;&lt;br /&gt;
**&#039;&#039;File System metadata&#039;&#039;&lt;br /&gt;
* The architecture consists of 3 components:&lt;br /&gt;
**Haystack Store&lt;br /&gt;
**Haystack Directory&lt;br /&gt;
**Haystack Cache&lt;br /&gt;
&lt;br /&gt;
=Comet=&lt;br /&gt;
*Introduced the concept of distributed shared memory (DSM). In a DSM, RAMs from multiple servers would appear as if they are all belonging to one server, allowing better scalability for caching.&lt;br /&gt;
*Comet model works by offloading the computation intensive process from the mobile to only one server.&lt;br /&gt;
*The offloading process works by passing the computation intensive process to the server and hold it on the mobile device. Once the process on the server completes, it returns the results and the handle back to the mobile device. In other words, the process does not get physically offloaded to the server but instead it runs on the server and stopped on the mobile device. &lt;br /&gt;
=F4=&lt;br /&gt;
* Warm Blob Storage System.&lt;br /&gt;
 ** Warm Blob is a immutable data that gets cool very rapidly.&lt;br /&gt;
 ** F4 reduce the space usage by 3.6 to 2.8 or 1.4 replication factor but still provides consistency. &lt;br /&gt;
&lt;br /&gt;
=Sapphire=&lt;br /&gt;
*Represents a building block towards building this global distributed systems. The main critique to it is that it didn’t present a specific use case upon which their design is built upon.&lt;br /&gt;
*Sapphire does not show their scalability boundaries. There is no such distributed system model that can be “one size fits all”, most probably it will break in some large scale distributed application.&lt;br /&gt;
*Reaching this global distributed system that address all the distributed OS use cases will be a cumulative work of many big bodies and building it block by block and then this system will evolve by putting all these different building blocks together. In other words, reaching a global distributed system will come from a “bottom up not top down approach” [Somayaji, 2015].&lt;/div&gt;</summary>
		<author><name>Ambalica</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_12&amp;diff=20086</id>
		<title>DistOS 2015W Session 12</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_12&amp;diff=20086"/>
		<updated>2015-04-02T04:09:42Z</updated>

		<summary type="html">&lt;p&gt;Ambalica: /* F4 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Haystack=&lt;br /&gt;
* Facebook&#039;s Photo Application Storage System. &lt;br /&gt;
* Previous Fb photo storage based on NFS design. The reason why NFS dint work is because it gave 3 reads for every photo. The issue here was that they needed 1 read per photo.&lt;br /&gt;
*Main goals of Haystack:&lt;br /&gt;
** High throughput with low latency&lt;br /&gt;
**Fault tolerance&lt;br /&gt;
**Cost effective&lt;br /&gt;
**SImple&lt;br /&gt;
*Facebook utilises CDN to serve popular images and further uses haystack to respond to photo requests in the long tail effectively. &lt;br /&gt;
*Haystack reduces the memory used for &#039;&#039;filesystem metadata&#039;&#039; &lt;br /&gt;
*It has 2 types of metadata:&lt;br /&gt;
**&#039;&#039;Application metadata&#039;&#039;&lt;br /&gt;
**&#039;&#039;File System metadata&#039;&#039;&lt;br /&gt;
* The architecture consists of 3 components:&lt;br /&gt;
**Haystack Store&lt;br /&gt;
**Haystack Directory&lt;br /&gt;
**Haystack Cache&lt;br /&gt;
&lt;br /&gt;
=Comet=&lt;br /&gt;
*Introduced the concept of distributed shared memory (DSM). In a DSM, RAMs from multiple servers would appear as if they are all belonging to one server, allowing better scalability for caching.&lt;br /&gt;
*Comet model works by offloading the computation intensive process from the mobile to only one server.&lt;br /&gt;
*The offloading process works by passing the computation intensive process to the server and hold it on the mobile device. Once the process on the server completes, it returns the results and the handle back to the mobile device. In other words, the process does not get physically offloaded to the server but instead it runs on the server and stopped on the mobile device. &lt;br /&gt;
=F4=&lt;br /&gt;
&#039;&#039;&#039;It is a warm blob storage system.&lt;br /&gt;
&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
=Sapphire=&lt;br /&gt;
*Represents a building block towards building this global distributed systems. The main critique to it is that it didn’t present a specific use case upon which their design is built upon.&lt;br /&gt;
*Sapphire does not show their scalability boundaries. There is no such distributed system model that can be “one size fits all”, most probably it will break in some large scale distributed application.&lt;br /&gt;
*Reaching this global distributed system that address all the distributed OS use cases will be a cumulative work of many big bodies and building it block by block and then this system will evolve by putting all these different building blocks together. In other words, reaching a global distributed system will come from a “bottom up not top down approach” [Somayaji, 2015].&lt;/div&gt;</summary>
		<author><name>Ambalica</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_12&amp;diff=20085</id>
		<title>DistOS 2015W Session 12</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_12&amp;diff=20085"/>
		<updated>2015-04-02T04:08:44Z</updated>

		<summary type="html">&lt;p&gt;Ambalica: /* F4 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Haystack=&lt;br /&gt;
* Facebook&#039;s Photo Application Storage System. &lt;br /&gt;
* Previous Fb photo storage based on NFS design. The reason why NFS dint work is because it gave 3 reads for every photo. The issue here was that they needed 1 read per photo.&lt;br /&gt;
*Main goals of Haystack:&lt;br /&gt;
** High throughput with low latency&lt;br /&gt;
**Fault tolerance&lt;br /&gt;
**Cost effective&lt;br /&gt;
**SImple&lt;br /&gt;
*Facebook utilises CDN to serve popular images and further uses haystack to respond to photo requests in the long tail effectively. &lt;br /&gt;
*Haystack reduces the memory used for &#039;&#039;filesystem metadata&#039;&#039; &lt;br /&gt;
*It has 2 types of metadata:&lt;br /&gt;
**&#039;&#039;Application metadata&#039;&#039;&lt;br /&gt;
**&#039;&#039;File System metadata&#039;&#039;&lt;br /&gt;
* The architecture consists of 3 components:&lt;br /&gt;
**Haystack Store&lt;br /&gt;
**Haystack Directory&lt;br /&gt;
**Haystack Cache&lt;br /&gt;
&lt;br /&gt;
=Comet=&lt;br /&gt;
*Introduced the concept of distributed shared memory (DSM). In a DSM, RAMs from multiple servers would appear as if they are all belonging to one server, allowing better scalability for caching.&lt;br /&gt;
*Comet model works by offloading the computation intensive process from the mobile to only one server.&lt;br /&gt;
*The offloading process works by passing the computation intensive process to the server and hold it on the mobile device. Once the process on the server completes, it returns the results and the handle back to the mobile device. In other words, the process does not get physically offloaded to the server but instead it runs on the server and stopped on the mobile device. &lt;br /&gt;
=F4=&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== warm blob storage system ==&lt;br /&gt;
&lt;br /&gt;
=Sapphire=&lt;br /&gt;
*Represents a building block towards building this global distributed systems. The main critique to it is that it didn’t present a specific use case upon which their design is built upon.&lt;br /&gt;
*Sapphire does not show their scalability boundaries. There is no such distributed system model that can be “one size fits all”, most probably it will break in some large scale distributed application.&lt;br /&gt;
*Reaching this global distributed system that address all the distributed OS use cases will be a cumulative work of many big bodies and building it block by block and then this system will evolve by putting all these different building blocks together. In other words, reaching a global distributed system will come from a “bottom up not top down approach” [Somayaji, 2015].&lt;/div&gt;</summary>
		<author><name>Ambalica</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_7&amp;diff=19891</id>
		<title>DistOS 2015W Session 7</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_7&amp;diff=19891"/>
		<updated>2015-02-24T06:02:32Z</updated>

		<summary type="html">&lt;p&gt;Ambalica: /* Chubby */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Ceph =&lt;br /&gt;
* Key advantage is that it is a general purpose distributed file system.  &lt;br /&gt;
* System is composed of three units:&lt;br /&gt;
	*Client,&lt;br /&gt;
	*Cluster of Object Storage device (OSDs): It is basically stores data and metadata and clients communicate directly with it to perform IO operations.&lt;br /&gt;
	*MetaData Server (MDS): It is used to manage the file and directories.Client basically interacts with it to perform metadata operations like open, rename. It manages the capabilities of a client.&lt;br /&gt;
* system has three key features:&lt;br /&gt;
     * decoupled data and metadata: &lt;br /&gt;
     * Dynamic Distributed Metadata Management: It distribute the metadata among multiple metadata servers using dynamic subtree partitioning to increase the performance and avoid metadata access hot spots.&lt;br /&gt;
     * Object based storage: Using cluster of OSDs to form a Reliable Autonomic Distributed Object-Store(RADOS) for ceph failure detection and recovery.   &lt;br /&gt;
&lt;br /&gt;
*CRUSH (Controlled, Replicated, Under Scalable, Hashing) is the hashing algorithm used to calculate the location of object instead of looking for them. The CRUSH paper on Ceph’s website can be downloaded from here http://ceph.com/papers/weil-crush-sc06.pdf.&lt;br /&gt;
* RADOS (Reliable Autonomic Distributed Object-Store) is the object store for Ceph.&lt;br /&gt;
&lt;br /&gt;
= Chubby =&lt;br /&gt;
It is basically a coarse grained lock service that serves multiple clients with small number of servers (chubby cell).&lt;br /&gt;
&lt;br /&gt;
== system consists ==&lt;br /&gt;
*Chubby Cell: mainly consists of 5 servers known as replicas. Consensus protocol is used to elect the master from replicas.&lt;br /&gt;
*Client: Find the master between the replicas. Consensus protocol is used to propagate the write request to the majority of servers. Read request is handled by master only.&lt;br /&gt;
communication between client and server is via RPCs.&lt;br /&gt;
 &lt;br /&gt;
  &lt;br /&gt;
&lt;br /&gt;
* Is a consensus algorithm among a set of servers to agree on who is the master that is in charge of the metadata.&lt;br /&gt;
* Can be considered a distributed file system for small size files only “256 KB” with very low scalability “5 servers”.&lt;br /&gt;
* Is defined in the paper as “A lock service used within a loosely-coupled distributed system consisting of moderately large number of small machines connected by a high speed network”.&lt;/div&gt;</summary>
		<author><name>Ambalica</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_5&amp;diff=19786</id>
		<title>DistOS 2015W Session 5</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_5&amp;diff=19786"/>
		<updated>2015-02-04T03:47:23Z</updated>

		<summary type="html">&lt;p&gt;Ambalica: /* Google File System */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== &#039;&#039;&#039;Cloud Distributed Operating System&#039;&#039;&#039;==&lt;br /&gt;
 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.&lt;br /&gt;
The OS is based on 2 patterns:&lt;br /&gt;
1. Message Based OS&lt;br /&gt;
2. Object Based  OS&lt;br /&gt;
&lt;br /&gt;
The structure of this is based on &#039;&#039;&#039;Object Thread Model.&#039;&#039;&#039; &lt;br /&gt;
It has set of objects which are defined by the class. Objects respond to messages. &lt;br /&gt;
Sending message to object causes object to execute the method and then reply back. &lt;br /&gt;
&lt;br /&gt;
It has Active Objects and Passive objects&lt;br /&gt;
&lt;br /&gt;
1.&#039;&#039;&#039;Active Objects&#039;&#039;&#039; are the objects which have one or more processes associated with them and further they can communicate with the external environment. &lt;br /&gt;
2.&#039;&#039;&#039;Passive Objects&#039;&#039;&#039; are the object which have no processes in them.&lt;br /&gt;
&lt;br /&gt;
The contents of the Cloud are long lived. They exist forever and can survive system crashes and shut downs.&lt;br /&gt;
&lt;br /&gt;
Another important part of Cloud DOS are &#039;&#039;&#039;threads&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
The threads are the logical path of execution that traverse objects and executes code in them. &lt;br /&gt;
&lt;br /&gt;
Note: The cloud thread is not bound to a single address space. Several threads can enter an object simultaneously and execute concurrently.&lt;br /&gt;
&lt;br /&gt;
The nature of the Cloud object prohibits a thread from accessing any data outside the current address space in which it is executing.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Interaction between &#039;&#039;&#039;Objects&#039;&#039;&#039; and &#039;&#039;&#039;Threads&#039;&#039;&#039;&lt;br /&gt;
1)Inter object interfaces are procedural&lt;br /&gt;
2)Invocations work across machine boundaries&lt;br /&gt;
3)Objects in cloud unify concept of persistent storage and memory to create address space, thus making the programming simpler.&lt;br /&gt;
4)Control flow achieved by threads invoking objects.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Cloud Environment&#039;&#039;&#039;&lt;br /&gt;
1) Integrates set of homogeneous machines into one seamless environment&lt;br /&gt;
2) There are three logical categories of machines- Compute Server, User Workstation and Data server.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
== &#039;&#039;&#039;Plan 9&#039;&#039;&#039; ==&lt;br /&gt;
&lt;br /&gt;
Plan 9 is a general purpose, multiuser and mobile computing environment physically distributed across machines. &lt;br /&gt;
The Plan 9 began in late 1980s. The aims of this system are:&lt;br /&gt;
1) To built a system that should be centrally administered &lt;br /&gt;
2) Cost effective using cheap modern microcomputers. &lt;br /&gt;
The distribution itself is transparent to most programs.&lt;br /&gt;
This property is made possible by 2 properties:&lt;br /&gt;
1) A per process group name space&lt;br /&gt;
2) A uniform access to all the resources by representing them as a file.&lt;br /&gt;
&lt;br /&gt;
It is quite similar to the Unix yet so different. 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.&lt;br /&gt;
&lt;br /&gt;
What actually distinguishes Plan 9 is its &#039;&#039;&#039;organization&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
Plan 9 is divided along the lines of service function. &lt;br /&gt;
* CPU services and terminals use same kernel&lt;br /&gt;
* Users may choose to run programs locally or remotely on CPU servers&lt;br /&gt;
*Gives the user a choice to choose whether they want distributed or centralized.&lt;br /&gt;
&lt;br /&gt;
The design of Plan 9 is based on 3 principles:&lt;br /&gt;
1) Resources are named and accessed like files in hierarchical file system.&lt;br /&gt;
2) Standard protocol 9P&lt;br /&gt;
3) Disjoint hierarchical provided by different services are joined together into single private hierarchal file name space.&lt;br /&gt;
&lt;br /&gt;
Another concept in Plan 9 is the &#039;&#039;&#039;Virtual Name Space&#039;&#039;&#039;&lt;br /&gt;
In a &#039;&#039;&#039;Virtual Name Space&#039;&#039;&#039;, a user boots a terminal or connects to a CPU server and then a new process group is created. &lt;br /&gt;
Processes in group can either add to or rearrange their name space using two system calls- [[Mount]] and [[Bind]]&lt;br /&gt;
* &#039;&#039;&#039;Mount&#039;&#039;&#039; is used to attach new file system to a point in name space.&lt;br /&gt;
*&#039;&#039;&#039;Bind&#039;&#039;&#039; is used to attach a kernel resident file system to name space and also arrange pieces of name space.&lt;br /&gt;
&lt;br /&gt;
The plan 9 provides mechanism to customize one&#039;s view of the system with the help of the software rather than the hardware.&lt;br /&gt;
It is built for the traditional system but it can be extended to the other resources. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Parallel Programming&#039;&#039;&#039;&lt;br /&gt;
The parallel programming has two aspects:&lt;br /&gt;
* Kernel provides simple process model and carefully designed system calls for synchronization.&lt;br /&gt;
*Programming language supports concurrent programming.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Implementation of Name Spaces&#039;&#039;&#039;&lt;br /&gt;
User processes construct name specs using three system calls- mount, bind, unmount.&lt;br /&gt;
Mount- System call attaches a tree served by a file server to the current name specs&lt;br /&gt;
Bind-Duplicates pieces of existing name specs at another point&lt;br /&gt;
Unmount- Allows components to be removed.&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
== &#039;&#039;&#039;Google File System&#039;&#039;&#039; ==&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Master and Chunk-Server Communication:&lt;br /&gt;
a) To check whether there is any chunk-server is down&lt;br /&gt;
b) To check if any file is corrupted.&lt;br /&gt;
c) Whether to create or delete any chunk.&lt;br /&gt;
&lt;br /&gt;
Operation of GFS:&lt;br /&gt;
a) Client communicate with master to get the matadata. &lt;br /&gt;
b) client get chunk location from matadata.&lt;br /&gt;
c) Communicate with the one of that chunk-server to retrieve the data to perform operations on it.&lt;/div&gt;</summary>
		<author><name>Ambalica</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_3&amp;diff=19686</id>
		<title>DistOS 2015W Session 3</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_3&amp;diff=19686"/>
		<updated>2015-01-20T04:44:30Z</updated>

		<summary type="html">&lt;p&gt;Ambalica: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;&#039;Reading Response Discussion&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&#039;&#039;&#039;Multics&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
Team: Sameer, Shivjot, Ambalica, Veena&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
Multics is a time sharing OS which provides Multitasking and Multiprogramming. &lt;br /&gt;
&lt;br /&gt;
It provides following features:&lt;br /&gt;
1. Utility Computing&lt;br /&gt;
2. Access Control Lists&lt;br /&gt;
3. Single level storage&lt;br /&gt;
4. Dynamic linking&lt;br /&gt;
  *Sharded libraries or files can be loaded and linked to Random Access Memory at run time. &lt;br /&gt;
5. Hot swapping&lt;br /&gt;
6. Multiprocessing System&lt;br /&gt;
7. Ring oriented Security&lt;br /&gt;
   * It provides number of levels of authorization within the computer System.&lt;br /&gt;
It is not a Distributed OS but it a Centralized system which was written in the assembly language.&lt;/div&gt;</summary>
		<author><name>Ambalica</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_3&amp;diff=19685</id>
		<title>DistOS 2015W Session 3</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_3&amp;diff=19685"/>
		<updated>2015-01-20T04:07:29Z</updated>

		<summary type="html">&lt;p&gt;Ambalica: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;&#039;Reading Response Discussion&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&#039;&#039;&#039;Multics&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
Team: Sameer, Shivjot, Ambalica, Veena&lt;br /&gt;
&lt;br /&gt;
It came into being in the 1960s and it completely vanished in 2000s. It was started by Bell and MIT but Bell backed out of the project in 1969.&lt;br /&gt;
Multics is a time sharing OS which provides Multitasking and Multiprogramming. &lt;br /&gt;
&lt;br /&gt;
It provides following features:&lt;br /&gt;
1. Utility Computing&lt;br /&gt;
2. Access Control Lists&lt;br /&gt;
3. Single level storage&lt;br /&gt;
4. Dynamic linking&lt;br /&gt;
  *Sharded libraries or files can be loaded and linked to Random Access Memory at run time. &lt;br /&gt;
5. Hot swapping&lt;br /&gt;
&lt;br /&gt;
It is not a Distributed OS but it a Centralized system which was written in the assembly language.&lt;/div&gt;</summary>
		<author><name>Ambalica</name></author>
	</entry>
</feed>