Diff: NetworkFileSystem

Differences between current version and predecessor to the previous major change of NetworkFileSystem.

Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History

Newer page: version 5 Last edited on Friday, July 29, 2005 11:18:16 am by CraigBox
Older page: version 3 Last edited on Monday, November 8, 2004 10:14:33 am by StuartYeates Revert
@@ -6,6 +6,11 @@
 A nice thing about [NFS] is that it's stateless. Therefore, resource use on the server does not scale with the number of clients, and clients won't be affected as servers disappear and reappear. At least in theory. 
 On the other hand, it lacks many advanced and even not so advanced features or newer networked FileSystems, such as disconnected operation. Its security model is simpleminded at best -- it maps [UID]s between machines, not even attempting to authenticate users. Locking on [NFS] is notoriously unreliable. Performance is a mixed bag; many combinations of [NFS] server and client implementations lead to abysmal throughput. These and an assortment of other problems have led many a SysAdmin to expand the [NFS] acronym as Nightmare FileSystem. 
+NFSv4 has mostly solved these issues, you can have an id remapper to map uid/gid's between machines, Users can be authenticated on a per user basis. Network traffic can be encrypted. locking is now a core part of the protocol, and the entire thing runs over TCP which gives much better performance. NFSv4 is very new at the time of writing (2004-10-08) but seems likely to be set to become the standard version of NFS in very short order (mostly because of the new features listed here).  
 Because it is built on [RPC], it does not use any single port and is therefor difficult for FireWall~s to handle. [Configuring NFS for firewall control |] steps you through the configuration process.