Comparison of NFS vs. others

From Linux NFS

(Difference between revisions)
Jump to: navigation, search
m (acknowledge edits on top of the original e-mail)
 
(17 intermediate revisions not shown)
Line 1: Line 1:
-
Here is a description comparing NFS and other similar technologies, found at this page:
+
Here is a description comparing NFS and other similar technologies, started at this page:
-
[http://forums.designtechnica.com/archive/index.php/t-5132.html]
+
[http://lists.samba.org/archive/samba-technical/2001-December/017918.html]
-
<pre>
 
-
CIFS:
 
-
Strengths:
 
-
a) Huge installed client base (not just Windows),
 
-
b) good, open source server implementation available (Samba!),
 
-
c) token management (oplock) and referral ("dfs") semantics are a good
 
-
compromise between usefulness and simplicity
 
-
d) the key part of the filesystem protocol (mostly) documented,
 
-
rich file open semantics map well to Windows and related OSs,
 
-
e) kerberos security integration and RPC integration
 
-
f) broader in scope (print, ACL, browsing etc.) than other filesystem
 
-
protocols
 
-
g) optional PDU signing above the RPC allowing maximal flexibility
 
-
h) Unicode
 
-
i) high performance
 
-
j) huge amount of loosely related management/administrative function
 
-
available via various DCE RPC calls
 
-
k) efficient PDUs (small frame headers, less wasted bandwidth)
 
-
Weaknesses:
+
==CIFS==
-
a) the extended protocol poorly documented,
+
===Strengths===
-
b) not an IETF standard
+
# Huge installed client base (not just Windows),
-
c) elements of older protocol dialects still needed adding to
+
# good, open source server implementation available (Samba!),
-
complexity of implementations
+
# token management (oplock) and referral ("dfs") semantics are a good compromise between usefulness and simplicity
-
d) protocol needs addition of lock migration/recovery and support for
+
# the key part of the filesystem protocol (mostly) documented, rich file open semantics map well to Windows and related OSs,
-
new transport mechanisms (e.g. RDMA)
+
# kerberos security integration and RPC integration
-
e) ACL support - although useful is hard to understand
+
# broader in scope (print, ACL, browsing etc.) than other filesystem protocols
-
f) (item j above) management/admistrative calls are proprietary
+
# optional PDU signing above the RPC allowing maximal flexibility
 +
# Unicode
 +
# high performance
 +
# huge amount of loosely related management/administrative function available via various DCE RPC calls
 +
# efficient PDUs (small frame headers, less wasted bandwidth)
-
NFSv3:
+
===Weaknesses===
-
Strengths:
+
# the extended protocol poorly documented,
-
a) relatively simple to implement
+
# not an IETF standard
-
b) maps well to Unix VFS semantics (except for caching)
+
# elements of older protocol dialects still needed adding to complexity of implementations
-
c) protocol easy to understand by stripping file protocol to its
+
# protocol needs addition of lock migration/recovery and support for new transport mechanisms (e.g. RDMA)
-
minimum
+
# ACL support - although useful is hard to understand
-
d) Unicode
+
# (item j above) management/admistrative calls are proprietary
-
Weaknesses:
+
==NFSv3==
-
a) statelessness of core protocol causes caching problems
+
===Strengths===
-
b) few Windows NFS clients installed
+
# relatively simple to implement
-
c) maps poorly to Windows operating system API
+
# maps well to Unix VFS semantics (except for caching)
-
d) poor security (forcing it into lower layers if at all)
+
# protocol easy to understand by stripping file protocol to its minimum
-
e) not a standard (informational description published by Sun as
+
# leverages ONC-RPC's authentication model for free, and good, security
-
informational RFC)
+
# many non-UNIX implementations (Windows, OS/400, ...)
-
f) relatively weak open source server implementation (at least
+
# Open Group standard, see http://www.opengroup.org/bookstore/catalog/c702.htm
-
compared to Samba and AFS) has scalability problems
+
# test suite available at http://www.opengroup.org/testing/testsuites/vsx4nfsov.htm
-
g) implementing many protocols needed to get CIFS equivalent e.g. lock
+
# SPEC server performance benchmark available at http://www.spec.org/benchmarks.html#nfs
-
manager, mount and port mapping protocol, SunRPC, NIS, ONC extensions (some
+
-
proprietary)
+
-
h) WebNFS enhancements partially implemented adding to some confusion
+
 +
===Weaknesses===
 +
# statelessness of core protocol causes caching problems
 +
# few Windows NFS clients installed
 +
# Security based on Unix Userids - no security if these are spoofable
 +
# maps poorly to Windows operating system API
 +
# not an IETF standard (informational description published by Sun and NetApp as an informational RFC)
 +
# relatively weak open source server implementation (at least compared to Samba and AFS) has scalability problems
 +
# implementing many protocols needed to get CIFS equivalent e.g. lock manager, mount and port mapping protocol, SunRPC, NIS, ONC extensions (some proprietary)
 +
# WebNFS enhancements partially implemented adding to some confusion
 +
# No support for Unicode, UTF/8, UCS-4, etc.
-
NFSv4:
+
==NFSv4==
-
Strengths:
+
===Strengths===
-
a) on track to be an IETF standard
+
# IETF standards track specification
-
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
 +
# Mandates strong authentication and integrity via Kerberos and SPKM-3
 +
# Supports rich access control model via Windows 2000-like Access Control Lists (ACLs)
 +
# Exports a pre-existing filesystem to the network; no data migration is necessary to enable or disable NFS
-
Weaknesses:
+
===Weaknesses===
-
a) few clients
+
# still relatively "new"--Linux and other implementations are maturing but not widely deployed yet.
-
b) perceived lack of Microsoft interest
+
# perceived lack of Microsoft interest
-
c) the existing prototype open source implementation is tricky to
+
# too late?
-
integrate into current Linux kernels
+
# complex
-
d) protocol is moving target (it is not quite done yet)
+
-
e) too late?
+
-
f) 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.
+
# (see NFS v4)
-
b) (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==
-
Strengths:
+
-
a) sophisticated distributed caching (token management)
+
-
b) DCE integration (including Kerberos and RPC)
+
-
c) standardized by OpenGroup
+
-
Weakness:
+
(DFS is related to AFS but deprecated for various reasons)
-
a) lack of clients
+
-
b) bulky, slow Windows clients
+
-
c) server integration with Unix operating systems and server
+
-
filesystem is complicated
+
-
d) most implementations were expensive
+
-
e) complex to implement
+
 +
===Strengths===
 +
# Kerberos 5 integration
 +
# abstraction layer between namespace and physical location, eases maintanance expense
 +
# excellent Linux and Windows- Client support
 +
# aggressive client side caching with proactive cache-invalidation
-
Coda:
+
===Weakness===
-
Strengths:
+
# difficult to setup
-
a) disconnected support
+
# complex, big linux kernel module for client
 +
# Implements its own storage layer over an extXfs filesystem; data must be migrated in to be usable with OpenAFS, and migrated out to be usable without.
-
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
 +
 
 +
==Lustre==
 +
(help?)
 +
 
 +
===Strengths===
 +
# Fully distributed.
 +
# Excellent performance.
 +
 
 +
===Weaknesses===
 +
# Poor community interaction.
 +
# lack of clients.
 +
 
 +
==GFS==
 +
(help?)
 +
 
 +
===Strengths===
 +
# Fully distributed.
 +
 
 +
===Weaknesses===
 +
# Needs heavy-duty, not-standardized cluster management system.
 +
# Linux-only (?)
 +
 
 +
==GPFS==
 +
 
 +
===Strengths===
 +
# Highly Scalable
 +
# Data Replication
 +
# Policy Based Storage Management
 +
# Good performance.
 +
# Stable, well-tested.
 +
 
 +
===Weaknesses===
 +
# Commercial-only.

Latest revision as of 21:36, 23 June 2010

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


Contents

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
  4. the key part of the filesystem protocol (mostly) documented, rich file open semantics map well to Windows and related OSs,
  5. kerberos security integration and RPC integration
  6. broader in scope (print, ACL, browsing etc.) than other filesystem protocols
  7. optional PDU signing above the RPC allowing maximal flexibility
  8. Unicode
  9. high performance
  10. huge amount of loosely related management/administrative function available via various DCE RPC calls
  11. 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
  4. protocol needs addition of lock migration/recovery and support for new transport mechanisms (e.g. RDMA)
  5. ACL support - although useful is hard to understand
  6. (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
  4. leverages ONC-RPC's authentication model for free, and good, security
  5. many non-UNIX implementations (Windows, OS/400, ...)
  6. Open Group standard, see http://www.opengroup.org/bookstore/catalog/c702.htm
  7. test suite available at http://www.opengroup.org/testing/testsuites/vsx4nfsov.htm
  8. SPEC server performance benchmark available at http://www.spec.org/benchmarks.html#nfs

Weaknesses

  1. statelessness of core protocol causes caching problems
  2. few Windows NFS clients installed
  3. Security based on Unix Userids - no security if these are spoofable
  4. maps poorly to Windows operating system API
  5. not an IETF standard (informational description published by Sun and NetApp as an informational RFC)
  6. relatively weak open source server implementation (at least compared to Samba and AFS) has scalability problems
  7. implementing many protocols needed to get CIFS equivalent e.g. lock manager, mount and port mapping protocol, SunRPC, NIS, ONC extensions (some proprietary)
  8. WebNFS enhancements partially implemented adding to some confusion
  9. No support for Unicode, UTF/8, UCS-4, etc.

NFSv4

Strengths

  1. IETF standards track specification
  2. improved recovery (lock migration)
  3. supports Windows file sharing semantics better than NFS v3 did
  4. safe file caching
  5. Mandates strong authentication and integrity via Kerberos and SPKM-3
  6. Supports rich access control model via Windows 2000-like Access Control Lists (ACLs)
  7. Exports a pre-existing filesystem to the network; no data migration is necessary to enable or disable NFS

Weaknesses

  1. still relatively "new"--Linux and other implementations are maturing but not widely deployed yet.
  2. perceived lack of Microsoft interest
  3. too late?
  4. complex

DAFS

Strengths

  1. Addition of RDMA to NFS style protocol, (probable) high performance in clusters and server farms.
  2. (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 is related to AFS but deprecated for various reasons)

Strengths

  1. Kerberos 5 integration
  2. abstraction layer between namespace and physical location, eases maintanance expense
  3. excellent Linux and Windows- Client support
  4. aggressive client side caching with proactive cache-invalidation

Weakness

  1. difficult to setup
  2. complex, big linux kernel module for client
  3. Implements its own storage layer over an extXfs filesystem; data must be migrated in to be usable with OpenAFS, and migrated out to be usable without.

Coda

Strengths

  1. disconnected support

Weaknesses

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

Lustre

(help?)

Strengths

  1. Fully distributed.
  2. Excellent performance.

Weaknesses

  1. Poor community interaction.
  2. lack of clients.

GFS

(help?)

Strengths

  1. Fully distributed.

Weaknesses

  1. Needs heavy-duty, not-standardized cluster management system.
  2. Linux-only (?)

GPFS

Strengths

  1. Highly Scalable
  2. Data Replication
  3. Policy Based Storage Management
  4. Good performance.
  5. Stable, well-tested.

Weaknesses

  1. Commercial-only.
Retrieved from "https://client.linux-nfs.org/wiki/index.php/Comparison_of_NFS_vs._others"
Personal tools