DistOS 2014W Lecture 8: Difference between revisions
Group 1 no longer exists |
Filled in a buncha information about NFS |
||
| Line 7: | Line 7: | ||
Group 1: | Group 1: | ||
1) per | 1) per operation traffic. | ||
2) rpc based | 2) rpc based. Easy with which to program but a very [http://www.joelonsoftware.com/articles/LeakyAbstractions.html leaky abstraction]. | ||
3) unreliable | 3) unreliable | ||
| Line 17: | Line 17: | ||
1) designed to share disks over a network, not files | 1) designed to share disks over a network, not files | ||
2) more UNIX like | 2) more UNIX like. They tried to maintain unix file semantics on the client and server side. | ||
3) portable | 3) portable. It was meant to work (as a server) across many FS types. | ||
4) | 4) used UDP: if request dropped, just request again. | ||
5) it is not minimize network traffic. | 5) it is not minimize network traffic. | ||
6) used VNODE | 6) used VNODE, VFS as transparent interfaces to local disks. | ||
7) not have much hardware equipment | 7) not have much hardware equipment | ||
| Line 31: | Line 31: | ||
8) later versions took on features of AFS | 8) later versions took on features of AFS | ||
9) stateless protocol conflicts with files being | 9) stateless protocol conflicts with files being stateful by nature. | ||
Group 3: | Group 3: | ||
| Line 37: | Line 37: | ||
1) cache assumption invalid. | 1) cache assumption invalid. | ||
2) no locking | 2) no dedicated locking mechanism. They couldn't decide on which locking strategy to use, so they left it up to the users of NFS to use their own separate locking service. | ||
3) bad security | 3) bad security | ||
==AFS== | ==AFS== | ||
Revision as of 23:40, 23 February 2014
NFS and AFS (Jan 30)
- Russel Sandberg et al., "Design and Implementation of the Sun Network Filesystem" (1985)
- John H. Howard et al., "Scale and Performance in a Distributed File System" (1988)
NFS
Group 1:
1) per operation traffic.
2) rpc based. Easy with which to program but a very leaky abstraction.
3) unreliable
Group 2:
1) designed to share disks over a network, not files
2) more UNIX like. They tried to maintain unix file semantics on the client and server side.
3) portable. It was meant to work (as a server) across many FS types.
4) used UDP: if request dropped, just request again.
5) it is not minimize network traffic.
6) used VNODE, VFS as transparent interfaces to local disks.
7) not have much hardware equipment
8) later versions took on features of AFS
9) stateless protocol conflicts with files being stateful by nature.
Group 3:
1) cache assumption invalid.
2) no dedicated locking mechanism. They couldn't decide on which locking strategy to use, so they left it up to the users of NFS to use their own separate locking service.
3) bad security
AFS
Group 1
1) design for 5000 clients
2) high integrity.
Group 2
1) designed to share files over a network, not disks
2) better scalability
3) better security.
4) minimize network traffic.
5) less UNIX like
6) plugin authentication
7) needs more kernel storage due to complex commands
8) inode concept replaced with fid
Group 3
1) cache assumption valid
2) locking
3) good security.
Class Discussion:
Capturing some of Anil's Observations about NFS and AFS:
- The reason why NFS does not try to share at block level instead of file level is that sharing at block level is complicated from the implementation point of view.
- NFS use UDP as the transport protocol since UDP being a stateless protocol is in-line with the NFS design philosophy of not maintaining state information.
- Security and unreliability issues in NFS are an implication of using RPC.
- RPC is a nice way for programming but RPC is not designed for networks (where flakiness is an inherent characteristic) which is better explained by the analogy that you never expect from a programming point of view your function call to fail(not to return) because of communication error. *AFS designers considered network as a bottle neck and tried to reduce the number of chatter over network by using caching.
- 'open' and 'close' operations in AFS were critical
- the 'close' operation assumes importance to the same proportions of a 'commit' operation in a well-designed database system.
- The security model of AFS is interesting in that rather than going for the UNIX access list based implementation AFS used a single sign on system based on Kerberos.
- cool thing about Kerberos is that idea of using tickets to get access.
- Irrespective of having better features compared to NFS, AFS did not get widely adopted. The reason for this was that the administrative mechanism for AFS was complex and it required highly trained/skilled people to setup AFS and it also required quite a number of day’s effort to set it up and maintain.