by R. Sandberg, USENIX 1986.
Abstract:
The Sun Network Filesystem (NFS) provides transparent, remote access to filesystems. Unlike many other remote filesystem implementations under UNIX, NFS is designed to be easily portable to other operating systems and machine architectures. It uses an External Data Representation (XDR) specification to describe protocols in a machine and system independent way. NFS is implemented on top of a Remote Procedure Call package (RPC) to help simplify protocol definition, implementation, and maintenance.
In order to build NFS into the UNIX kernel in a way that is transparent to applications, we decided to add a new interface to the kernel which separates generic filesystem operations from specific filesystem implementations. The “filesystem interface” consists of two parts: the Virtual File System (VFS) interface defines the operations that can be done on a filesystem, while the virtual node (vnode) interface defines the operations that can be done on a file within that filesystem. This new interface allows us to implement and install new filesystems in much the same way as new device drivers are added to the kernel.
In this paper we discuss the design and implementation of the filesystem interface in the UNIX kernel and the NFS virtual filesystem. We compare NFS to other remote filesystem implementations, and describe some interesting NFS ports that have been done, including the IBM PC implementation under MS/DOS and the VMS server implementation. We also describe the user-level NFS server implementation which allows simple server ports without modification to the underlying operating system. We conclude with some ideas for future enhancements.
In this paper we use the term server to refer to a machine that provides resources to the network; a client is a machine that accesses resources over the network; a user is a person “logged in” at a client; an application is a program that executes on a client; and a workstation is a client machine that typically supports one user at a time.
Link to the full paper:
This question is related to the section "Concurrent Access and File Locking"
ReplyDelete1) Is there any solution to avoid intermixing of data while several users are accessing same file/directory and updating it simultaneously? Since NFS uses stateless protocol, so it does not maintain any locks while several users are accessing the same file, so is there any way to solve this/ any mechanism/ any updates in NFS protocol to solve this?
This question is related to "File Consistency". It is evident that NFS implements client caching where a file on the server, that is requested by multiple clients is cached to the respective client workstations. Modifications to the file by these clients are now done on their respective cached copies. How does NFS handle this issue of inconsistent file updates when clients modify a local cached copy?
ReplyDeleteI have a question on the usage of 'stateless protocol' in NFS.
ReplyDeleteOnce the server crashes, the client tries to send the request again and again until it receives a response. Since server does not have a recovery mechanism in place, how can the client requests get served? Doesn't the client requests get 'denial of service' forever once the server crashes? What alternative do we have for this?
When the root users wants to access the files on server , the server maps the user root to user nobody for checking his permissions. This causes some strange behavior on the root user? Why does this happens? What are these strange behaviors? Is there any method by which we can stop this or revert back the changes that has happened on root user to normal?
ReplyDeleteThis question is related to security in NFS.
ReplyDeleteNFS traffic flows in clear-text (even when using "AUTH_DES" or "AUTH_KERB" for authentication) so any files transported via NFS are susceptible to snooping. How is this addressed in latest version of NFS?
This question is related to the confusion of loop mounted of remote file system.
ReplyDeleteCould you explain that if we use "a set of basic mounted filesystems on each machine and then let users add other filesystems on top of that", what will happen? And why this will alleviate the confusion.
While NFS is stateless, 'MOUNT' protocol is used in such a way that mount is done only once - at the beginning - and then it is explicitly unmounted later. In that case, is the 'MOUNT' protocol stateful? If so how is the state maintained? How does a server or client crash affect this mount information?
ReplyDeleteHow NFS will handle heavy network traffic?
ReplyDeleteHow is scalability achieved in NFS?
ReplyDeleteThis comment has been removed by the author.
ReplyDeleteSince older NFS was stateless, if a client mounts a directory of a server at 2 different mount points, creating 2 different bindings, how will the concurrent writes from the same client (but from 2 different processes) be handled? Will the client take a local file_lock while write() to these file?
ReplyDelete2. The same question for single mount point as well. If 2 processes try to write to a file simultaneously, will the local locks still be used in VFS?
How has the NFS evolved that leads to the later parallel cluster file systems and wide area file systems?
ReplyDeleteOne of the design goal of NFS was "Machine and Operating System Independence", but the entire system is syntactically and semantically modelled on Unix. Then how is it OS Independent?
ReplyDelete