DistOS 2014W Lecture 8 - Revision history

Eapache: /* Class Discussion: */

2014-04-23T17:33:56Z

Class Discussion:

← Older revision		Revision as of 17:33, 23 April 2014
Line 84:		Line 84:
	==Class Discussion:==		==Class Discussion:==

	~~Capturing some of Anil's Observations about~~ NFS and AFS:		NFS and AFS took substantially different approaches to the many problems they faced; while we consider AFS to have made generally better choices in this respect, it was not widely adopted because it was complex and difficult to setup/administer/maintain. NFS however, was comparatively simple. Its protocol and API were relatively stateless (thus it used UDP) and it shared information at the file level rather than the block level. It was also built on RPC, which was convenient to program in but was (as we have already discussed) a bad abstraction since it hid the inherent flakiness of the network. This use of RPC led to security and reliability problems with NFS.
	* 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~~.		AFS took a more thorough approach to figuring out coherent consistency guarantees and how to implement them efficiently. The AFS designers considered the network as a bottle neck and tried to reduce the amount of chatter over network by making heavy use of caching. The 'open' and 'close' operations in AFS were critical, assuming importance similar in proportion to 'commit' operations in a well-designed database system. The security model of AFS was also interesting in that rather than going for the UNIX access list based implementation AFS used a single sign on system based on Kerberos.
	* 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.

Cdelahou: /* Class Discussion: */

2014-04-22T18:58:22Z

Class Discussion:

← Older revision		Revision as of 18:58, 22 April 2014
Line 88:		Line 88:
	* 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.		* 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.		* 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.		** 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		** '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 'close' operation assumes importance to the same proportions of a 'commit' operation in a well-designed database system.

Cdelahou: More NFS details.

2014-02-23T23:48:12Z

More NFS details.

← Older revision		Revision as of 23:48, 23 February 2014
Line 40:		Line 40:

	3) bad security		3) bad security

			Other:
			* Client mounts full FS. No common namespace.
			* Hostname lookup and address binding happens at mount

	==AFS==		==AFS==

Cdelahou: Added a few details.

2014-02-23T23:44:56Z

Added a few details.

← Older revision		Revision as of 23:44, 23 February 2014
Line 45:		Line 45:
	Group 1		Group 1

	1) design for 5000 clients		1) design for 5000 to 10000 clients

	2) high integrity.		2) high integrity.
Line 51:		Line 51:
	Group 2		Group 2

	1) designed to share files over a network, not disks		1) designed to share files over a network, not disks. It is one FS.

	2) better scalability		2) better scalability

	3) better security.		3) better security (Kerberos).

	4) minimize network traffic.		4) minimize network traffic.
Line 75:		Line 75:
	3) good security.		3) good security.

			Other:
			* Caches full files locally on open. Sends diffs on close.

	==Class Discussion:==		==Class Discussion:==

Cdelahou: Filled in a buncha information about NFS

2014-02-23T23:40:06Z

Filled in a buncha information about NFS

← Older revision		Revision as of 23:40, 23 February 2014
Line 7:		Line 7:
	Group 1:		Group 1:

	1) per ~~operating~~ traffic		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) ~~use~~ UDP		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 ~~state-full~~ by nature.		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==

Cdelahou: Group 1 no longer exists

2014-02-23T23:28:27Z

Group 1 no longer exists

← Older revision		Revision as of 23:28, 23 February 2014
Line 3:		Line 3:
	* [http://homeostasis.scs.carleton.ca/~soma/distos/2008-02-11/sandberg-nfs.pdf Russel Sandberg et al., "Design and Implementation of the Sun Network Filesystem" (1985)]		* [http://homeostasis.scs.carleton.ca/~soma/distos/2008-02-11/sandberg-nfs.pdf Russel Sandberg et al., "Design and Implementation of the Sun Network Filesystem" (1985)]
	* [http://homeostasis.scs.carleton.ca/~soma/distos/2008-02-11/howard-afs.pdf John H. Howard et al., "Scale and Performance in a Distributed File System" (1988)]		* [http://homeostasis.scs.carleton.ca/~soma/distos/2008-02-11/howard-afs.pdf John H. Howard et al., "Scale and Performance in a Distributed File System" (1988)]

	~~==Group 1==~~

	==NFS==		==NFS==

Cdelahou: Combined all AFS and NFS parts together. Groups don't matter.

2014-02-23T23:28:00Z

Combined all AFS and NFS parts together. Groups don't matter.

@@ Line 6: / Line 6: @@
 ==Group 1==
-'''NFS:'''
+==NFS==
 ) per operating traffic
@@ Line 14: / Line 15: @@
 ) unreliable
-'''AFS:'''
+Group 2:
 ) designed to share disks over a network, not files
@@ Line 42: / Line 35: @@
 ) stateless protocol conflicts with files being state-full by nature.
-'''AFS:'''
+Group 3:
 ) designed to share files over a network, not disks
@@ Line 60: / Line 71: @@
 ) inode concept replaced with fid
 Group 3
 ) cache assumption valid

Cdelahou: Removed unused group 4. Formatted discussion

2014-02-23T23:24:16Z

Removed unused group 4. Formatted discussion

← Older revision		Revision as of 23:24, 23 February 2014
Line 79:		Line 79:
	3) good security.		3) good security.

	~~==Group 4==~~

			==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.
	~~Additional notes from the 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. ~~In Anil's opinion~~ 'open' and 'close' operations in AFS were critical ~~and~~ the 'close' operation assumes importance to the same proportions of a 'commit' operation in a well-designed database system. ~~Anil mentioned that~~ 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. ~~In Anil's opinion~~ cool thing about Kerberos is that idea of using tickets to get access. ~~Another interesting fact that was mentioned was that 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.		** '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.

Cdelahou: added link to paper and title

2014-02-21T21:47:03Z

added link to paper and title

← Older revision		Revision as of 21:47, 21 February 2014
Line 1:		Line 1:
			==NFS and AFS (Jan 30)==

			* [http://homeostasis.scs.carleton.ca/~soma/distos/2008-02-11/sandberg-nfs.pdf Russel Sandberg et al., "Design and Implementation of the Sun Network Filesystem" (1985)]
			* [http://homeostasis.scs.carleton.ca/~soma/distos/2008-02-11/howard-afs.pdf John H. Howard et al., "Scale and Performance in a Distributed File System" (1988)]

	==Group 1==		==Group 1==

Sjoy: formatting

2014-02-08T20:48:10Z

formatting

← Older revision		Revision as of 20:48, 8 February 2014
Line 80:		Line 80:


	~~==Additional notes from the 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. In Anil's opinion 'open' and 'close' operations in AFS were critical and the 'close' operation assumes importance to the same proportions of a 'commit' operation in a well-designed database system. Anil mentioned that 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. In Anil's opinion cool thing about Kerberos is that idea of using tickets to get access. Another interesting fact that was mentioned was that 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.		----
			Additional notes from the 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. In Anil's opinion 'open' and 'close' operations in AFS were critical and the 'close' operation assumes importance to the same proportions of a 'commit' operation in a well-designed database system. Anil mentioned that 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. In Anil's opinion cool thing about Kerberos is that idea of using tickets to get access. Another interesting fact that was mentioned was that 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.