https://homeostasis.scs.carleton.ca/wiki/api.php?action=feedcontributions&feedformat=atom&user=Ameti073 2026-06-02T21:08:47Z User contributions MediaWiki 1.42.1 https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_4&diff=19868 2015-02-11T03:37:09Z

<p>Ameti073: /* Supported processor architectures */</p> <hr /> <div>= Andrew File System =<br /> AFS (Andrew File System) was set up as a direct response to NFS. Essentially universities found issues when they tried to scale NFS in a way that would allow them to share files amongst their staff effectively. AFS was more scalable than NFS because read-write operations happened locally before they were committed to the server (data store).<br /> <br /> Since AFS copied files locally when they were opened and only sent the data back when they were closed, all operations during that time are very fast and do need the network. NFS works with files remotely, so there is no data to transfer when opening/closing the file, making those operations instant.<br /> <br /> There are several problems with this design, however.<br /> * The local system must have enough space to temporarily store the file.<br /> * Opening and closing the files requires a lot of bandwidth for large files. To read even a single byte, the entire file must be retrieved (later versions remedied this).<br /> * If the close operation fails, the system will not have the updated version of the file. Many programs don't even check the return value of the close operation, giving users the false impression that everything went well.<br /> <br /> Given all this, AFS was suitable for working with small files, not large ones, limiting its usefulness. It is also notoriously annoying to set up as it is geared towards university-sized networks, further limiting its success.<br /> <br /> <br /> = Amoeba Operating System =<br /> <br /> === Capablities: ===<br /> * Pointer to the object<br /> * Capability assigning right to perform to some operation to the object ticket <br /> * Communicate wide area network <br /> * a kind of ticket or key that allows the holder of the capa- bility to perform some (not neces- sarily all) <br /> * Each user process owns some collection of capabilities, which together define the set of objects it may access and the types of operations that my ne performed on each <br /> * After the server has performed the operation, it sends back a reply message that unblocks the client <br /> * Sending messages, blocking and accepting forms the remote procedure call that can be encapsulate using to make entire remote operation look like local procedure <br /> * Second field: used by the sever to identify which of its objects is being addressed server port and object number identify object which operation to performed <br /> * Generates 48-bit random number <br /> * The third field is the right field which contains a bit map telling which operation the holder of the capability may performed<br /> * X11 Window management<br /> <br /> <br /> === Thread Management: ===<br /> * Same process have multiple thread and each process has its own registered counter and stack <br /> * Behave like process<br /> * It can synchronized using mutex semaphore <br /> * File: Multiple thread, <br /> * Blocked when there's multiple threads <br /> * Buttlet thread the mutex<br /> * The careful reader may have noticed that user process can pull 813kbytes/sec<br /> <br /> = Unique features =<br /> <br /> == Pool processors ==<br /> Pool processors are group of CPUs that are dynamically allocated as user needs. When a program is executed, any of the available processor run.<br /> <br /> == Supported architectures ==<br /> Many different processor architectures are supported including:<br /> &lt;ul&gt;<br /> &lt;li&gt; i80386(Pentium)&lt;/li&gt;<br /> &lt;li&gt;68K&lt;/li&gt;<br /> &lt;li&gt;SPARC&lt;/li&gt;<br /> &lt;/ul&gt;<br /> <br /> = The V Distributed System = <br /> <br /> * First tent in V design: High Performance communication is the most critical facility for distributed systems.<br /> * Second; The protocols, not the software, define the system.<br /> * Third; a relatively small operating system kernel can implement the basic protocols and services providing a simple network-transparent process, address space &amp; communication model.<br /> <br /> === Ideas that significantly affected the design ===<br /> * Shared Memory.<br /> * Dealing with group of entities same as they deal w/individual entities.<br /> * Efficient file caching mechanism using the virtual memory caching mechanism.<br /> <br /> === Design Decisions ===<br /> * Designed for a cluster of workstations with high speed network access ( only really supports LAN ).<br /> * Abstract the physical architecture of the participating workstations, by defining common protocols providing well-defined interfaces.<br /> <br /> V was run on LAN, and its developers developed a really fast IPC protocol which allowed for it to be a fasted distributed operating system in a small geographic area. Aside from the IPC protocols, V also implemented RPC calls in the background.<br /> <br /> V uses the strong consistency model. This model can cause issues with concurrency because in V files are a memory space. Thus two different users accessing the same file and in fact accessing the same memory location. This could result in issues unless there is an effective implementation to deal with multiple versions, etc.<br /> <br /> VMTP protocol was used for communication. It supports request-respond behavior. Besides, it provides transparency, group communication facility and flow control. It is pretty much like TCP.</div>

Ameti073 https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_4&diff=19867 2015-02-11T03:36:41Z

<p>Ameti073: /* Pool processors */</p> <hr /> <div>= Andrew File System =<br /> AFS (Andrew File System) was set up as a direct response to NFS. Essentially universities found issues when they tried to scale NFS in a way that would allow them to share files amongst their staff effectively. AFS was more scalable than NFS because read-write operations happened locally before they were committed to the server (data store).<br /> <br /> Since AFS copied files locally when they were opened and only sent the data back when they were closed, all operations during that time are very fast and do need the network. NFS works with files remotely, so there is no data to transfer when opening/closing the file, making those operations instant.<br /> <br /> There are several problems with this design, however.<br /> * The local system must have enough space to temporarily store the file.<br /> * Opening and closing the files requires a lot of bandwidth for large files. To read even a single byte, the entire file must be retrieved (later versions remedied this).<br /> * If the close operation fails, the system will not have the updated version of the file. Many programs don't even check the return value of the close operation, giving users the false impression that everything went well.<br /> <br /> Given all this, AFS was suitable for working with small files, not large ones, limiting its usefulness. It is also notoriously annoying to set up as it is geared towards university-sized networks, further limiting its success.<br /> <br /> <br /> = Amoeba Operating System =<br /> <br /> === Capablities: ===<br /> * Pointer to the object<br /> * Capability assigning right to perform to some operation to the object ticket <br /> * Communicate wide area network <br /> * a kind of ticket or key that allows the holder of the capa- bility to perform some (not neces- sarily all) <br /> * Each user process owns some collection of capabilities, which together define the set of objects it may access and the types of operations that my ne performed on each <br /> * After the server has performed the operation, it sends back a reply message that unblocks the client <br /> * Sending messages, blocking and accepting forms the remote procedure call that can be encapsulate using to make entire remote operation look like local procedure <br /> * Second field: used by the sever to identify which of its objects is being addressed server port and object number identify object which operation to performed <br /> * Generates 48-bit random number <br /> * The third field is the right field which contains a bit map telling which operation the holder of the capability may performed<br /> * X11 Window management<br /> <br /> <br /> === Thread Management: ===<br /> * Same process have multiple thread and each process has its own registered counter and stack <br /> * Behave like process<br /> * It can synchronized using mutex semaphore <br /> * File: Multiple thread, <br /> * Blocked when there's multiple threads <br /> * Buttlet thread the mutex<br /> * The careful reader may have noticed that user process can pull 813kbytes/sec<br /> <br /> = Unique features =<br /> <br /> == Pool processors ==<br /> Pool processors are group of CPUs that are dynamically allocated as user needs. When a program is executed, any of the available processor run.<br /> <br /> == Supported processor architectures ==<br /> Many different processor architectures are supported including:<br /> &lt;ul&gt;<br /> &lt;li&gt; i80386(Pentium)&lt;/li&gt;<br /> &lt;li&gt;68K&lt;/li&gt;<br /> &lt;li&gt;SPARC&lt;/li&gt;<br /> &lt;/ul&gt;<br /> <br /> = The V Distributed System = <br /> <br /> * First tent in V design: High Performance communication is the most critical facility for distributed systems.<br /> * Second; The protocols, not the software, define the system.<br /> * Third; a relatively small operating system kernel can implement the basic protocols and services providing a simple network-transparent process, address space &amp; communication model.<br /> <br /> === Ideas that significantly affected the design ===<br /> * Shared Memory.<br /> * Dealing with group of entities same as they deal w/individual entities.<br /> * Efficient file caching mechanism using the virtual memory caching mechanism.<br /> <br /> === Design Decisions ===<br /> * Designed for a cluster of workstations with high speed network access ( only really supports LAN ).<br /> * Abstract the physical architecture of the participating workstations, by defining common protocols providing well-defined interfaces.<br /> <br /> V was run on LAN, and its developers developed a really fast IPC protocol which allowed for it to be a fasted distributed operating system in a small geographic area. Aside from the IPC protocols, V also implemented RPC calls in the background.<br /> <br /> V uses the strong consistency model. This model can cause issues with concurrency because in V files are a memory space. Thus two different users accessing the same file and in fact accessing the same memory location. This could result in issues unless there is an effective implementation to deal with multiple versions, etc.<br /> <br /> VMTP protocol was used for communication. It supports request-respond behavior. Besides, it provides transparency, group communication facility and flow control. It is pretty much like TCP.</div>

Ameti073 https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_4&diff=19866 2015-02-11T03:33:45Z

<p>Ameti073: /* Unique features */</p> <hr /> <div>= Andrew File System =<br /> AFS (Andrew File System) was set up as a direct response to NFS. Essentially universities found issues when they tried to scale NFS in a way that would allow them to share files amongst their staff effectively. AFS was more scalable than NFS because read-write operations happened locally before they were committed to the server (data store).<br /> <br /> Since AFS copied files locally when they were opened and only sent the data back when they were closed, all operations during that time are very fast and do need the network. NFS works with files remotely, so there is no data to transfer when opening/closing the file, making those operations instant.<br /> <br /> There are several problems with this design, however.<br /> * The local system must have enough space to temporarily store the file.<br /> * Opening and closing the files requires a lot of bandwidth for large files. To read even a single byte, the entire file must be retrieved (later versions remedied this).<br /> * If the close operation fails, the system will not have the updated version of the file. Many programs don't even check the return value of the close operation, giving users the false impression that everything went well.<br /> <br /> Given all this, AFS was suitable for working with small files, not large ones, limiting its usefulness. It is also notoriously annoying to set up as it is geared towards university-sized networks, further limiting its success.<br /> <br /> <br /> = Amoeba Operating System =<br /> <br /> === Capablities: ===<br /> * Pointer to the object<br /> * Capability assigning right to perform to some operation to the object ticket <br /> * Communicate wide area network <br /> * a kind of ticket or key that allows the holder of the capa- bility to perform some (not neces- sarily all) <br /> * Each user process owns some collection of capabilities, which together define the set of objects it may access and the types of operations that my ne performed on each <br /> * After the server has performed the operation, it sends back a reply message that unblocks the client <br /> * Sending messages, blocking and accepting forms the remote procedure call that can be encapsulate using to make entire remote operation look like local procedure <br /> * Second field: used by the sever to identify which of its objects is being addressed server port and object number identify object which operation to performed <br /> * Generates 48-bit random number <br /> * The third field is the right field which contains a bit map telling which operation the holder of the capability may performed<br /> * X11 Window management<br /> <br /> <br /> === Thread Management: ===<br /> * Same process have multiple thread and each process has its own registered counter and stack <br /> * Behave like process<br /> * It can synchronized using mutex semaphore <br /> * File: Multiple thread, <br /> * Blocked when there's multiple threads <br /> * Buttlet thread the mutex<br /> * The careful reader may have noticed that user process can pull 813kbytes/sec<br /> <br /> = Unique features =<br /> <br /> == Pool processors ==<br /> Pool processors are group of CPUs that are dynamically allocated as user needs. When a program is executed, any of the available processor run.<br /> <br /> = The V Distributed System = <br /> <br /> * First tent in V design: High Performance communication is the most critical facility for distributed systems.<br /> * Second; The protocols, not the software, define the system.<br /> * Third; a relatively small operating system kernel can implement the basic protocols and services providing a simple network-transparent process, address space &amp; communication model.<br /> <br /> === Ideas that significantly affected the design ===<br /> * Shared Memory.<br /> * Dealing with group of entities same as they deal w/individual entities.<br /> * Efficient file caching mechanism using the virtual memory caching mechanism.<br /> <br /> === Design Decisions ===<br /> * Designed for a cluster of workstations with high speed network access ( only really supports LAN ).<br /> * Abstract the physical architecture of the participating workstations, by defining common protocols providing well-defined interfaces.<br /> <br /> V was run on LAN, and its developers developed a really fast IPC protocol which allowed for it to be a fasted distributed operating system in a small geographic area. Aside from the IPC protocols, V also implemented RPC calls in the background.<br /> <br /> V uses the strong consistency model. This model can cause issues with concurrency because in V files are a memory space. Thus two different users accessing the same file and in fact accessing the same memory location. This could result in issues unless there is an effective implementation to deal with multiple versions, etc.<br /> <br /> VMTP protocol was used for communication. It supports request-respond behavior. Besides, it provides transparency, group communication facility and flow control. It is pretty much like TCP.</div>

Ameti073 https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_4&diff=19865 2015-02-11T03:32:50Z

<p>Ameti073: /* Thread Management: */</p> <hr /> <div>= Andrew File System =<br /> AFS (Andrew File System) was set up as a direct response to NFS. Essentially universities found issues when they tried to scale NFS in a way that would allow them to share files amongst their staff effectively. AFS was more scalable than NFS because read-write operations happened locally before they were committed to the server (data store).<br /> <br /> Since AFS copied files locally when they were opened and only sent the data back when they were closed, all operations during that time are very fast and do need the network. NFS works with files remotely, so there is no data to transfer when opening/closing the file, making those operations instant.<br /> <br /> There are several problems with this design, however.<br /> * The local system must have enough space to temporarily store the file.<br /> * Opening and closing the files requires a lot of bandwidth for large files. To read even a single byte, the entire file must be retrieved (later versions remedied this).<br /> * If the close operation fails, the system will not have the updated version of the file. Many programs don't even check the return value of the close operation, giving users the false impression that everything went well.<br /> <br /> Given all this, AFS was suitable for working with small files, not large ones, limiting its usefulness. It is also notoriously annoying to set up as it is geared towards university-sized networks, further limiting its success.<br /> <br /> <br /> = Amoeba Operating System =<br /> <br /> === Capablities: ===<br /> * Pointer to the object<br /> * Capability assigning right to perform to some operation to the object ticket <br /> * Communicate wide area network <br /> * a kind of ticket or key that allows the holder of the capa- bility to perform some (not neces- sarily all) <br /> * Each user process owns some collection of capabilities, which together define the set of objects it may access and the types of operations that my ne performed on each <br /> * After the server has performed the operation, it sends back a reply message that unblocks the client <br /> * Sending messages, blocking and accepting forms the remote procedure call that can be encapsulate using to make entire remote operation look like local procedure <br /> * Second field: used by the sever to identify which of its objects is being addressed server port and object number identify object which operation to performed <br /> * Generates 48-bit random number <br /> * The third field is the right field which contains a bit map telling which operation the holder of the capability may performed<br /> * X11 Window management<br /> <br /> <br /> = Unique features =<br /> <br /> == Pool processors ==<br /> Pool processors are group of CPUs that are dynamically allocated as user needs. When a program is executed, any of the available processor run.<br /> <br /> === Thread Management: ===<br /> * Same process have multiple thread and each process has its own registered counter and stack <br /> * Behave like process<br /> * It can synchronized using mutex semaphore <br /> * File: Multiple thread, <br /> * Blocked when there's multiple threads <br /> * Buttlet thread the mutex<br /> * The careful reader may have noticed that user process can pull 813kbytes/sec<br /> <br /> = Unique features =<br /> <br /> == Pool processors ==<br /> Pool processors are group of CPUs that are dynamically allocated as user needs. When a program is executed, any of the available processor run.<br /> <br /> = The V Distributed System = <br /> <br /> * First tent in V design: High Performance communication is the most critical facility for distributed systems.<br /> * Second; The protocols, not the software, define the system.<br /> * Third; a relatively small operating system kernel can implement the basic protocols and services providing a simple network-transparent process, address space &amp; communication model.<br /> <br /> === Ideas that significantly affected the design ===<br /> * Shared Memory.<br /> * Dealing with group of entities same as they deal w/individual entities.<br /> * Efficient file caching mechanism using the virtual memory caching mechanism.<br /> <br /> === Design Decisions ===<br /> * Designed for a cluster of workstations with high speed network access ( only really supports LAN ).<br /> * Abstract the physical architecture of the participating workstations, by defining common protocols providing well-defined interfaces.<br /> <br /> V was run on LAN, and its developers developed a really fast IPC protocol which allowed for it to be a fasted distributed operating system in a small geographic area. Aside from the IPC protocols, V also implemented RPC calls in the background.<br /> <br /> V uses the strong consistency model. This model can cause issues with concurrency because in V files are a memory space. Thus two different users accessing the same file and in fact accessing the same memory location. This could result in issues unless there is an effective implementation to deal with multiple versions, etc.<br /> <br /> VMTP protocol was used for communication. It supports request-respond behavior. Besides, it provides transparency, group communication facility and flow control. It is pretty much like TCP.</div>

Ameti073 https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_4&diff=19864 2015-02-11T03:32:21Z

<p>Ameti073: /* Pool processors */</p> <hr /> <div>= Andrew File System =<br /> AFS (Andrew File System) was set up as a direct response to NFS. Essentially universities found issues when they tried to scale NFS in a way that would allow them to share files amongst their staff effectively. AFS was more scalable than NFS because read-write operations happened locally before they were committed to the server (data store).<br /> <br /> Since AFS copied files locally when they were opened and only sent the data back when they were closed, all operations during that time are very fast and do need the network. NFS works with files remotely, so there is no data to transfer when opening/closing the file, making those operations instant.<br /> <br /> There are several problems with this design, however.<br /> * The local system must have enough space to temporarily store the file.<br /> * Opening and closing the files requires a lot of bandwidth for large files. To read even a single byte, the entire file must be retrieved (later versions remedied this).<br /> * If the close operation fails, the system will not have the updated version of the file. Many programs don't even check the return value of the close operation, giving users the false impression that everything went well.<br /> <br /> Given all this, AFS was suitable for working with small files, not large ones, limiting its usefulness. It is also notoriously annoying to set up as it is geared towards university-sized networks, further limiting its success.<br /> <br /> <br /> = Amoeba Operating System =<br /> <br /> === Capablities: ===<br /> * Pointer to the object<br /> * Capability assigning right to perform to some operation to the object ticket <br /> * Communicate wide area network <br /> * a kind of ticket or key that allows the holder of the capa- bility to perform some (not neces- sarily all) <br /> * Each user process owns some collection of capabilities, which together define the set of objects it may access and the types of operations that my ne performed on each <br /> * After the server has performed the operation, it sends back a reply message that unblocks the client <br /> * Sending messages, blocking and accepting forms the remote procedure call that can be encapsulate using to make entire remote operation look like local procedure <br /> * Second field: used by the sever to identify which of its objects is being addressed server port and object number identify object which operation to performed <br /> * Generates 48-bit random number <br /> * The third field is the right field which contains a bit map telling which operation the holder of the capability may performed<br /> * X11 Window management<br /> <br /> <br /> = Unique features =<br /> <br /> == Pool processors ==<br /> Pool processors are group of CPUs that are dynamically allocated as user needs. When a program is executed, any of the available processor run.<br /> <br /> === Thread Management: ===<br /> * Same process have multiple thread and each process has its own registered counter and stack <br /> * Behave like process<br /> * It can synchronized using mutex semaphore <br /> * File: Multiple thread, <br /> * Blocked when there's multiple threads <br /> * Buttlet thread the mutex<br /> * The careful reader may have noticed that user process can pull 813kbytes/sec<br /> <br /> = The V Distributed System = <br /> <br /> * First tent in V design: High Performance communication is the most critical facility for distributed systems.<br /> * Second; The protocols, not the software, define the system.<br /> * Third; a relatively small operating system kernel can implement the basic protocols and services providing a simple network-transparent process, address space &amp; communication model.<br /> <br /> === Ideas that significantly affected the design ===<br /> * Shared Memory.<br /> * Dealing with group of entities same as they deal w/individual entities.<br /> * Efficient file caching mechanism using the virtual memory caching mechanism.<br /> <br /> === Design Decisions ===<br /> * Designed for a cluster of workstations with high speed network access ( only really supports LAN ).<br /> * Abstract the physical architecture of the participating workstations, by defining common protocols providing well-defined interfaces.<br /> <br /> V was run on LAN, and its developers developed a really fast IPC protocol which allowed for it to be a fasted distributed operating system in a small geographic area. Aside from the IPC protocols, V also implemented RPC calls in the background.<br /> <br /> V uses the strong consistency model. This model can cause issues with concurrency because in V files are a memory space. Thus two different users accessing the same file and in fact accessing the same memory location. This could result in issues unless there is an effective implementation to deal with multiple versions, etc.<br /> <br /> VMTP protocol was used for communication. It supports request-respond behavior. Besides, it provides transparency, group communication facility and flow control. It is pretty much like TCP.</div>

Ameti073 https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_4&diff=19863 2015-02-11T03:30:17Z

<p>Ameti073: /* Capablities: */</p> <hr /> <div>= Andrew File System =<br /> AFS (Andrew File System) was set up as a direct response to NFS. Essentially universities found issues when they tried to scale NFS in a way that would allow them to share files amongst their staff effectively. AFS was more scalable than NFS because read-write operations happened locally before they were committed to the server (data store).<br /> <br /> Since AFS copied files locally when they were opened and only sent the data back when they were closed, all operations during that time are very fast and do need the network. NFS works with files remotely, so there is no data to transfer when opening/closing the file, making those operations instant.<br /> <br /> There are several problems with this design, however.<br /> * The local system must have enough space to temporarily store the file.<br /> * Opening and closing the files requires a lot of bandwidth for large files. To read even a single byte, the entire file must be retrieved (later versions remedied this).<br /> * If the close operation fails, the system will not have the updated version of the file. Many programs don't even check the return value of the close operation, giving users the false impression that everything went well.<br /> <br /> Given all this, AFS was suitable for working with small files, not large ones, limiting its usefulness. It is also notoriously annoying to set up as it is geared towards university-sized networks, further limiting its success.<br /> <br /> <br /> = Amoeba Operating System =<br /> <br /> === Capablities: ===<br /> * Pointer to the object<br /> * Capability assigning right to perform to some operation to the object ticket <br /> * Communicate wide area network <br /> * a kind of ticket or key that allows the holder of the capa- bility to perform some (not neces- sarily all) <br /> * Each user process owns some collection of capabilities, which together define the set of objects it may access and the types of operations that my ne performed on each <br /> * After the server has performed the operation, it sends back a reply message that unblocks the client <br /> * Sending messages, blocking and accepting forms the remote procedure call that can be encapsulate using to make entire remote operation look like local procedure <br /> * Second field: used by the sever to identify which of its objects is being addressed server port and object number identify object which operation to performed <br /> * Generates 48-bit random number <br /> * The third field is the right field which contains a bit map telling which operation the holder of the capability may performed<br /> * X11 Window management<br /> <br /> <br /> = Unique features =<br /> <br /> == Pool processors ==<br /> <br /> === Thread Management: ===<br /> * Same process have multiple thread and each process has its own registered counter and stack <br /> * Behave like process<br /> * It can synchronized using mutex semaphore <br /> * File: Multiple thread, <br /> * Blocked when there's multiple threads <br /> * Buttlet thread the mutex<br /> * The careful reader may have noticed that user process can pull 813kbytes/sec<br /> <br /> <br /> = The V Distributed System = <br /> <br /> * First tent in V design: High Performance communication is the most critical facility for distributed systems.<br /> * Second; The protocols, not the software, define the system.<br /> * Third; a relatively small operating system kernel can implement the basic protocols and services providing a simple network-transparent process, address space &amp; communication model.<br /> <br /> === Ideas that significantly affected the design ===<br /> * Shared Memory.<br /> * Dealing with group of entities same as they deal w/individual entities.<br /> * Efficient file caching mechanism using the virtual memory caching mechanism.<br /> <br /> === Design Decisions ===<br /> * Designed for a cluster of workstations with high speed network access ( only really supports LAN ).<br /> * Abstract the physical architecture of the participating workstations, by defining common protocols providing well-defined interfaces.<br /> <br /> V was run on LAN, and its developers developed a really fast IPC protocol which allowed for it to be a fasted distributed operating system in a small geographic area. Aside from the IPC protocols, V also implemented RPC calls in the background.<br /> <br /> V uses the strong consistency model. This model can cause issues with concurrency because in V files are a memory space. Thus two different users accessing the same file and in fact accessing the same memory location. This could result in issues unless there is an effective implementation to deal with multiple versions, etc.<br /> <br /> VMTP protocol was used for communication. It supports request-respond behavior. Besides, it provides transparency, group communication facility and flow control. It is pretty much like TCP.</div>

Ameti073 https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_5&diff=19862 2015-02-11T03:23:25Z

<p>Ameti073: /* Similaritieis with the UNIX */</p> <hr /> <div><br /> = The Clouds Distributed Operating System =<br /> 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.<br /> <br /> The OS is based on 2 patterns:<br /> * Message Based OS<br /> * Object Based OS<br /> <br /> == Object Thread Model ==<br /> <br /> The structure of this is based on object thread model. It has set of objects which are defined by the class. Objects respond to messages. Sending message to object causes object to execute the method and then reply back. <br /> <br /> The system has '''active objects''' and '''passive objects'''.<br /> <br /> # Active objects are the objects which have one or more processes associated with them and further they can communicate with the external environment. <br /> # Passive objects are those that currently do not have an active thread executing in them.<br /> <br /> The content of the Clouds data is long lived. Since the memory is implemented as a single-level store, the data exists forever and can survive system crashes and shut downs.<br /> <br /> == Threads ==<br /> <br /> The threads are the logical path of execution that traverse objects and executes code in them. The Clouds thread is not bound to a single address space. Several threads can enter an object simultaneously and execute concurrently. The nature of the Clouds object prohibits a thread from accessing any data outside the current address space in which it is executing.<br /> <br /> == Interaction Between Objects and Threads ==<br /> <br /> # Inter object interfaces are procedural<br /> # Invocations work across machine boundaries<br /> # Objects in clouds unify concept of persistent storage and memory to create address space, thus making the programming simpler.<br /> # Control flow achieved by threads invoking objects.<br /> <br /> == Clouds Environment ==<br /> <br /> # Integrates set of homogeneous machines into one seamless environment<br /> # There are three logical categories of machines- Compute Server, User Workstation and Data server.<br /> <br /> <br /> = Plan 9 =<br /> <br /> Plan 9 is a general purpose, multi-user and mobile computing environment physically distributed across machines. Development of the system began in the late 1980s. The system was built at Bell Labs - the birth place of Unix. The original Unix OS had no support for networking, and there were many attempts over the years by others to create distributed systems with Unix compatibility. Plan 9, however, is distributed systems done following the original Unix philosophy.<br /> <br /> The goals of this system were:<br /> # To built a distributed system that can be centrally administered.<br /> # Be cost effective using cheap, modern microcomputers. <br /> <br /> The distribution itself is transparent to most programs. This property is made possible by 2 properties:<br /> # A per process group namespace.<br /> # Uniform access to most resources by representing them as a file.<br /> <br /> == Unix Compatibility ==<br /> <br /> 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.<br /> <br /> <br /> == Similaritieis with the UNIX ==<br /> &lt;ul&gt;<br /> &lt;li&gt;shell&lt;/li&gt;<br /> &lt;li&gt;Various C compilers&lt;/li&gt;<br /> &lt;/ul&gt;<br /> <br /> == Unique Features ==<br /> <br /> What actually distinguishes Plan 9 is its '''organization'''. Plan 9 is divided along the lines of service function.<br /> * CPU services and terminals use same kernel.<br /> * Users may choose to run programs locally or remotely on CPU servers.<br /> * It lets the user choose whether they want a distributed or centralized system.<br /> <br /> The design of Plan 9 is based on 3 principles:<br /> # Resources are named and accessed like files in hierarchical file system.<br /> # Standard protocol 9P.<br /> # Disjoint hierarchical provided by different services are joined together into single private hierarchical file name space.<br /> <br /> === Virtual Namespaces ===<br /> <br /> In a virtual namespace, a user boots a terminal or connects to a CPU server and then a new process group is created. Processes in group can either add to or rearrange their name space using two system calls - mount and bind.<br /> <br /> * '''Mount''' is used to attach new file system to a point in name space.<br /> * '''Bind''' is used to attach a kernel resident (existing, mounted) file system to name space and also arrange pieces of name space.<br /> * There is also '''unbind''' which undoes the effects of the other two calls.<br /> <br /> Namespaces in Plan 9 are on a per-process basis. While everything had a way reference resources with a unique name, using mount and bind, every process could also build their namespace as they saw fit.<br /> <br /> Since most resources are in the form of files (and folders), the term ''namespace'' really only refers to the filesystem layout.<br /> <br /> === Parallel Programming ===<br /> The parallel programming has two aspects:<br /> * Kernel provides simple process model and carefully designed system calls for synchronization.<br /> * Programming language supports concurrent programming.<br /> <br /> == Legacy ==<br /> <br /> Even though Plan 9 is no longer developed, the good ideas from the system still exist today. For example, the ''/proc'' virtual filesystem which displays current process information in the form of files exists in moden Linux kernels.<br /> <br /> <br /> = Google File System =<br /> <br /> It is scalable, distributed file system for large, data intensive applications. It is crafted to Google's unique needs as a search engine company.<br /> <br /> Unlike most filesystems, GFS must be implemented by individual applications and is not part of the kernel. While this introduces some technical overhead, it gives the system more freedom to implement or not implement certain non-standard features.<br /> <br /> == Architecture ==<br /> <br /> The architecture of the Google file system consists of a single master, multiple chunk-servers and multiple clients. Chunk servers are used to store the data in uniformly sized chunks. Each chunk is identified by globally unique 64 bit handle assigned by master at the time of creation. The chunks are split into 64KB blocks, each with its own hashsum for data integrity checks. The chunks are replicated between servers, 3 by default. The master maintains all the file system metadata which includes the namespace and chunk location.<br /> <br /> Each of the chunks is 64 MB large (contrast this to the typical filesystem sectors of 512 or 4096 bytes) as the system is meant to hold enormous amount of data - namely the internet. The large chunk size is also important for the scalability of the system - the larger the chunk size, the less metadata the master server has to store for any given amount of data. With the current size, the master server is able to store the entirety of the metadata in memory, increasing performance by a significant margin.<br /> <br /> == Operation ==<br /> <br /> Master and Chunk server communication consists of<br /> # checking whether there is any chunk-server is down.<br /> # checking if any file is corrupted.<br /> # deleting stale chunks<br /> <br /> When a client want to do some operations on the chunks<br /> # it first asks the master server for the list of servers that store the parts of a file it wants to access<br /> # it receives a list of chunk servers, with multiple servers for each chunk<br /> # it finally communicates with the the chunk servers to perform the operation<br /> <br /> The system is geared towards appends and sequential reads. This is why the master server responds with multiple server addresses for each chunk - the client can then request a small piece from each server, increasing the data throughput linearly with the number of servers. Writes, in general, are in the form of a special ''append'' system call. When appending, there is no chance that two clients will want to write to the same location at the same time. This helps avoid any potential synchronization issues. If there are multiple appends to the same file at the same time, the chunk servers are free to order them as they wish (chunks on each server are not guaranteed to be byte-for-byte identical). While a problem in the general sense, this is good enough for Google's needs.<br /> <br /> == Redundancy ==<br /> <br /> GFS is built with failure in mind. The system expects that at any time, there is some server or disk that is malfunctioning. The system deals with the failures as follows.<br /> <br /> === Chunk Servers ===<br /> <br /> By default, chunks are replicated to three servers. This exact number depends on the application in question doing the write. When a chunk server finds that some of its data is corrupt, it grabs the data from other servers to repair itself{{Citation needed}}.<br /> <br /> === Master Server ===<br /> <br /> For efficiency, there is only a single live master server at a time. While not making the system completely distributed, it avoid many synchronization problems and suits Google's needs. At any point in time, there are multiple read-only master servers that copy metadata from the currently live master. Should it go down, they will serve any read operations from the clients, until one of the hot spares is promoted to being the new live master server.</div>

Ameti073 https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_5&diff=19861 2015-02-11T03:22:09Z

<p>Ameti073: /* Similaritieis with the UNIX */</p> <hr /> <div><br /> = The Clouds Distributed Operating System =<br /> 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.<br /> <br /> The OS is based on 2 patterns:<br /> * Message Based OS<br /> * Object Based OS<br /> <br /> == Object Thread Model ==<br /> <br /> The structure of this is based on object thread model. It has set of objects which are defined by the class. Objects respond to messages. Sending message to object causes object to execute the method and then reply back. <br /> <br /> The system has '''active objects''' and '''passive objects'''.<br /> <br /> # Active objects are the objects which have one or more processes associated with them and further they can communicate with the external environment. <br /> # Passive objects are those that currently do not have an active thread executing in them.<br /> <br /> The content of the Clouds data is long lived. Since the memory is implemented as a single-level store, the data exists forever and can survive system crashes and shut downs.<br /> <br /> == Threads ==<br /> <br /> The threads are the logical path of execution that traverse objects and executes code in them. The Clouds thread is not bound to a single address space. Several threads can enter an object simultaneously and execute concurrently. The nature of the Clouds object prohibits a thread from accessing any data outside the current address space in which it is executing.<br /> <br /> == Interaction Between Objects and Threads ==<br /> <br /> # Inter object interfaces are procedural<br /> # Invocations work across machine boundaries<br /> # Objects in clouds unify concept of persistent storage and memory to create address space, thus making the programming simpler.<br /> # Control flow achieved by threads invoking objects.<br /> <br /> == Clouds Environment ==<br /> <br /> # Integrates set of homogeneous machines into one seamless environment<br /> # There are three logical categories of machines- Compute Server, User Workstation and Data server.<br /> <br /> <br /> = Plan 9 =<br /> <br /> Plan 9 is a general purpose, multi-user and mobile computing environment physically distributed across machines. Development of the system began in the late 1980s. The system was built at Bell Labs - the birth place of Unix. The original Unix OS had no support for networking, and there were many attempts over the years by others to create distributed systems with Unix compatibility. Plan 9, however, is distributed systems done following the original Unix philosophy.<br /> <br /> The goals of this system were:<br /> # To built a distributed system that can be centrally administered.<br /> # Be cost effective using cheap, modern microcomputers. <br /> <br /> The distribution itself is transparent to most programs. This property is made possible by 2 properties:<br /> # A per process group namespace.<br /> # Uniform access to most resources by representing them as a file.<br /> <br /> == Unix Compatibility ==<br /> <br /> 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.<br /> <br /> <br /> == Similaritieis with the UNIX ==<br /> &lt;ul&gt;&lt;li&gt;sdfsdf&lt;/li&gt;&lt;/ul&gt;<br /> <br /> == Unique Features ==<br /> <br /> What actually distinguishes Plan 9 is its '''organization'''. Plan 9 is divided along the lines of service function.<br /> * CPU services and terminals use same kernel.<br /> * Users may choose to run programs locally or remotely on CPU servers.<br /> * It lets the user choose whether they want a distributed or centralized system.<br /> <br /> The design of Plan 9 is based on 3 principles:<br /> # Resources are named and accessed like files in hierarchical file system.<br /> # Standard protocol 9P.<br /> # Disjoint hierarchical provided by different services are joined together into single private hierarchical file name space.<br /> <br /> === Virtual Namespaces ===<br /> <br /> In a virtual namespace, a user boots a terminal or connects to a CPU server and then a new process group is created. Processes in group can either add to or rearrange their name space using two system calls - mount and bind.<br /> <br /> * '''Mount''' is used to attach new file system to a point in name space.<br /> * '''Bind''' is used to attach a kernel resident (existing, mounted) file system to name space and also arrange pieces of name space.<br /> * There is also '''unbind''' which undoes the effects of the other two calls.<br /> <br /> Namespaces in Plan 9 are on a per-process basis. While everything had a way reference resources with a unique name, using mount and bind, every process could also build their namespace as they saw fit.<br /> <br /> Since most resources are in the form of files (and folders), the term ''namespace'' really only refers to the filesystem layout.<br /> <br /> === Parallel Programming ===<br /> The parallel programming has two aspects:<br /> * Kernel provides simple process model and carefully designed system calls for synchronization.<br /> * Programming language supports concurrent programming.<br /> <br /> == Legacy ==<br /> <br /> Even though Plan 9 is no longer developed, the good ideas from the system still exist today. For example, the ''/proc'' virtual filesystem which displays current process information in the form of files exists in moden Linux kernels.<br /> <br /> <br /> = Google File System =<br /> <br /> It is scalable, distributed file system for large, data intensive applications. It is crafted to Google's unique needs as a search engine company.<br /> <br /> Unlike most filesystems, GFS must be implemented by individual applications and is not part of the kernel. While this introduces some technical overhead, it gives the system more freedom to implement or not implement certain non-standard features.<br /> <br /> == Architecture ==<br /> <br /> The architecture of the Google file system consists of a single master, multiple chunk-servers and multiple clients. Chunk servers are used to store the data in uniformly sized chunks. Each chunk is identified by globally unique 64 bit handle assigned by master at the time of creation. The chunks are split into 64KB blocks, each with its own hashsum for data integrity checks. The chunks are replicated between servers, 3 by default. The master maintains all the file system metadata which includes the namespace and chunk location.<br /> <br /> Each of the chunks is 64 MB large (contrast this to the typical filesystem sectors of 512 or 4096 bytes) as the system is meant to hold enormous amount of data - namely the internet. The large chunk size is also important for the scalability of the system - the larger the chunk size, the less metadata the master server has to store for any given amount of data. With the current size, the master server is able to store the entirety of the metadata in memory, increasing performance by a significant margin.<br /> <br /> == Operation ==<br /> <br /> Master and Chunk server communication consists of<br /> # checking whether there is any chunk-server is down.<br /> # checking if any file is corrupted.<br /> # deleting stale chunks<br /> <br /> When a client want to do some operations on the chunks<br /> # it first asks the master server for the list of servers that store the parts of a file it wants to access<br /> # it receives a list of chunk servers, with multiple servers for each chunk<br /> # it finally communicates with the the chunk servers to perform the operation<br /> <br /> The system is geared towards appends and sequential reads. This is why the master server responds with multiple server addresses for each chunk - the client can then request a small piece from each server, increasing the data throughput linearly with the number of servers. Writes, in general, are in the form of a special ''append'' system call. When appending, there is no chance that two clients will want to write to the same location at the same time. This helps avoid any potential synchronization issues. If there are multiple appends to the same file at the same time, the chunk servers are free to order them as they wish (chunks on each server are not guaranteed to be byte-for-byte identical). While a problem in the general sense, this is good enough for Google's needs.<br /> <br /> == Redundancy ==<br /> <br /> GFS is built with failure in mind. The system expects that at any time, there is some server or disk that is malfunctioning. The system deals with the failures as follows.<br /> <br /> === Chunk Servers ===<br /> <br /> By default, chunks are replicated to three servers. This exact number depends on the application in question doing the write. When a chunk server finds that some of its data is corrupt, it grabs the data from other servers to repair itself{{Citation needed}}.<br /> <br /> === Master Server ===<br /> <br /> For efficiency, there is only a single live master server at a time. While not making the system completely distributed, it avoid many synchronization problems and suits Google's needs. At any point in time, there are multiple read-only master servers that copy metadata from the currently live master. Should it go down, they will serve any read operations from the clients, until one of the hot spares is promoted to being the new live master server.</div>

Ameti073 https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_5&diff=19860 2015-02-11T03:21:37Z

<p>Ameti073: /* Unix Compatibility */</p> <hr /> <div><br /> = The Clouds Distributed Operating System =<br /> 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.<br /> <br /> The OS is based on 2 patterns:<br /> * Message Based OS<br /> * Object Based OS<br /> <br /> == Object Thread Model ==<br /> <br /> The structure of this is based on object thread model. It has set of objects which are defined by the class. Objects respond to messages. Sending message to object causes object to execute the method and then reply back. <br /> <br /> The system has '''active objects''' and '''passive objects'''.<br /> <br /> # Active objects are the objects which have one or more processes associated with them and further they can communicate with the external environment. <br /> # Passive objects are those that currently do not have an active thread executing in them.<br /> <br /> The content of the Clouds data is long lived. Since the memory is implemented as a single-level store, the data exists forever and can survive system crashes and shut downs.<br /> <br /> == Threads ==<br /> <br /> The threads are the logical path of execution that traverse objects and executes code in them. The Clouds thread is not bound to a single address space. Several threads can enter an object simultaneously and execute concurrently. The nature of the Clouds object prohibits a thread from accessing any data outside the current address space in which it is executing.<br /> <br /> == Interaction Between Objects and Threads ==<br /> <br /> # Inter object interfaces are procedural<br /> # Invocations work across machine boundaries<br /> # Objects in clouds unify concept of persistent storage and memory to create address space, thus making the programming simpler.<br /> # Control flow achieved by threads invoking objects.<br /> <br /> == Clouds Environment ==<br /> <br /> # Integrates set of homogeneous machines into one seamless environment<br /> # There are three logical categories of machines- Compute Server, User Workstation and Data server.<br /> <br /> <br /> = Plan 9 =<br /> <br /> Plan 9 is a general purpose, multi-user and mobile computing environment physically distributed across machines. Development of the system began in the late 1980s. The system was built at Bell Labs - the birth place of Unix. The original Unix OS had no support for networking, and there were many attempts over the years by others to create distributed systems with Unix compatibility. Plan 9, however, is distributed systems done following the original Unix philosophy.<br /> <br /> The goals of this system were:<br /> # To built a distributed system that can be centrally administered.<br /> # Be cost effective using cheap, modern microcomputers. <br /> <br /> The distribution itself is transparent to most programs. This property is made possible by 2 properties:<br /> # A per process group namespace.<br /> # Uniform access to most resources by representing them as a file.<br /> <br /> == Unix Compatibility ==<br /> <br /> 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.<br /> <br /> <br /> == Similaritieis with the UNIX ==<br /> &lt;li&gt;sdfsdf&lt;/li&gt;<br /> <br /> == Unique Features ==<br /> <br /> What actually distinguishes Plan 9 is its '''organization'''. Plan 9 is divided along the lines of service function.<br /> * CPU services and terminals use same kernel.<br /> * Users may choose to run programs locally or remotely on CPU servers.<br /> * It lets the user choose whether they want a distributed or centralized system.<br /> <br /> The design of Plan 9 is based on 3 principles:<br /> # Resources are named and accessed like files in hierarchical file system.<br /> # Standard protocol 9P.<br /> # Disjoint hierarchical provided by different services are joined together into single private hierarchical file name space.<br /> <br /> === Virtual Namespaces ===<br /> <br /> In a virtual namespace, a user boots a terminal or connects to a CPU server and then a new process group is created. Processes in group can either add to or rearrange their name space using two system calls - mount and bind.<br /> <br /> * '''Mount''' is used to attach new file system to a point in name space.<br /> * '''Bind''' is used to attach a kernel resident (existing, mounted) file system to name space and also arrange pieces of name space.<br /> * There is also '''unbind''' which undoes the effects of the other two calls.<br /> <br /> Namespaces in Plan 9 are on a per-process basis. While everything had a way reference resources with a unique name, using mount and bind, every process could also build their namespace as they saw fit.<br /> <br /> Since most resources are in the form of files (and folders), the term ''namespace'' really only refers to the filesystem layout.<br /> <br /> === Parallel Programming ===<br /> The parallel programming has two aspects:<br /> * Kernel provides simple process model and carefully designed system calls for synchronization.<br /> * Programming language supports concurrent programming.<br /> <br /> == Legacy ==<br /> <br /> Even though Plan 9 is no longer developed, the good ideas from the system still exist today. For example, the ''/proc'' virtual filesystem which displays current process information in the form of files exists in moden Linux kernels.<br /> <br /> <br /> = Google File System =<br /> <br /> It is scalable, distributed file system for large, data intensive applications. It is crafted to Google's unique needs as a search engine company.<br /> <br /> Unlike most filesystems, GFS must be implemented by individual applications and is not part of the kernel. While this introduces some technical overhead, it gives the system more freedom to implement or not implement certain non-standard features.<br /> <br /> == Architecture ==<br /> <br /> The architecture of the Google file system consists of a single master, multiple chunk-servers and multiple clients. Chunk servers are used to store the data in uniformly sized chunks. Each chunk is identified by globally unique 64 bit handle assigned by master at the time of creation. The chunks are split into 64KB blocks, each with its own hashsum for data integrity checks. The chunks are replicated between servers, 3 by default. The master maintains all the file system metadata which includes the namespace and chunk location.<br /> <br /> Each of the chunks is 64 MB large (contrast this to the typical filesystem sectors of 512 or 4096 bytes) as the system is meant to hold enormous amount of data - namely the internet. The large chunk size is also important for the scalability of the system - the larger the chunk size, the less metadata the master server has to store for any given amount of data. With the current size, the master server is able to store the entirety of the metadata in memory, increasing performance by a significant margin.<br /> <br /> == Operation ==<br /> <br /> Master and Chunk server communication consists of<br /> # checking whether there is any chunk-server is down.<br /> # checking if any file is corrupted.<br /> # deleting stale chunks<br /> <br /> When a client want to do some operations on the chunks<br /> # it first asks the master server for the list of servers that store the parts of a file it wants to access<br /> # it receives a list of chunk servers, with multiple servers for each chunk<br /> # it finally communicates with the the chunk servers to perform the operation<br /> <br /> The system is geared towards appends and sequential reads. This is why the master server responds with multiple server addresses for each chunk - the client can then request a small piece from each server, increasing the data throughput linearly with the number of servers. Writes, in general, are in the form of a special ''append'' system call. When appending, there is no chance that two clients will want to write to the same location at the same time. This helps avoid any potential synchronization issues. If there are multiple appends to the same file at the same time, the chunk servers are free to order them as they wish (chunks on each server are not guaranteed to be byte-for-byte identical). While a problem in the general sense, this is good enough for Google's needs.<br /> <br /> == Redundancy ==<br /> <br /> GFS is built with failure in mind. The system expects that at any time, there is some server or disk that is malfunctioning. The system deals with the failures as follows.<br /> <br /> === Chunk Servers ===<br /> <br /> By default, chunks are replicated to three servers. This exact number depends on the application in question doing the write. When a chunk server finds that some of its data is corrupt, it grabs the data from other servers to repair itself{{Citation needed}}.<br /> <br /> === Master Server ===<br /> <br /> For efficiency, there is only a single live master server at a time. While not making the system completely distributed, it avoid many synchronization problems and suits Google's needs. At any point in time, there are multiple read-only master servers that copy metadata from the currently live master. Should it go down, they will serve any read operations from the clients, until one of the hot spares is promoted to being the new live master server.</div>

Ameti073 https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_4&diff=19803 2015-02-05T04:01:44Z

<p>Ameti073: /* Design Decisions */</p> <hr /> <div>= Andrew File System =<br /> AFS (Andrew File System) was set up as a direct response to NFS. Essentially universities found issues when they tried to scale NFS in a way that would allow them to share files amongst their staff effectively. AFS was more scalable than NFS because read-write operations happened locally before they were committed to the server (data store). As such the largest file size that AFS could deal with was the size of its local disk cache. <br /> <br /> AFS open-close operations were more time-consuming, while for NFS its read-write operations were more time consuming.<br /> <br /> = Amoeba Operating System =<br /> <br /> === Capablities: ===<br /> * Pointer to the object<br /> * Capability assigning right to perform to some operation to the object ticket <br /> * Communicate wide area network <br /> * a kind of ticket or key that allows the holder of the capa- bility to perform some (not neces- sarily all) <br /> * Each user process owns some collection of capabilities, which together define the set of objects it may access and the types of operations that my ne performed on each <br /> * After the server has performed the operation, it sends back a reply message that unblocks the client <br /> * Sending messages, blocking and accepting forms the remote procedure call that can be encapsulate using to make entire remote operation look like local procedure <br /> * Second field: used by the sever to identify which of its objects is being addressed server port and object number identify object which operation to performed <br /> * Generates 48-bit random number <br /> * The third field is the right field which contains a bit map telling which operation the holder of the capability may performed<br /> * X11 Window management<br /> <br /> === Thread Management: ===<br /> * Same process have multiple thread and each process has its own registered counter and stack <br /> * Behave like process<br /> * It can synchronized using mutex semaphore <br /> * File: Multiple thread, <br /> * Blocked when there's multiple threads <br /> * Buttlet thread the mutex<br /> * The careful reader may have noticed that user process can pull 813kbytes/sec<br /> <br /> <br /> = The V Distributed System = <br /> <br /> * First tent in V design: High Performance communication is the most critical facility for distributed systems.<br /> * Second; The protocols, not the software, define the system.<br /> * Third; a relatively small operating system kernel can implement the basic protocols and services providing a simple network-transparent process, address space &amp; communication model.<br /> <br /> === Ideas that significantly affected the design ===<br /> * Shared Memory.<br /> * Dealing with group of entities same as they deal w/individual entities.<br /> * Efficient file caching mechanism using the virtual memory caching mechanism.<br /> <br /> === Design Decisions ===<br /> * Designed for a cluster of workstations with high speed network access ( only really supports LAN ).<br /> * Abstract the physical architecture of the participating workstations, by defining common protocols providing well-defined interfaces.<br /> <br /> V was run on LAN, and its developers developed a really fast IPC protocol which allowed for it to be a fasted distributed operating system in a small geographic area. Aside from the IPC protocols, V also implemented RPC calls in the background.<br /> <br /> V uses the strong consistency model. This model can cause issues with concurrency because in V files are a memory space. Thus two different users accessing the same file and in fact accessing the same memory location. This could result in issues unless there is an effective implementation to deal with multiple versions, etc.<br /> <br /> VMTP protocol was used for communication. It supports request-respond behavior. Besides, it provides transparency, group communication facility and flow control. It is pretty much like TCP.</div>

Ameti073 https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_4&diff=19802 2015-02-05T04:00:07Z

<p>Ameti073: /* Capablities: */</p> <hr /> <div>= Andrew File System =<br /> AFS (Andrew File System) was set up as a direct response to NFS. Essentially universities found issues when they tried to scale NFS in a way that would allow them to share files amongst their staff effectively. AFS was more scalable than NFS because read-write operations happened locally before they were committed to the server (data store). As such the largest file size that AFS could deal with was the size of its local disk cache. <br /> <br /> AFS open-close operations were more time-consuming, while for NFS its read-write operations were more time consuming.<br /> <br /> = Amoeba Operating System =<br /> <br /> === Capablities: ===<br /> * Pointer to the object<br /> * Capability assigning right to perform to some operation to the object ticket <br /> * Communicate wide area network <br /> * a kind of ticket or key that allows the holder of the capa- bility to perform some (not neces- sarily all) <br /> * Each user process owns some collection of capabilities, which together define the set of objects it may access and the types of operations that my ne performed on each <br /> * After the server has performed the operation, it sends back a reply message that unblocks the client <br /> * Sending messages, blocking and accepting forms the remote procedure call that can be encapsulate using to make entire remote operation look like local procedure <br /> * Second field: used by the sever to identify which of its objects is being addressed server port and object number identify object which operation to performed <br /> * Generates 48-bit random number <br /> * The third field is the right field which contains a bit map telling which operation the holder of the capability may performed<br /> * X11 Window management<br /> <br /> === Thread Management: ===<br /> * Same process have multiple thread and each process has its own registered counter and stack <br /> * Behave like process<br /> * It can synchronized using mutex semaphore <br /> * File: Multiple thread, <br /> * Blocked when there's multiple threads <br /> * Buttlet thread the mutex<br /> * The careful reader may have noticed that user process can pull 813kbytes/sec<br /> <br /> <br /> = The V Distributed System = <br /> <br /> * First tent in V design: High Performance communication is the most critical facility for distributed systems.<br /> * Second; The protocols, not the software, define the system.<br /> * Third; a relatively small operating system kernel can implement the basic protocols and services providing a simple network-transparent process, address space &amp; communication model.<br /> <br /> === Ideas that significantly affected the design ===<br /> * Shared Memory.<br /> * Dealing with group of entities same as they deal w/individual entities.<br /> * Efficient file caching mechanism using the virtual memory caching mechanism.<br /> <br /> === Design Decisions ===<br /> * Designed for a cluster of workstations with high speed network access ( only really supports LAN ).<br /> * Abstract the physical architecture of the participating workstations, by defining common protocols providing well-defined interfaces.<br /> <br /> V was run on LAN, and its developers developed a really fast IPC protocol which allowed for it to be a fasted distributed operating system in a small geographic area. Aside from the IPC protocols, V also implemented RPC calls in the background.<br /> <br /> V uses the strong consistency model. This model can cause issues with concurrency because in V files are a memory space. Thus two different users accessing the same file and in fact accessing the same memory location. This could result in issues unless there is an effective implementation to deal with multiple versions, etc.</div>

Ameti073 https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_3&diff=19801 2015-02-05T03:56:29Z

<p>Ameti073: /* Locus */</p> <hr /> <div>= '''Reading Response Discussion''' =<br /> <br /> == Multics ==<br /> <br /> '''Team:''' Sameer, Shivjot, Ambalica, Veena<br /> <br /> 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.<br /> Multics is a time sharing OS which provides Multitasking and Multiprogramming. It is not a Distributed OS but it a Centralized system which was written in the assembly language.<br /> <br /> It provides following features:<br /> # Utility Computing<br /> # Access Control Lists<br /> # Single level storage<br /> # Dynamic linking<br /> #* Sharded libraries or files can be loaded and linked to Random Access Memory at run time. <br /> # Hot swapping<br /> # Multiprocessing System<br /> # Ring oriented Security<br /> #* It provides number of levels of authorization within the computer System.<br /> <br /> == Unix ==<br /> <br /> Unix in its original conception is a small, minimal API system designed by two guys from Bell Labs. It was essentially a OS that would be easy to grasp for an programmer but not much beyond that. The UNIX OS ran on one computer, and terminals ran from that one computer. Thus it is not a distributed operating system as it is centralized and implements time sharing.<br /> <br /> == Sun NFS ==<br /> <br /> The Sun NFS OS implemented networking using RPC connections. These connections are not secure. Sun wanted to encrypt these RPC connections but encryption would result in government regulations that Sun wanted to avoid in order to sell NFS over seas (See below).<br /> <br /> Sun wanted to encrypt their NFS system but decided not to. In the US encryption is regulated like munitions. Thus when Sun wanted to sell the NFS <br /> system abroad they would have to contend with government regulations. To avoid these regulations, Sun decided to sell the unencrypted NFS system abroad.<br /> <br /> '''Team: Mert<br /> <br /> '''== Locus ==<br /> <br /> # Not scalable (They did not bother themselves about scalability. Locus ran only in five computers.)<br /> #* Every computer stores a copy of every file<br /> #* Also used CAS to manage files<br /> # Not efficient with abstractions<br /> #* Trying to distribute files and processes<br /> #Allowed for process migration<br /> #Transparency<br /> #* It provided network transparency to “disguise” its distributed context.<br /> #Dynamic reconfiguration. (It adapts topology changes.)<br /> <br /> <br /> Locus has lots of similarities with the today's systems. It uses replication and partitioning which are employed in cloud and distributed systems.<br /> <br /> == Sprite ==<br /> <br /> ''' Team: ''' Jamie, Hassan, Khaled<br /> <br /> Sprite had the following Design Features:<br /> # Network Transparency<br /> # Process Migration, file transfer between computers<br /> #* User could initiate a process migration to an idle machine, and if the machine was no longer idle; due to it being used be another user, the system would take care of the process migration to another machine<br /> # Handling Cache Consistency<br /> #* Sequential file sharing ==&gt; By using a version number for each file<br /> #* Concurrent write sharing ==&gt; Disable cache to clients, enable write-blocking and other methods<br /> # Implemented a caching system that sped up performance<br /> # Implemented a log structured file system<br /> #* Log structured file systems are optimized for writes; data is written to cache instead of memory, over reads. This is a way of minimizing the performance issues of doing writes<br /> #* Example: SSD (Solid-state disks)<br /> <br /> The ''' main features ''' to take away from the Sprite system is that it implemented a log structured file system, and implemented caching to increase performanace.</div>

Ameti073 https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_3&diff=19800 2015-02-05T03:54:40Z

<p>Ameti073: /* Locus */</p> <hr /> <div>= '''Reading Response Discussion''' =<br /> <br /> == Multics ==<br /> <br /> '''Team:''' Sameer, Shivjot, Ambalica, Veena<br /> <br /> 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.<br /> Multics is a time sharing OS which provides Multitasking and Multiprogramming. It is not a Distributed OS but it a Centralized system which was written in the assembly language.<br /> <br /> It provides following features:<br /> # Utility Computing<br /> # Access Control Lists<br /> # Single level storage<br /> # Dynamic linking<br /> #* Sharded libraries or files can be loaded and linked to Random Access Memory at run time. <br /> # Hot swapping<br /> # Multiprocessing System<br /> # Ring oriented Security<br /> #* It provides number of levels of authorization within the computer System.<br /> <br /> == Unix ==<br /> <br /> Unix in its original conception is a small, minimal API system designed by two guys from Bell Labs. It was essentially a OS that would be easy to grasp for an programmer but not much beyond that. The UNIX OS ran on one computer, and terminals ran from that one computer. Thus it is not a distributed operating system as it is centralized and implements time sharing.<br /> <br /> == Sun NFS ==<br /> <br /> The Sun NFS OS implemented networking using RPC connections. These connections are not secure. Sun wanted to encrypt these RPC connections but encryption would result in government regulations that Sun wanted to avoid in order to sell NFS over seas (See below).<br /> <br /> Sun wanted to encrypt their NFS system but decided not to. In the US encryption is regulated like munitions. Thus when Sun wanted to sell the NFS <br /> system abroad they would have to contend with government regulations. To avoid these regulations, Sun decided to sell the unencrypted NFS system abroad.<br /> <br /> == Locus ==<br /> <br /> # Not scalable (They did not bother themselves about scalability. Locus ran only in five computers.)<br /> #* Every computer stores a copy of every file<br /> #* Also used CAS to manage files<br /> # Not efficient with abstractions<br /> #* Trying to distribute files and processes<br /> #Allowed for process migration<br /> #Transparency<br /> #* It provided network transparency to “disguise” its distributed context.<br /> #Dynamic reconfiguration. (It adapts topology changes.)<br /> <br /> <br /> Locus has lots of similarities with the today's systems. It uses replication and partitioning which are employed in cloud and distributed systems.<br /> <br /> == Sprite ==<br /> <br /> ''' Team: ''' Jamie, Hassan, Khaled<br /> <br /> Sprite had the following Design Features:<br /> # Network Transparency<br /> # Process Migration, file transfer between computers<br /> #* User could initiate a process migration to an idle machine, and if the machine was no longer idle; due to it being used be another user, the system would take care of the process migration to another machine<br /> # Handling Cache Consistency<br /> #* Sequential file sharing ==&gt; By using a version number for each file<br /> #* Concurrent write sharing ==&gt; Disable cache to clients, enable write-blocking and other methods<br /> # Implemented a caching system that sped up performance<br /> # Implemented a log structured file system<br /> #* Log structured file systems are optimized for writes; data is written to cache instead of memory, over reads. This is a way of minimizing the performance issues of doing writes<br /> #* Example: SSD (Solid-state disks)<br /> <br /> The ''' main features ''' to take away from the Sprite system is that it implemented a log structured file system, and implemented caching to increase performanace.</div>

Ameti073 https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_3&diff=19799 2015-02-05T03:53:01Z

<p>Ameti073: /* Locus */</p> <hr /> <div>= '''Reading Response Discussion''' =<br /> <br /> == Multics ==<br /> <br /> '''Team:''' Sameer, Shivjot, Ambalica, Veena<br /> <br /> 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.<br /> Multics is a time sharing OS which provides Multitasking and Multiprogramming. It is not a Distributed OS but it a Centralized system which was written in the assembly language.<br /> <br /> It provides following features:<br /> # Utility Computing<br /> # Access Control Lists<br /> # Single level storage<br /> # Dynamic linking<br /> #* Sharded libraries or files can be loaded and linked to Random Access Memory at run time. <br /> # Hot swapping<br /> # Multiprocessing System<br /> # Ring oriented Security<br /> #* It provides number of levels of authorization within the computer System.<br /> <br /> == Unix ==<br /> <br /> Unix in its original conception is a small, minimal API system designed by two guys from Bell Labs. It was essentially a OS that would be easy to grasp for an programmer but not much beyond that. The UNIX OS ran on one computer, and terminals ran from that one computer. Thus it is not a distributed operating system as it is centralized and implements time sharing.<br /> <br /> == Sun NFS ==<br /> <br /> The Sun NFS OS implemented networking using RPC connections. These connections are not secure. Sun wanted to encrypt these RPC connections but encryption would result in government regulations that Sun wanted to avoid in order to sell NFS over seas (See below).<br /> <br /> Sun wanted to encrypt their NFS system but decided not to. In the US encryption is regulated like munitions. Thus when Sun wanted to sell the NFS <br /> system abroad they would have to contend with government regulations. To avoid these regulations, Sun decided to sell the unencrypted NFS system abroad.<br /> <br /> == Locus ==<br /> <br /> # Not scalable (They did not bother themselves about scalability. Locus ran only in five computers.)<br /> #* Every computer stores a copy of every file<br /> #* Also used CAS to manage files<br /> # Not efficient with abstractions<br /> #* Trying to distribute files and processes<br /> #Allowed for process migration<br /> #Transparency<br /> #* It provided network transparency to “disguise” its distributed context.<br /> <br /> <br /> Locus has lots of similarities with the today's systems. It uses replication and partitioning which are employed in cloud and distributed systems.<br /> <br /> == Sprite ==<br /> <br /> ''' Team: ''' Jamie, Hassan, Khaled<br /> <br /> Sprite had the following Design Features:<br /> # Network Transparency<br /> # Process Migration, file transfer between computers<br /> #* User could initiate a process migration to an idle machine, and if the machine was no longer idle; due to it being used be another user, the system would take care of the process migration to another machine<br /> # Handling Cache Consistency<br /> #* Sequential file sharing ==&gt; By using a version number for each file<br /> #* Concurrent write sharing ==&gt; Disable cache to clients, enable write-blocking and other methods<br /> # Implemented a caching system that sped up performance<br /> # Implemented a log structured file system<br /> #* Log structured file systems are optimized for writes; data is written to cache instead of memory, over reads. This is a way of minimizing the performance issues of doing writes<br /> #* Example: SSD (Solid-state disks)<br /> <br /> The ''' main features ''' to take away from the Sprite system is that it implemented a log structured file system, and implemented caching to increase performanace.</div>

Ameti073 https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_3&diff=19798 2015-02-05T03:49:59Z

<p>Ameti073: /* Locus */</p> <hr /> <div>= '''Reading Response Discussion''' =<br /> <br /> == Multics ==<br /> <br /> '''Team:''' Sameer, Shivjot, Ambalica, Veena<br /> <br /> 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.<br /> Multics is a time sharing OS which provides Multitasking and Multiprogramming. It is not a Distributed OS but it a Centralized system which was written in the assembly language.<br /> <br /> It provides following features:<br /> # Utility Computing<br /> # Access Control Lists<br /> # Single level storage<br /> # Dynamic linking<br /> #* Sharded libraries or files can be loaded and linked to Random Access Memory at run time. <br /> # Hot swapping<br /> # Multiprocessing System<br /> # Ring oriented Security<br /> #* It provides number of levels of authorization within the computer System.<br /> <br /> == Unix ==<br /> <br /> Unix in its original conception is a small, minimal API system designed by two guys from Bell Labs. It was essentially a OS that would be easy to grasp for an programmer but not much beyond that. The UNIX OS ran on one computer, and terminals ran from that one computer. Thus it is not a distributed operating system as it is centralized and implements time sharing.<br /> <br /> == Sun NFS ==<br /> <br /> The Sun NFS OS implemented networking using RPC connections. These connections are not secure. Sun wanted to encrypt these RPC connections but encryption would result in government regulations that Sun wanted to avoid in order to sell NFS over seas (See below).<br /> <br /> Sun wanted to encrypt their NFS system but decided not to. In the US encryption is regulated like munitions. Thus when Sun wanted to sell the NFS <br /> system abroad they would have to contend with government regulations. To avoid these regulations, Sun decided to sell the unencrypted NFS system abroad.<br /> <br /> == Locus ==<br /> <br /> # Not scalable (They did not bother themselves about scalability. Locus ran only in five computers.)<br /> #* Every computer stores a copy of every file<br /> #* Also used CAS to manage files<br /> # Not efficient with abstractions<br /> #* Trying to distribute files and processes<br /> #Allowed for process migration<br /> #Transparency<br /> #* It provided network transparency to “disguise” its distributed context.<br /> <br /> == Sprite ==<br /> <br /> ''' Team: ''' Jamie, Hassan, Khaled<br /> <br /> Sprite had the following Design Features:<br /> # Network Transparency<br /> # Process Migration, file transfer between computers<br /> #* User could initiate a process migration to an idle machine, and if the machine was no longer idle; due to it being used be another user, the system would take care of the process migration to another machine<br /> # Handling Cache Consistency<br /> #* Sequential file sharing ==&gt; By using a version number for each file<br /> #* Concurrent write sharing ==&gt; Disable cache to clients, enable write-blocking and other methods<br /> # Implemented a caching system that sped up performance<br /> # Implemented a log structured file system<br /> #* Log structured file systems are optimized for writes; data is written to cache instead of memory, over reads. This is a way of minimizing the performance issues of doing writes<br /> #* Example: SSD (Solid-state disks)<br /> <br /> The ''' main features ''' to take away from the Sprite system is that it implemented a log structured file system, and implemented caching to increase performanace.</div>

Ameti073 https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_3&diff=19797 2015-02-05T03:49:22Z

<p>Ameti073: /* Locus */</p> <hr /> <div>= '''Reading Response Discussion''' =<br /> <br /> == Multics ==<br /> <br /> '''Team:''' Sameer, Shivjot, Ambalica, Veena<br /> <br /> 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.<br /> Multics is a time sharing OS which provides Multitasking and Multiprogramming. It is not a Distributed OS but it a Centralized system which was written in the assembly language.<br /> <br /> It provides following features:<br /> # Utility Computing<br /> # Access Control Lists<br /> # Single level storage<br /> # Dynamic linking<br /> #* Sharded libraries or files can be loaded and linked to Random Access Memory at run time. <br /> # Hot swapping<br /> # Multiprocessing System<br /> # Ring oriented Security<br /> #* It provides number of levels of authorization within the computer System.<br /> <br /> == Unix ==<br /> <br /> Unix in its original conception is a small, minimal API system designed by two guys from Bell Labs. It was essentially a OS that would be easy to grasp for an programmer but not much beyond that. The UNIX OS ran on one computer, and terminals ran from that one computer. Thus it is not a distributed operating system as it is centralized and implements time sharing.<br /> <br /> == Sun NFS ==<br /> <br /> The Sun NFS OS implemented networking using RPC connections. These connections are not secure. Sun wanted to encrypt these RPC connections but encryption would result in government regulations that Sun wanted to avoid in order to sell NFS over seas (See below).<br /> <br /> Sun wanted to encrypt their NFS system but decided not to. In the US encryption is regulated like munitions. Thus when Sun wanted to sell the NFS <br /> system abroad they would have to contend with government regulations. To avoid these regulations, Sun decided to sell the unencrypted NFS system abroad.<br /> <br /> == Locus ==<br /> <br /> # Not scalable (They did not bother themselves about scalability. Locus ran only in five computers.)<br /> #* Every computer stores a copy of every file<br /> #* Also used CAS to manage files<br /> # Not efficient with abstractions<br /> #* Trying to distribute files and processes<br /> #Allowed for process migration<br /> #* It provided network transparency to “disguise” its distributed context.<br /> <br /> == Sprite ==<br /> <br /> ''' Team: ''' Jamie, Hassan, Khaled<br /> <br /> Sprite had the following Design Features:<br /> # Network Transparency<br /> # Process Migration, file transfer between computers<br /> #* User could initiate a process migration to an idle machine, and if the machine was no longer idle; due to it being used be another user, the system would take care of the process migration to another machine<br /> # Handling Cache Consistency<br /> #* Sequential file sharing ==&gt; By using a version number for each file<br /> #* Concurrent write sharing ==&gt; Disable cache to clients, enable write-blocking and other methods<br /> # Implemented a caching system that sped up performance<br /> # Implemented a log structured file system<br /> #* Log structured file systems are optimized for writes; data is written to cache instead of memory, over reads. This is a way of minimizing the performance issues of doing writes<br /> #* Example: SSD (Solid-state disks)<br /> <br /> The ''' main features ''' to take away from the Sprite system is that it implemented a log structured file system, and implemented caching to increase performanace.</div>

Ameti073 https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2015W_Session_3&diff=19796 2015-02-05T03:46:52Z

<p>Ameti073: /* Locus */</p> <hr /> <div>= '''Reading Response Discussion''' =<br /> <br /> == Multics ==<br /> <br /> '''Team:''' Sameer, Shivjot, Ambalica, Veena<br /> <br /> 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.<br /> Multics is a time sharing OS which provides Multitasking and Multiprogramming. It is not a Distributed OS but it a Centralized system which was written in the assembly language.<br /> <br /> It provides following features:<br /> # Utility Computing<br /> # Access Control Lists<br /> # Single level storage<br /> # Dynamic linking<br /> #* Sharded libraries or files can be loaded and linked to Random Access Memory at run time. <br /> # Hot swapping<br /> # Multiprocessing System<br /> # Ring oriented Security<br /> #* It provides number of levels of authorization within the computer System.<br /> <br /> == Unix ==<br /> <br /> Unix in its original conception is a small, minimal API system designed by two guys from Bell Labs. It was essentially a OS that would be easy to grasp for an programmer but not much beyond that. The UNIX OS ran on one computer, and terminals ran from that one computer. Thus it is not a distributed operating system as it is centralized and implements time sharing.<br /> <br /> == Sun NFS ==<br /> <br /> The Sun NFS OS implemented networking using RPC connections. These connections are not secure. Sun wanted to encrypt these RPC connections but encryption would result in government regulations that Sun wanted to avoid in order to sell NFS over seas (See below).<br /> <br /> Sun wanted to encrypt their NFS system but decided not to. In the US encryption is regulated like munitions. Thus when Sun wanted to sell the NFS <br /> system abroad they would have to contend with government regulations. To avoid these regulations, Sun decided to sell the unencrypted NFS system abroad.<br /> <br /> == Locus ==<br /> <br /> # Not scalable (They did not bother themselves about scalability. Locus ran only in five computers.)<br /> #* Every computer stores a copy of every file<br /> #* Also used CAS to manage files<br /> # Not efficient with abstractions<br /> #* Trying to distribute files and processes<br /> #Allowed for process migration<br /> <br /> == Sprite ==<br /> <br /> ''' Team: ''' Jamie, Hassan, Khaled<br /> <br /> Sprite had the following Design Features:<br /> # Network Transparency<br /> # Process Migration, file transfer between computers<br /> #* User could initiate a process migration to an idle machine, and if the machine was no longer idle; due to it being used be another user, the system would take care of the process migration to another machine<br /> # Handling Cache Consistency<br /> #* Sequential file sharing ==&gt; By using a version number for each file<br /> #* Concurrent write sharing ==&gt; Disable cache to clients, enable write-blocking and other methods<br /> # Implemented a caching system that sped up performance<br /> # Implemented a log structured file system<br /> #* Log structured file systems are optimized for writes; data is written to cache instead of memory, over reads. This is a way of minimizing the performance issues of doing writes<br /> #* Example: SSD (Solid-state disks)<br /> <br /> The ''' main features ''' to take away from the Sprite system is that it implemented a log structured file system, and implemented caching to increase performanace.</div>

Ameti073