Talk:Network File System

message: 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)
replies: text: Dalielx 2806:264:5483:10C3:A197:A738:9BA4:1F2E (talk) 18:14, 10 August 2023 (UTC)
thread_title:  Advantages? 

message: sure newer NFS operates over TCP.  Robneild 00:16, 30 Jan 2004 (UTC)
thread_title:  '''pretty''' 

message: Does anyone remember WebNFS?  Some sort of half-arsed attempt by Sun to
get everyone to replace HTTP with NFS?
Richard W.M. Jones 10:53, 10 August 2005 (UTC)
thread_title:  WebNFS

message: 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)
replies: text: 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 82.238.217.133 (talk • contribs) 00:09, 12 September 2006 (UTC)

text: 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)
thread_title:  No mention of its place in ONC? 

message: 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 82.238.217.133 (talk • contribs) 00:09, 12 September 2006 (UTC)
replies: text: 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)
thread_title:  ND ? 

message: Mre5765 01:40, 2 November 2005 (UTC)
thread_title:  added discussion of webnfs, onc, and nlm 

message: 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)
replies: text: Technically, NFS no longer stands for anything. Mre5765 01:41, 2 November 2005 (UTC)
replies: text:  That must be a post-RFC-3530 change, Mike - RFC 3530 is titled "Network File System (NFS)". Guy Harris 02:33, 5 January 2006 (UTC)
replies: text:  Guy, Sun, the legal owner of the NFS trademark, at some point decided NFS stood for nothing. This was well before RFC 3530 ... probably while you were still at Sun. Mre5765 04:51, 20 January 2006 (UTC)
thread_title:  Network Failure System? 

message: 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)
replies: text: 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)
thread_title:  Some technical terms need wikilinking. 

message: 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)
thread_title:  Copy-edit? 

message: NFS is an IETF protocol, if any thing.
Mre5765 19:18, 31 January 2007 (UTC)
thread_title:  WTF added (Sun) to this title? 

message: 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)
thread_title:  active-active and active-passive NFS 

message: 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:
#Network File System (protocol) or
#Network File System protocol ?
I'll move it to option 1, unless I hear any objections or alternate titles.+mwtoews 21:33, 11 May 2007 (UTC)
replies: text: The first sounds good to me. --moof 02:14, 12 May 2007 (UTC)
replies: text: Moved. I've updated half of the redirects ... I'll do the other half tomorrow. +mwtoews 08:56, 12 May 2007 (UTC)
thread_title:  Move page? 

message: [Sun] and [DEC] used to sell this 'NFS Accelerator' -- perhaps a brief reference should be added to the article. 91.76.57.235 (talk) 13:36, 23 December 2007 (UTC)
thread_title:  PrestoServe 

message: 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.
Robert.harker (talk) 01:07, 30 April 2008 (UTC)
replies: text: 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)
thread_title:  Sun invented NFS, not IBM 

message: 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?
(I'm asking for this because i don't have the info and want it so can't offer to write it.  sorry.)  —Preceding unsigned comment added by 69.136.108.216 (talk) 22:37, 14 October 2008 (UTC)
replies: text: 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)
replies: text: Server side caching is important here, as it affects the way that NFS works. Client side normally doesn't.  Gah4 (talk) 17:33, 7 September 2016 (UTC)
thread_title:  client side caching? 

message: 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 69.136.108.216 (talk) 22:42, 14 October 2008 (UTC)
thread_title:  NFS as borg? 

message: Compared to Articles featuring UDP or TCP, I'm greatly missing information about packet formats and sizes. --Poc (talk) 13:46, 18 July 2010 (UTC)
thread_title:  Technical details missing 

message: 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. 
http://www.sqlite.org/testing.html
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.
Drkirkby (talk) 11:18, 9 October 2010 (UTC)
thread_title:  How reliable is NFS? 

message: 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)
thread_title:  Is it not "Network File Service"? 

message: "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... ? 
Please? Thanks, and apologies.  — Preceding unsigned comment added by 68.183.238.154 (talk) 07:33, 22 October 2012 (UTC)
replies: text: 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)
thread_title:  Unreadable - yet essential -- please help 

message: 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)
replies: text: 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)

text: 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)
thread_title:  Network File System or network file system? 

message: 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)
replies: text: 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)
thread_title:  UDP 

message: Hello fellow Wikipedians,
I have just modified 2 external links on Network File System. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added  tag to https://yanfs.dev.java.net/
*Added archive https://web.archive.org/web/20110512180716/http://www.connectathon.org/talks06/talpey-cthon06-nfs-rdma.pdf to http://www.connectathon.org/talks06/talpey-cthon06-nfs-rdma.pdf
*Added archive https://web.archive.org/web/20080216083308/http://www.ietf.org/html.charters/nfsv4-charter.html to http://www.ietf.org/html.charters/nfsv4-charter.html
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 11:48, 16 February 2018 (UTC)
thread_title:  External links modified (February 2018)