CLICK HERE TO DOWNLOAD PPT ON The Locus Distributed Operating System
The Locus Distributed Operating System Presentation Transcript
1.The Locus Distributed Operating System
2.The LOCUS distributed OS
UCLA project 1979-1983 (50 man years)
Superset of Unix services
Adds replication and transactions
Provides:
Transparent access to data through network wide file system (uniform name space).
Automatic replication of storage.
Distributed process execution
Recovery from failures
Performance exceeds Unix, more complex
UCLA project 1979-1983 (50 man years)
Superset of Unix services
Adds replication and transactions
Provides:
Transparent access to data through network wide file system (uniform name space).
Automatic replication of storage.
Distributed process execution
Recovery from failures
Performance exceeds Unix, more complex
3.Distributed File system.
Single tree hierarchy
All objects on all machines (uniform name space)
File groups (= Unix filesystem) glued together by mount
File Replication
File: unique inode within file group, replicas have the same inode no.
LOCUS keeps copies up to date and serves most recent ones
High Performance and Failure Management
4.Advantages of File Replication
User Point of View
Availability, reliability
Multiple copies of data resources provide more availability
Decreasing the availability the increasing the replicas
Performance
Increase the speed of data accessing
As compare to Slow Network It’s a Big advantage.
Single tree hierarchy
All objects on all machines (uniform name space)
File groups (= Unix filesystem) glued together by mount
File Replication
File: unique inode within file group, replicas have the same inode no.
LOCUS keeps copies up to date and serves most recent ones
High Performance and Failure Management
4.Advantages of File Replication
User Point of View
Availability, reliability
Multiple copies of data resources provide more availability
Decreasing the availability the increasing the replicas
Performance
Increase the speed of data accessing
As compare to Slow Network It’s a Big advantage.
5.Advantages of File Replication(2)
System View
Balance between availability and performance
Granularity of entire directory in contrast to single entry
High level of File System tree more read access and more replication increases the availability and performance
Drawback
Concurrency control increases the performance cost
6.Mechanism for File Replication
Having physical containers for logical file groups
Stores only subset of the files in the subtree to which it corresponds
Each copy has a version vector associated with it that maintains necessary history information
System View
Balance between availability and performance
Granularity of entire directory in contrast to single entry
High level of File System tree more read access and more replication increases the availability and performance
Drawback
Concurrency control increases the performance cost
6.Mechanism for File Replication
Having physical containers for logical file groups
Stores only subset of the files in the subtree to which it corresponds
Each copy has a version vector associated with it that maintains necessary history information
7.File access
There are three logical sites
US – User site --which issues the request to open a file and to which pages of the file are to be supplied
SS – Storage Site-- which is the site at which copy of the requested file is stored, and which has been selected to supply pages of that file to the using site
CSS- Current Synchronization Site– Which enforces a global access synchronization policy for the file's filegroup and selects SSs for each open request.
8.Strategy for Distributed Operation
There are three logical sites
US – User site --which issues the request to open a file and to which pages of the file are to be supplied
SS – Storage Site-- which is the site at which copy of the requested file is stored, and which has been selected to supply pages of that file to the using site
CSS- Current Synchronization Site– Which enforces a global access synchronization policy for the file's filegroup and selects SSs for each open request.
8.Strategy for Distributed Operation
9. Reading the Files
Open System Call with file parameter and flags indicating that operation is read
Path name searching
Then CSS is interrogated, if local site is CSS only procedure call is needed
Otherwise CSS is determined by mount table and a message is sent to CSS
Why CSS is involved?
for Synchronization control and to find storage site
Open System Call with file parameter and flags indicating that operation is read
Path name searching
Then CSS is interrogated, if local site is CSS only procedure call is needed
Otherwise CSS is determined by mount table and a message is sent to CSS
Why CSS is involved?
for Synchronization control and to find storage site
10.Open Protocol
11.Reading files contd..
After the file is open, user level process issues read procedure call
All such requests is serviced via kernel buffers both in UNIX and Locus
For local site data is paged from external storage into system buffers and then translated into process space
For remote site system at US allocates a buffer and queues request to be sent over the network to SS.
US - > SS request for page z of file y
SS - > US response to the above request
12. Path Name Searching
All pathnames presented to the operating system start from one of two places, either the root (/) the current working directory of the process presenting the pathname
To commence the pathname searching, the <logical filegroup, inode number> of the starting directory is extracted from the appropriate inode and an internal open is done on it
If the directory is stored locally, the local directory is searched without informing the CSS. If the directory is not local, the protocol involving the CSS must be used
13.File Modification
Opening a file for modification is same as opening for read. The synchronization check at the CSS is different and the state information kept at all three logical sites is slightly different
If the modification does not include the entire page, the old page is read from the SS using the read protocol. If the change involves an entire page, a buffer is set up at the US without any reads
In both cases changes are made at SS by write protocol
14.File Creation and Deletion
Due to the potential for replicated storage of a new file, the create call needs two additional pieces of information - how many copies to store and where to store them
The create is done at one storage site and propagated to the other storage sites. If the storage site of the created file is not Local, the protocol for the create is very similar to the remote open protocol, the difference being that a placeholder is sent instead of an inode number. The storage site allocates an inode number from a pool which is local to that physical container of the filegroup.
File delete uses much of the same mechanism normal file update.
After the file is open, user level process issues read procedure call
All such requests is serviced via kernel buffers both in UNIX and Locus
For local site data is paged from external storage into system buffers and then translated into process space
For remote site system at US allocates a buffer and queues request to be sent over the network to SS.
US - > SS request for page z of file y
SS - > US response to the above request
12. Path Name Searching
All pathnames presented to the operating system start from one of two places, either the root (/) the current working directory of the process presenting the pathname
To commence the pathname searching, the <logical filegroup, inode number> of the starting directory is extracted from the appropriate inode and an internal open is done on it
If the directory is stored locally, the local directory is searched without informing the CSS. If the directory is not local, the protocol involving the CSS must be used
13.File Modification
Opening a file for modification is same as opening for read. The synchronization check at the CSS is different and the state information kept at all three logical sites is slightly different
If the modification does not include the entire page, the old page is read from the SS using the read protocol. If the change involves an entire page, a buffer is set up at the US without any reads
In both cases changes are made at SS by write protocol
14.File Creation and Deletion
Due to the potential for replicated storage of a new file, the create call needs two additional pieces of information - how many copies to store and where to store them
The create is done at one storage site and propagated to the other storage sites. If the storage site of the created file is not Local, the protocol for the create is very similar to the remote open protocol, the difference being that a placeholder is sent instead of an inode number. The storage site allocates an inode number from a pool which is local to that physical container of the filegroup.
File delete uses much of the same mechanism normal file update.
15.Remote Process Creation and Handling
Requirements for Transparency
Able to create a process on remote machine
Able to initialize it properly
Support cross machine and inter process functions as on a single machine
Requirements for Transparency
Able to create a process on remote machine
Able to initialize it properly
Support cross machine and inter process functions as on a single machine
16. Inter Process Functions
Explicit Functions are signals and pipes provided by UNIX
Shared open files is another Implicit mechanism in contrast to explicit functions but causes more conflicts
Both of these techniques are implemented in LOCUS with a token mechanism which marks which copy of a resource is valid.
To access a resource you need a token
Explicit Functions are signals and pipes provided by UNIX
Shared open files is another Implicit mechanism in contrast to explicit functions but causes more conflicts
Both of these techniques are implemented in LOCUS with a token mechanism which marks which copy of a resource is valid.
To access a resource you need a token
17. Error Handling
LOCUS tries to fold most of the process errors in UNIX interface
Rest of the errors are due to either failing of parent process machine or child process machine
In case of a child machine failure, error is reported to parent process and it generates a new call
In case of a parent machine failure, error is reported to child process and it aborts itself
LOCUS tries to fold most of the process errors in UNIX interface
Rest of the errors are due to either failing of parent process machine or child process machine
In case of a child machine failure, error is reported to parent process and it generates a new call
In case of a parent machine failure, error is reported to child process and it aborts itself
18.LOCUS Recovery Philosophy
The basic goal is to maintain strict synchronization among the copies of files in a single partition
Upon merges conflicts and inconsistencies are effectively detected
For simple data types automatic reconciliation is provided by LOCUS otherwise reported to higher level e.g.. DataBase manager or the user itself
The basic goal is to maintain strict synchronization among the copies of files in a single partition
Upon merges conflicts and inconsistencies are effectively detected
For simple data types automatic reconciliation is provided by LOCUS otherwise reported to higher level e.g.. DataBase manager or the user itself
19.Partitions
Conflicts can be avoided by strong connectivity between nodes but that is not always possible so handling the situation of partitions is necessary
Update must be allowed during partitions for greater availability and reliability (Rise conflicts)
The merge procedure must assure that no updates are lost when different copies are merged
Transaction techniques of Database systems are also used in case updates are dependant
Conflicts can be avoided by strong connectivity between nodes but that is not always possible so handling the situation of partitions is necessary
Update must be allowed during partitions for greater availability and reliability (Rise conflicts)
The merge procedure must assure that no updates are lost when different copies are merged
Transaction techniques of Database systems are also used in case updates are dependant
20.Detection of conflicting updates
21.File f replicated at node S1 and S2 before partition
22.File System merge
Merging is a recovery process
Recovery software takes the type of as a key information to take appropriate action
Current file types are
Directory files
Mailboxes (of several kinds)
Database files
Untyped files
Merging is a recovery process
Recovery software takes the type of as a key information to take appropriate action
Current file types are
Directory files
Mailboxes (of several kinds)
Database files
Untyped files
23.Reconciliation of Directory files
A directory is a set of records and each record can be defined as character string which comprises an element in the pathname of a file.
Operations on directory files:-
Insert( character string path element )
Delete( character string path element )
A directory is a set of records and each record can be defined as character string which comprises an element in the pathname of a file.
Operations on directory files:-
Insert( character string path element )
Delete( character string path element )
24. Rules for reconciliation
Check for name conflicts, for each name in the union of directories, check that inode numbers are same, if they aren’t both the file have been slightly altered to be distinguished. The owners of two files are informed by electronic mail about the action.
Rest of the reconciliation is performed on inode by inode basis with following rules
If the entry is on one and not on other than propagate it
If there is a deletion entry on one and on other the file is not modified than propagate deletion
If both have entry and neither is deleted, no action
Else a conflict has occurred and it is reported to the owner
Check for name conflicts, for each name in the union of directories, check that inode numbers are same, if they aren’t both the file have been slightly altered to be distinguished. The owners of two files are informed by electronic mail about the action.
Rest of the reconciliation is performed on inode by inode basis with following rules
If the entry is on one and not on other than propagate it
If there is a deletion entry on one and on other the file is not modified than propagate deletion
If both have entry and neither is deleted, no action
Else a conflict has occurred and it is reported to the owner
25.Dynamic reconfiguration'
Transparency must be applied not only to static topologies but also to the configuration changes
The system must insulate user from dynamic reconfiguration, providing the continuation of processes with negligible delays
User programs deals with reconfiguration so the network cost shift from Operating System to user programs
Transparency must be applied not only to static topologies but also to the configuration changes
The system must insulate user from dynamic reconfiguration, providing the continuation of processes with negligible delays
User programs deals with reconfiguration so the network cost shift from Operating System to user programs
26.Requirements of reconfiguration protocols
It should maintain consistency with respect to internal system architecture
The solution must insulate user from the underlying system changes
Solution should not affect program development and should be efficient enough that any delays it imposes are negligible
It should maintain consistency with respect to internal system architecture
The solution must insulate user from the underlying system changes
Solution should not affect program development and should be efficient enough that any delays it imposes are negligible
27.Protocol Structures
LOCUS assumes the network to be fully connected
So the reconfiguration strategy is divided into two stages
A partition protocol
A merge protocol
All reconfiguration protocols are controlled by a high level kernel process. Both the protocols are run directly by that process
LOCUS assumes the network to be fully connected
So the reconfiguration strategy is divided into two stages
A partition protocol
A merge protocol
All reconfiguration protocols are controlled by a high level kernel process. Both the protocols are run directly by that process
28.The Partition Protocol
Partitions are represented as equivalence classes
of sites and reflected by site tables
Whenever a communication breaks, these tables becomes unsynchronized
The partition code must re-establish these tables
Any communication failure does not imply failure of any of the site, it may due to transmission noise or unforeseen delay
Partitions are represented as equivalence classes
of sites and reflected by site tables
Whenever a communication breaks, these tables becomes unsynchronized
The partition code must re-establish these tables
Any communication failure does not imply failure of any of the site, it may due to transmission noise or unforeseen delay
29.The Merge Protocol
The merge protocol joins several partitions into one
It establishes new site tables and mount tables and re-establishes CSS (Current Synchronization site)
The protocol tries to make the partition as large as possible by polling all the sites, those were previously down
It uses asynchronous polling instead of linear to avoid unwanted timeouts and retransmissions
The merge protocol joins several partitions into one
It establishes new site tables and mount tables and re-establishes CSS (Current Synchronization site)
The protocol tries to make the partition as large as possible by polling all the sites, those were previously down
It uses asynchronous polling instead of linear to avoid unwanted timeouts and retransmissions
0 comments