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