08-18-2009, 06:58 PM
Sandberg, R., Golgberg, D., Kleiman, S., Walsh, D., and Lyon, B. 1988. Design and implementation of the Sun network filesystem. In innovations in internetworking Artech House, Norwood, MA, 379-390.
08-18-2009, 06:58 PM
12-23-2009, 01:28 PM
A link to this paper: http://www.stanford.edu/class/cs240/readings/nfs.pdf
02-14-2011, 09:02 PM
Although designed and implemented in 1980s, NFS (the later version)
still serves as the network file system for lots systems because of its
features like machine and OS independence, transparent access, and high
performance.
The design of NFS uses some level "pure" protocol, while the
implementation uses techniques to achieve the high performance.
Although the pure stateless protocol makes the design of NFS simple, a
little relaxed protocol may makes NFS more easier to be used in more
widely area and get good performance:
Cache is important for the performance, and we see it is used to improve
NFS's performance. But cache hurts the purity of the stateless protocol
since the cache is part of the server's state.
UDP is used to ensure the stateless feature. But using UDP to transport
small packets has bad performance (speed) than TCP when being used in a
network environments that are not as good as LAN such as Internet. The
later version of NFS allows the users to choose TCP as the protocol.
In the practice, we also find that the latency is "big": some time
(seconds) client A writes to the file in NFS, another clients B can read
out the data from the file. This may be caused by the cache in the
client side which is not invalidated when the NFS server gets update
(client A writes to the file). If using a not so "pure" protocol, the
NFS server can invalidate the client's cache to further optimize the
latency and NFS can be used in a more wider area, such as storing
configuration for distributed applications.
still serves as the network file system for lots systems because of its
features like machine and OS independence, transparent access, and high
performance.
The design of NFS uses some level "pure" protocol, while the
implementation uses techniques to achieve the high performance.
Although the pure stateless protocol makes the design of NFS simple, a
little relaxed protocol may makes NFS more easier to be used in more
widely area and get good performance:
Cache is important for the performance, and we see it is used to improve
NFS's performance. But cache hurts the purity of the stateless protocol
since the cache is part of the server's state.
UDP is used to ensure the stateless feature. But using UDP to transport
small packets has bad performance (speed) than TCP when being used in a
network environments that are not as good as LAN such as Internet. The
later version of NFS allows the users to choose TCP as the protocol.
In the practice, we also find that the latency is "big": some time
(seconds) client A writes to the file in NFS, another clients B can read
out the data from the file. This may be caused by the cache in the
client side which is not invalidated when the NFS server gets update
(client A writes to the file). If using a not so "pure" protocol, the
NFS server can invalidate the client's cache to further optimize the
latency and NFS can be used in a more wider area, such as storing
configuration for distributed applications.
04-01-2011, 10:25 PM
The Network File System (NFS) can be considered as a remote accessing protocol
rather than a typical file system because it does not store the data itself. Instead,
it relies on the lower level file system on the server to manage the storage of data
and metadata.
The NFS environment is implemented on top of Sun RPC. The NFSv3
assumes a stateless server implementation which means that the servers do not
need to remember any state information of the clients and previous requests. The
advantage of this design choice is that the recovery after a crash becomes very
simple. If the client crashes, the server needs not to discovery this failure, neither
to handle any states related to the failed client. Meanwhile, if the server fails, the
client can just retry the request periodically until the server responsed (recovered
from the failure).
However, this simplification brings some problems indeed. For the stateless
server, there should be no locks implemented because locks are some kind of
states. If a client holding a lock fails, the server must be able to detect that
and release the lock. Lack of the concurrent write guarantee from the locks or
other mechanisms (such as transactions), multiple clients writing the same file
may cause inconsistency.
Caching is another typical mechanism to increase the performance of network
file systems. A stateless server may not be able to perform a cache coherence
protocol due to the lack of information of the clients. Meanwhile, periodically
check the state of a file on the remote end wastes the network bandwidth. Research
such as Spritely NFS solved this problem and modified the NFS protocol to
be stateful to add some cache coherence protocol upon it.
In NFSv4, the protocol has been revised and the stateless feature is abandoned.
The new version NFS added states both on clients and on servers. To detect the
failures and take corresponding actions against it, a lease is introduced to
operations such as ‘open’, ‘close’ and ‘lock’. The server maintains the states
with a lease. The client should always renew its lease with ‘renew’ operation
or implicitly with ‘read’ or other operations. If a client fails to renew the holding
leases, it is considered dead and all the states associated with it should be released.
rather than a typical file system because it does not store the data itself. Instead,
it relies on the lower level file system on the server to manage the storage of data
and metadata.
The NFS environment is implemented on top of Sun RPC. The NFSv3
assumes a stateless server implementation which means that the servers do not
need to remember any state information of the clients and previous requests. The
advantage of this design choice is that the recovery after a crash becomes very
simple. If the client crashes, the server needs not to discovery this failure, neither
to handle any states related to the failed client. Meanwhile, if the server fails, the
client can just retry the request periodically until the server responsed (recovered
from the failure).
However, this simplification brings some problems indeed. For the stateless
server, there should be no locks implemented because locks are some kind of
states. If a client holding a lock fails, the server must be able to detect that
and release the lock. Lack of the concurrent write guarantee from the locks or
other mechanisms (such as transactions), multiple clients writing the same file
may cause inconsistency.
Caching is another typical mechanism to increase the performance of network
file systems. A stateless server may not be able to perform a cache coherence
protocol due to the lack of information of the clients. Meanwhile, periodically
check the state of a file on the remote end wastes the network bandwidth. Research
such as Spritely NFS solved this problem and modified the NFS protocol to
be stateful to add some cache coherence protocol upon it.
In NFSv4, the protocol has been revised and the stateless feature is abandoned.
The new version NFS added states both on clients and on servers. To detect the
failures and take corresponding actions against it, a lease is introduced to
operations such as ‘open’, ‘close’ and ‘lock’. The server maintains the states
with a lease. The client should always renew its lease with ‘renew’ operation
or implicitly with ‘read’ or other operations. If a client fails to renew the holding
leases, it is considered dead and all the states associated with it should be released.
04-04-2011, 11:19 PM
Critical review
Critical review
This is a very classic paper, though it is republished in 1980s. But, from now on view, there are still lots of innovative ideas,sophisticated thinking to learn.
The whole paper proposed a 'new' file system protocal, using the remote procedure call to allow a user on a client computer to access files over a network in a manner similar to how local storage is accessed. The paper introduce the VFS(vitural file system),and introduce the client site and the server site in details. they also show the UDP to transport small packets. And show there performace, pointing out what is to enhance.
As we have known , The nfs develop by sun soon became an open standard which improve there excellence in design. Especially in adding an new interface to separates generic file system from specific file system. So that, they didn't need to do on each system. Does that mean we can refer this mind to cloud computing, to do the migration of cloud computing?
In strength or all kinds of ways, environmental requirements were satisfacted by the nfs quite well. And the nfs aslo do the future work in the paper, such as the security, etc.
However, from now on view , the nfs is not suitable for the huge distribude system. But in my opinion, if a software or a design, can be used for 10 years, it can be called excellent. If it can be use for 20 years or longer, it can be call great indeed.
Critical review
This is a very classic paper, though it is republished in 1980s. But, from now on view, there are still lots of innovative ideas,sophisticated thinking to learn.
The whole paper proposed a 'new' file system protocal, using the remote procedure call to allow a user on a client computer to access files over a network in a manner similar to how local storage is accessed. The paper introduce the VFS(vitural file system),and introduce the client site and the server site in details. they also show the UDP to transport small packets. And show there performace, pointing out what is to enhance.
As we have known , The nfs develop by sun soon became an open standard which improve there excellence in design. Especially in adding an new interface to separates generic file system from specific file system. So that, they didn't need to do on each system. Does that mean we can refer this mind to cloud computing, to do the migration of cloud computing?
In strength or all kinds of ways, environmental requirements were satisfacted by the nfs quite well. And the nfs aslo do the future work in the paper, such as the security, etc.
However, from now on view , the nfs is not suitable for the huge distribude system. But in my opinion, if a software or a design, can be used for 10 years, it can be called excellent. If it can be use for 20 years or longer, it can be call great indeed.
11-24-2011, 07:56 PM
Summary
This paper mainly discusses the design and implementation of NFS (Network File System), which is portable, OS independent, transparent to existing programs, crash resilient and reasonably fast.
The author elegantly separates the implementations from interfaces. For interfaces, vnode and VFS successfully unifies ways of local and remote file access. Under common interfaces, the modified UNIX kernel would have different implementations thus make such transparency available.
Moreover, this paper talks about the architecture and data flow of both client and server. A stateless protocol makes crash recovery very easy and the separated MOUNT protocol further enables unified file access.
The paper also discussed the encountered problems when implementing NFS. For example, sharing root filesystem would cause many potential problems like conflict temporary files named after process ID, which is not unique across network. Time skew is another problem, which happens in any program comparing system time and modification time.
Finally, performance is taken into consideration and the author listed their work to improve it.
Critique
RPC is adopted without enough reasons. The author explains that RPC is to help simplify protocol definition, implementation and maintenance, which is insufficient. Actually, RPC is optimized for small messages exchange but NFS transmits a large block of data (heavy read). Moreover, RPC makes request caching difficult.
Data encryption is not considered in this paper. NFS would suffer from security issues when it is not in local network.
The adoption of UDP in NFS is somewhat lack of consideration. Although loss of packets wouldn’t cause system crash, UDP prevents performance increase even when server can predict potential requests. For instance, if a read request comes from a client, it is reasonable to guess another read request would come thus keeping connection alive would decrease some cost. This idea comes from protocol of HTTP/1.1, which can group sequential GET requests in a single TCP connection.
It is not OS independent. In fact, NFS is constructed totally on UNIX platform since it directly adopts UNIX authentication mechanism (user, group) and the author spent much time resolving authentication issues among different UNIX workstations. However, DOS is a single-user operating system and has no complicated authentication or mount mechanism as UNIX. And this paper does not discuss NFS between DOS and UNIX.
More information is needed when talking about performance such as network topology and network load.
Future Work
It is really a tough section for this paper is published in 1980s, thus I am not talking about future work but something already happened. With little experience in this area, I would like to talk about my “future” ideas.
Lock mechanism can be added because data consistency is really important in highly concurrent environment.
More work on performance optimization is needed in order to make NFS more popular.
Security issues should be overcome if NFS is adopted in a much larger network such as internet.
This paper mainly discusses the design and implementation of NFS (Network File System), which is portable, OS independent, transparent to existing programs, crash resilient and reasonably fast.
The author elegantly separates the implementations from interfaces. For interfaces, vnode and VFS successfully unifies ways of local and remote file access. Under common interfaces, the modified UNIX kernel would have different implementations thus make such transparency available.
Moreover, this paper talks about the architecture and data flow of both client and server. A stateless protocol makes crash recovery very easy and the separated MOUNT protocol further enables unified file access.
The paper also discussed the encountered problems when implementing NFS. For example, sharing root filesystem would cause many potential problems like conflict temporary files named after process ID, which is not unique across network. Time skew is another problem, which happens in any program comparing system time and modification time.
Finally, performance is taken into consideration and the author listed their work to improve it.
Critique
RPC is adopted without enough reasons. The author explains that RPC is to help simplify protocol definition, implementation and maintenance, which is insufficient. Actually, RPC is optimized for small messages exchange but NFS transmits a large block of data (heavy read). Moreover, RPC makes request caching difficult.
Data encryption is not considered in this paper. NFS would suffer from security issues when it is not in local network.
The adoption of UDP in NFS is somewhat lack of consideration. Although loss of packets wouldn’t cause system crash, UDP prevents performance increase even when server can predict potential requests. For instance, if a read request comes from a client, it is reasonable to guess another read request would come thus keeping connection alive would decrease some cost. This idea comes from protocol of HTTP/1.1, which can group sequential GET requests in a single TCP connection.
It is not OS independent. In fact, NFS is constructed totally on UNIX platform since it directly adopts UNIX authentication mechanism (user, group) and the author spent much time resolving authentication issues among different UNIX workstations. However, DOS is a single-user operating system and has no complicated authentication or mount mechanism as UNIX. And this paper does not discuss NFS between DOS and UNIX.
More information is needed when talking about performance such as network topology and network load.
Future Work
It is really a tough section for this paper is published in 1980s, thus I am not talking about future work but something already happened. With little experience in this area, I would like to talk about my “future” ideas.
Lock mechanism can be added because data consistency is really important in highly concurrent environment.
More work on performance optimization is needed in order to make NFS more popular.
Security issues should be overcome if NFS is adopted in a much larger network such as internet.