Talk:Network File System
|This is the talk page for discussing improvements to the Network File System article.
This is not a forum for general discussion of the article's subject.
|WikiProject Computing / Networking / Software||(Rated C-class, Mid-importance)|
- 1 Advantages?
- 2 NFS over TCP
- 3 pretty
- 4 to Sfoskett
- 5 WebNFS
- 6 No mention of its place in ONC?
- 7 ND ?
- 8 added discussion of webnfs, onc, and nlm
- 9 Network Failure System?
- 10 Some technical terms need wikilinking.
- 11 Copy-edit?
- 12 WTF added (Sun) to this title?
- 13 active-active and active-passive NFS
- 14 PC-NFS
- 15 Move page?
- 16 PrestoServe
- 17 Sun invented NFS, not IBM
- 18 client side caching?
- 19 NFS as borg?
- 20 Technical details missing
- 21 How reliable is NFS?
- 22 Is it not "Network File Service"?
- 23 Unreadable - yet essential -- please help
- 24 Network File System or network file system?
- 25 UDP
Can someone add a section or two on the advantages and disadvantages of NFS over similar systems? I would do it myself, but I'm not familiar with network file systems. Danielx (talk) 21:04, 8 October 2009 (UTC)
NFS over TCP
sure newer NFS operates over TCP. Robneild 00:16, 30 Jan 2004 (UTC)
The statement: "Using TCP as transport made using NFS over a WAN more feasible (although not necessarily practical)." is both an oxymoron (feasible and practical are synonyms so how can something be both "more feasible" and "not ... practical"), and also sounds like bias, since there is nothing to back up the contention it is not practical. Besides which, I've used NFS across a WAN. If no one objects I'm going to delete the "(although ... practical)" part of the statement. —The preceding unsigned comment was added by 126.96.36.199 (talk • contribs) 13:13, 10 June 2005 (UTC).
Well, maybe now it isn't so bad. I had one running over the Internet from a few states away, and it only sort of worked. The problem is that NFS/UDP doesn't adjust the time-out for the network delay. In 1995 (when I tried it) the Internet wasn't as fast as today. (The actual reason for the test was that we moved a client without removing the /etc/fstab entry, and then started it up at a new site.) Gah4 (talk) 06:16, 24 May 2011 (UTC)
where is this "NFS disambig page" ur talkin about??? cant seem to find it Secfan 14:45, Nov 18, 2004 (UTC)
No mention of its place in ONC?
NFS was one of a set of standards and protocols (others included XDR and Sun RPC) that in the 80's Sun clumped together under the title ONC (Open Network Computing). ONC was quite an historic achievement at the time. Apollo NCS was the only thing comparable. The whole political context of UNIX network computing in the 80's is probably worth a mention on this page. —The preceding unsigned comment was added by Sparky62 (talk • contribs) 15:41, 1 October 2005 (UTC).
- User:Mre5765: done. Hope it isn't too much detail.
IIRC, NCS predates XML/RPC, from which it the latter borrowed the idea to redo them with a slightly different set of design choices, notably the basic protocol, since NCS was initially DomainOS-based. —The preceding unsigned comment was added by 188.8.131.52 (talk • contribs) 00:09, 12 September 2006 (UTC).
- NCS predates XML, period (and predates HTTP, for that matter), but none of that is relevant to ONC, which predated both XML (and HTTP) and NCS, although the term "ONC" was, I think, coined as a response to NCS. Guy Harris 08:38, 12 September 2006 (UTC)
It could be interesting to add a note about ND (Network Disk) which NFS replaced circa 1987. Same idea, different implementation (ND was weaker). —The preceding unsigned comment was added by 184.108.40.206 (talk • contribs) 00:09, 12 September 2006 (UTC).
- No, not the same idea - ND supported remote access to a virtual disk, while NFS supported remote access to a file system; ND requests read from or wrote to block numbers on the disk, and the ND client implemented a regular UFS file system on the virtual disk, while NFS requests look and create up files, get attributes of files, read or write from byte offsets within the file, remove files, etc.. Only one machine was supposed to access an ND virtual disk, but multiple machines can access an NFS export. Guy Harris 08:58, 12 September 2006 (UTC)
added discussion of webnfs, onc, and nlm
Mre5765 01:40, 2 November 2005 (UTC)
Network Failure System?
The manpage of maildir on http://www.qmail.org/man/man5/maildir.html says, NFS is an abbreviation of "Network Failure System". Has this been true? What does NFS really stands for?
- No. I suspect a DJB snipe at NFS. Anyone who had to actually have their home dir on NFS during the early 90s would however probably sympathise. Richard W.M. Jones 19:31, 24 October 2005 (UTC)
- Technically, NFS no longer stands for anything. Mre5765 01:41, 2 November 2005 (UTC)
There are some technical terms here that aren't obvious to the lay person. For instance I don't know exactly what "asynchronous" means in this context, or which wikipedia article to link it to. If anybody could wikilink these terms to the appropriate articles I think a good few people would find that very useful. Ireneshusband 17:10, 20 September 2006 (UTC)
- For original NFS, the system call on the client didn't return until the data was on an actual disk. The client might still buffer data, but a server software crash shouldn't lose data. (If the disk crashes, you can still lose data.) There is a general concept of asynchronous I/O, where a program doesn't wait for the operation to finish before continuing. I don't know if there is a article on that. Gah4 (talk) 17:30, 7 September 2016 (UTC)
If anyone has time, this page could use a copy-edit. For example:
Computer-people often use the term "network file system" as a generic term...
What, exactly, are "computer-people"? Are these the people who live inside my computer and push the electrons around, or are they some sort of computer-human hybrid? There are also a lot of TLAs in the article. In general, it just looks kind of messy and unprofessional. Chrismith 00:31, 1 December 2006 (UTC)
WTF added (Sun) to this title?
NFS is an IETF protocol, if any thing. Mre5765 19:18, 31 January 2007 (UTC)
active-active and active-passive NFS
there is no mentioning to the features in NFS which allow multiple NFS servers to cooperate such as active-active and active-passive modes (?)--Mayz 11:52, 2 February 2007 (UTC)
When I first encountered this page, I was thrown off by the (Sun) part of the title, since I was looking for a general page for the protocol. Then I realized this was the general page for the protocol. Since this protocol it is not exclusive to Sun Microsystems, could this page be moved to one of either:
I'll move it to option 1, unless I hear any objections or alternate titles.+mwtoews 21:33, 11 May 2007 (UTC)
- The first sounds good to me. --moof 02:14, 12 May 2007 (UTC)
- Moved. I've updated half of the redirects ... I'll do the other half tomorrow. +mwtoews 08:56, 12 May 2007 (UTC)
Sun invented NFS, not IBM
NFS was an invention of Sun, IBM was not involved. The original implimentation of NFS was presented at UNIFOURM 85 and was an interoperating demo between Sun, a VAX 750 running BSD UNIX, Gould, and The Wollongong group. UNIFOURM 85 was also the first show wide Ethernet/TCP/IP network at a major trade show.
- I'd been wondering about that too. The original papers were presented at the summer 1985 Usenix in Portland. I was there. No one from IBM is an author on any of the papers (I think there were three). The original protocol spec was a Sun tech report. Rees11 (talk) 17:02, 30 April 2008 (UTC)
client side caching?
Could we get a section on client-side caching, perhaps comparing how cachefs differs from caching in NFSv4, and NFSv4 differs from AFS and Coda?
- Caching is more an implementation than a protocol feature, although protocol features like delegations can certainly make it easier for the client to provide cache consistency. I'm not convinced this article needs to say much about caching. Rees11 (talk) 00:52, 15 October 2008 (UTC)
NFS as borg?
Sounds like NFS is absorbing features from other distributed file systems so maybe some comparisons are in order? time was that different distributed file systems had a few distinct features that made them stand out for particular sets of requirements, but if everybody's learning from everybody else and copying each other are these products becoming more alike? Is NFS becoming all things to all distributed file system specifiers? if not, why not? —Preceding unsigned comment added by 220.127.116.11 (talk) 22:42, 14 October 2008 (UTC)
Technical details missing
How reliable is NFS?
There's no discussion about the reliability of NFS, yet I've known of issues with it. The developers of the Sqlite database take testing very seriously. The size of their test code is more than 600 times the length of the database.
However this is what they say about NFS:
But use caution: this locking mechanism might not work correctly if the database file is kept on an NFS filesystem. This is because fcntl() file locking is broken on many NFS implementations. You should avoid putting SQLite database files on NFS if multiple processes might try to access the file at the same time.
Oracle has figured out how to use NFS with their RDBMS (Oracle 11g).
It should also be noted that there are issues with cache flushing by the NFS Server, due to implementation decisions by operating system manufacturers and operating system distribution providers.
Just because someone implements a standard (i.e. nfs) in a broken way does not make the standard protocol broken. Many [open-source] Linux implementations, for example, do not offer a reliable implementation of NFS as it's default out-of-the-box configuration, for beneficial performance considerations. Most implementations of [closed-source] Solaris and [open-source] OpenSolaris offer reliable NFS implementations out-of-the box, at the cost of a performance hit.
If someone REALLY wants to work this topic, it needs to be done thoroughly and in a balanced way, to illustrate reliability is not necessarily related to the NFS protocol, but to bugs, tuning, and implementation decisions (to make their implementation appear faster out-of-the-box than a competitor's implementation.)
Every operating system has bugs and default tuning considerations for every subsystem, NFS protocol is as reliable as a user wants it to be... just choose the right vendors who have qualified their products. Every release of an OS, database, or patch means a wiki section on this would need to be updated by somebody - and I don't picture anyone really doing this unless they are in the business of providing this kind of support since it is a full-time job! I would recommend against a wiki section on this topic since such information is very quickly dated. DavidHalko (talk) —Preceding undated comment added 17:38, 12 October 2010 (UTC).
Is it not "Network File Service"?
I thought the initial "S" indicated "Service", not "System". Does anyone else have a thought about that?
- No it did not. Perhaps the same acronym was used for something else (perhaps the generic idea?) or someone just made an obvious mistake. See sources to be sure. W Nowicki (talk) 22:35, 7 September 2016 (UTC)
Unreadable - yet essential -- please help
"DFS used DCE as the RPC and derived from the Andrew File System (AFS)."
Forgive me please, but the first thing that pops into my mind is, "Who cares?" This article averages approximately 4 acronyms per sentence and some have absolutely nothing at all to do with NFS.
When one actually gets to setting up NFS, the details run from man page to man page in disorder. One either needs to be a network administrator, or install it in ignorance and run it completely naked in the dark with hiccups everywhere like I am. I came here in desperation looking for understanding, a top-level gestalt.
A picture is worth a thousand words. How about an example network interconnect, with daemons above in bubbles, and lines connecting from client to server, using which network protocols for what transactions? How about a diagram of NFS layers, with API connections to operating system services and sockets? How about a state diagram or a pseudocode listing of the authentication protocol and transfer protocol, with requests and transfers and timeouts and errors? How about a description of the cacheing mechanism and network protocols and server options and mounting options and what the daemons do and where to look in files and tools when troubleshooting... ?
- Some of what you ask about are implementation details. Unix-like systems normally use /etc/exports for the list of what to export, but others use something else. Sun liked to implement their NFS at the kernel level, but others do it at the user level. One result is that on Unix-like systems, you can mount (NFS or not) over a directory with files. Kernel NFS will see the underlying files. You normally don't need all that much detail to get an NFS system running. You do to implement one. Gah4 (talk) 17:41, 7 September 2016 (UTC)
Network File System or network file system?
Is it a proper noun or not? If it's a proper noun, does it stand alone or should it be used only to modify a noun, e.g. "Network File System protocol"? I am trying to standardize the terminology and capitalization for use in my company and I can't find the answers--the Sun/Oracle web site is itself very inconsistent. I have seen references to "NFS file systems" --perhaps that's not as redundant as it looks, if NFS really refers to the protocol.
Is there such a thing as the generic concept "network file system"? I see many instances of that on the Internet, sometimes followed by (NFS), but can't tell if it is being used generically or someone just forgot to capitalize. — Preceding unsigned comment added by Beautdogs (talk • contribs) 20:16, 22 January 2013 (UTC)
- This article is about the specific and original Network File System and therefore is a proper noun. I have not seen network file system used as a generic term but we do have Category:Network file systems here on Wikipedia. ~KvnG 19:41, 5 August 2013 (UTC)
- Although some early sources spell it as "Network Filesystem" I prefer the current name since this is English not German. I would say this topic should be on the protocol (and by extension the clients and servers of the protocol). Thus I would say it is not really a distributed file system, since it is normally just a way of getting access to a centralized (NOT distributed) file system. Or in the case of something like MapR-FS it could also access a file system that IS distributed. I see that the Category:Network file systems includes a sub-category Category:Distributed file systems which seems more correct than the lead. W Nowicki (talk) 22:35, 7 September 2016 (UTC)
Using TCP as a transport made using NFS over a WAN more feasible, and allowed the use of larger read and write transfer sizes beyond the 8 KB limit imposed by User Datagram Protocol (UDP). UDP has a 16 bit length field that includes the header, so can go close to, but not up to 65535 bytes. It then depends on IP fragmentation to get through most link level protocols with smaller frame size. Some UDP implementations, or IP fragment implementations, might limit to 8K, and NFS implementations might also limit it. Even more, Sun used to like to run NFS/UDP with UDP checksums turned off, relying on the ethernet CRC to detect errors. That usually works across a LAN, and for smaller frame sizes, but it is better to use both UDP checksum and ethernet CRC. Gah4 (talk) 17:53, 7 September 2016 (UTC)
- Indeed, I think it was some kind of kernel implementation limitation, not a protocol limitation. Certainly UDPs larger than 8K were even less feasible on a wide-area network, so it is not that far off. Also 8K (plus header) got enshrined as the common Jumbo frame limit, but that came later, and it would require a source to claim cause and effect. W Nowicki (talk) 22:35, 7 September 2016 (UTC)