Comparison of NFS vs. others

From Linux NFS

Revision as of 20:55, 29 July 2005 (view source) 65.172.181.6 (Talk) ← Older edit		Revision as of 15:13, 17 August 2005 (view source) 129.185.75.9 (Talk) (→better presentation ??? (not sure)) Newer edit →
Line 2:		Line 2:
	[http://forums.designtechnica.com/archive/index.php/t-5132.html]		[http://forums.designtechnica.com/archive/index.php/t-5132.html]
-	<pre>	+
-	CIFS:	+	==CIFS==
-	Strengths:	+	===Strengths===
-	a) Huge installed client base (not just Windows),	+	# Huge installed client base (not just Windows),
-	b) good, open source server implementation available (Samba!),	+	# good, open source server implementation available (Samba!),
-	c) token management (oplock) and referral ("dfs") semantics are a good	+	# token management (oplock) and referral ("dfs") semantics are a good
	compromise between usefulness and simplicity		compromise between usefulness and simplicity
-	d) the key part of the filesystem protocol (mostly) documented,	+	# the key part of the filesystem protocol (mostly) documented,
	rich file open semantics map well to Windows and related OSs,		rich file open semantics map well to Windows and related OSs,
-	e) kerberos security integration and RPC integration	+	# kerberos security integration and RPC integration
-	f) broader in scope (print, ACL, browsing etc.) than other filesystem	+	# broader in scope (print, ACL, browsing etc.) than other filesystem
	protocols		protocols
-	g) optional PDU signing above the RPC allowing maximal flexibility	+	# optional PDU signing above the RPC allowing maximal flexibility
-	h) Unicode	+	# Unicode
-	i) high performance	+	# high performance
-	j) huge amount of loosely related management/administrative function	+	# huge amount of loosely related management/administrative function
	available via various DCE RPC calls		available via various DCE RPC calls
-	k) efficient PDUs (small frame headers, less wasted bandwidth)	+	# efficient PDUs (small frame headers, less wasted bandwidth)
-	Weaknesses:	+	===Weaknesses===
-	a) the extended protocol poorly documented,	+	# the extended protocol poorly documented,
-	b) not an IETF standard	+	# not an IETF standard
-	c) elements of older protocol dialects still needed adding to	+	# elements of older protocol dialects still needed adding to
	complexity of implementations		complexity of implementations
-	d) protocol needs addition of lock migration/recovery and support for	+	# protocol needs addition of lock migration/recovery and support for
	new transport mechanisms (e.g. RDMA)		new transport mechanisms (e.g. RDMA)
-	e) ACL support - although useful is hard to understand	+	# ACL support - although useful is hard to understand
-	f) (item j above) management/admistrative calls are proprietary	+	# (item j above) management/admistrative calls are proprietary
-	NFSv3:	+	==NFSv3==
-	Strengths:	+	===Strengths===
-	a) relatively simple to implement	+	# relatively simple to implement
-	b) maps well to Unix VFS semantics (except for caching)	+	# maps well to Unix VFS semantics (except for caching)
-	c) protocol easy to understand by stripping file protocol to its	+	# protocol easy to understand by stripping file protocol to its
	minimum		minimum
-	d) Unicode	+	# Unicode
-	Weaknesses:	+	===Weaknesses===
-	a) statelessness of core protocol causes caching problems	+	# statelessness of core protocol causes caching problems
-	b) few Windows NFS clients installed	+	# few Windows NFS clients installed
-	c) maps poorly to Windows operating system API	+	# maps poorly to Windows operating system API
-	d) poor security (forcing it into lower layers if at all)	+	# poor security (forcing it into lower layers if at all)
-	e) not a standard (informational description published by Sun as	+	# not a standard (informational description published by Sun as
	informational RFC)		informational RFC)
-	f) relatively weak open source server implementation (at least	+	# relatively weak open source server implementation (at least
	compared to Samba and AFS) has scalability problems		compared to Samba and AFS) has scalability problems
-	g) implementing many protocols needed to get CIFS equivalent e.g. lock	+	# implementing many protocols needed to get CIFS equivalent e.g. lock
	manager, mount and port mapping protocol, SunRPC, NIS, ONC extensions (some		manager, mount and port mapping protocol, SunRPC, NIS, ONC extensions (some
	proprietary)		proprietary)
-	h) WebNFS enhancements partially implemented adding to some confusion	+	# WebNFS enhancements partially implemented adding to some confusion
-	NFSv4:	+	==NFSv4==
-	Strengths:	+	===Strengths===
-	a) on track to be an IETF standard	+	# on track to be an IETF standard
-	b) improved recovery (lock migration)	+	# improved recovery (lock migration)
-	c) supports Windows file sharing semantics better than NFS v3 did	+	# supports Windows file sharing semantics better than NFS v3 did
-	d) safe file caching	+	# safe file caching
-	Weaknesses:	+	===Weaknesses===
-	a) few clients	+	# few clients
-	b) perceived lack of Microsoft interest	+	# perceived lack of Microsoft interest
-	c) the existing prototype open source implementation is tricky to	+	# the existing prototype open source implementation is tricky to
	integrate into current Linux kernels		integrate into current Linux kernels
-	d) protocol is moving target (it is not quite done yet)	+	# protocol is moving target (it is not quite done yet)
-	e) too late?	+	# too late?
-	f) complex	+	# complex
-	DAFS:	+	==DAFS==
-	Strengths:	+	===Strengths===
-	a) Addition of RDMA to NFS style protocol, (probable) high performance	+	# Addition of RDMA to NFS style protocol, (probable) high performance
	in clusters and server farms.		in clusters and server farms.
-	b) (see NFS v4)	+	# (see NFS v4)
-	Weaknesses:	+	===Weaknesses===
-	a) unproven, lack of client support, perceived competition with NFS v4	+	# unproven, lack of client support, perceived competition with NFS v4
-	b) (see NFS v4)	+	# (see NFS v4)
-	HTTP/WebDAV	+	==HTTP/WebDAV==
-	Strengths:	+	===Strengths===
-	a) official standard	+	# official standard
-	b) broadly implemented	+	# broadly implemented
-	c) well suited to internet	+	# well suited to internet
-	d) active standardization work - protocol will improve	+	# active standardization work - protocol will improve
-	Weaknesses:	+	===Weaknesses===
-	a) frame headers are large (high % of frame size is wasted)	+	# frame headers are large (high % of frame size is wasted)
-	b) security integration not optimal	+	# security integration not optimal
-	c) slow	+	# slow
-	d) not a complete match to either Linux VFS or Win2K IFS API	+	# not a complete match to either Linux VFS or Win2K IFS API
	requirements		requirements
-	NCP(Netware):	+	==NCP(Netware)==
-	Strengths:	+	===Strengths===
-	a) NDS integration	+	# NDS integration
-	b) good match for Windows	+	# good match for Windows
-	c) good installed base on older systems	+	# good installed base on older systems
-	Weaknesses:	+	===Weaknesses===
-	a) Proprietary	+	# Proprietary
-	b) poorly documented	+	# poorly documented
-	c) not a standard	+	# not a standard
-	d) complex, with lots of dialects	+	# complex, with lots of dialects
-	e) future clients questionable	+	# future clients questionable
-	AFS/DFS:	+	==AFS/DFS==
-	Strengths:	+	===Strengths===
-	a) sophisticated distributed caching (token management)	+	# sophisticated distributed caching (token management)
-	b) DCE integration (including Kerberos and RPC)	+	# DCE integration (including Kerberos and RPC)
-	c) standardized by OpenGroup	+	# standardized by OpenGroup
-	Weakness:	+	===Weakness===
-	a) lack of clients	+	# lack of clients
-	b) bulky, slow Windows clients	+	# bulky, slow Windows clients
-	c) server integration with Unix operating systems and server	+	# server integration with Unix operating systems and server
	filesystem is complicated		filesystem is complicated
-	d) most implementations were expensive	+	# most implementations were expensive complex to implement
-	e) complex to implement	+
-		+
-	Coda:
-	Strengths:
-	a) disconnected support
-	Weaknesses:	+	==Coda==
-	a) Lack of commercial implementations	+	===Strengths===
-	b) lack of Windows clients	+	# disconnected support
-	c) not well understood	+
-	</pre>	+	===Weaknesses===
		+	# Lack of commercial implementations
		+	# lack of Windows clients
		+	# not well understood

---

Revision as of 15:13, 17 August 2005

Here is a description comparing NFS and other similar technologies, found at this page: [1]

Contents 1 CIFS 1.1 Strengths 1.2 Weaknesses 2 NFSv3 2.1 Strengths 2.2 Weaknesses 3 NFSv4 3.1 Strengths 3.2 Weaknesses 4 DAFS 4.1 Strengths 4.2 Weaknesses 5 HTTP/WebDAV 5.1 Strengths 5.2 Weaknesses 6 NCP(Netware) 6.1 Strengths 6.2 Weaknesses 7 AFS/DFS 7.1 Strengths 7.2 Weakness 8 Coda 8.1 Strengths 8.2 Weaknesses

CIFS

Strengths

1. Huge installed client base (not just Windows),
2. good, open source server implementation available (Samba!),
3. token management (oplock) and referral ("dfs") semantics are a good

compromise between usefulness and simplicity

1. the key part of the filesystem protocol (mostly) documented,

rich file open semantics map well to Windows and related OSs,

1. kerberos security integration and RPC integration
2. broader in scope (print, ACL, browsing etc.) than other filesystem

protocols

1. optional PDU signing above the RPC allowing maximal flexibility
2. Unicode
3. high performance
4. huge amount of loosely related management/administrative function

available via various DCE RPC calls

1. efficient PDUs (small frame headers, less wasted bandwidth)

Weaknesses

1. the extended protocol poorly documented,
2. not an IETF standard
3. elements of older protocol dialects still needed adding to

complexity of implementations

1. protocol needs addition of lock migration/recovery and support for

new transport mechanisms (e.g. RDMA)

1. ACL support - although useful is hard to understand
2. (item j above) management/admistrative calls are proprietary

NFSv3

Strengths

1. relatively simple to implement
2. maps well to Unix VFS semantics (except for caching)
3. protocol easy to understand by stripping file protocol to its

minimum

1. Unicode

Weaknesses

1. statelessness of core protocol causes caching problems
2. few Windows NFS clients installed
3. maps poorly to Windows operating system API
4. poor security (forcing it into lower layers if at all)
5. not a standard (informational description published by Sun as

informational RFC)

1. relatively weak open source server implementation (at least

compared to Samba and AFS) has scalability problems

1. implementing many protocols needed to get CIFS equivalent e.g. lock

manager, mount and port mapping protocol, SunRPC, NIS, ONC extensions (some proprietary)

1. WebNFS enhancements partially implemented adding to some confusion

NFSv4

Strengths

1. on track to be an IETF standard
2. improved recovery (lock migration)
3. supports Windows file sharing semantics better than NFS v3 did
4. safe file caching

Weaknesses

1. few clients
2. perceived lack of Microsoft interest
3. the existing prototype open source implementation is tricky to

integrate into current Linux kernels

1. protocol is moving target (it is not quite done yet)
2. too late?
3. complex

DAFS

Strengths

1. Addition of RDMA to NFS style protocol, (probable) high performance

in clusters and server farms.

1. (see NFS v4)

Weaknesses

1. unproven, lack of client support, perceived competition with NFS v4
2. (see NFS v4)

HTTP/WebDAV

Strengths

1. official standard
2. broadly implemented
3. well suited to internet
4. active standardization work - protocol will improve

Weaknesses

1. frame headers are large (high % of frame size is wasted)
2. security integration not optimal
3. slow
4. not a complete match to either Linux VFS or Win2K IFS API

requirements

NCP(Netware)

Strengths

1. NDS integration
2. good match for Windows
3. good installed base on older systems

Weaknesses

1. Proprietary
2. poorly documented
3. not a standard
4. complex, with lots of dialects
5. future clients questionable

AFS/DFS

Strengths

1. sophisticated distributed caching (token management)
2. DCE integration (including Kerberos and RPC)
3. standardized by OpenGroup

Weakness

1. lack of clients
2. bulky, slow Windows clients
3. server integration with Unix operating systems and server

filesystem is complicated

1. most implementations were expensive complex to implement

Coda

Strengths

1. disconnected support

Weaknesses

1. Lack of commercial implementations
2. lack of Windows clients
3. not well understood