11 citations found. Retrieving documents...
Juszczak, C., "Improving the Performance and Correctness of an NFS Server," Proceedings of the USENIX Winter 1989 Conference.

 Home/Search   Document Not in Database   Summary   Related Articles   Check  

This paper is cited in the following contexts:
The NFS Version 4 Protocol - Spencer (2000)   (10 citations)  (Correct)

....router replays a previous unlock request other clients may acquire a conflicting lock and corrupt data. The RPC layer s transaction id will defend against many of these replay errors, but the server duplicate request caches are frequently not large enough to handle even modest windows of time [Juszczak]. Locking requests by an application in virtually all operating systems are strictly ordered, defining a well known state of the file. This requires that a server in a distributed file system also process the locking requests in the required strict order. NFS Version 4 adds to every lock and ....

Juszczak, C., "Improving the Performance and Correctness of an NFS Server," Proceedings of the USENIX Winter 1989 Conference.


Improving NFS Performance over Wireless Links - Rohit Dube Cynthia (1997)   (6 citations)  (Correct)

....and section 4 present the results of our experiments. We propose some ideas for future investigation in section 5. Finally, section 6 summarizes this paper and presents our conclusions. 2 Related Work and Solution Approach Much research has been done to optimize NFS performance on wired LANs [Jus89] Jus94] PJS 94] New file systems have been developed to support disconnected operation via diskcaching [SK92] SNKP94] HHRB92] For improving application performance over wireless links, an M RPC system has been proposed [BB95a] Enhancements have been suggested to improve TCP ....

....over wireless links. We use linear back off and smaller block sizes on the NFS client on one hand, and link layer retransmissions on the other to obtain performance improvements. 2. 1 Related Work The performance of NFS over traditional wired LANs has been improved by using a server reply cache [Jus89] by using write gathering to improve write throughput [Jus94] and 2 by allowing larger than 8KB block sizes and allowing asynchronous writes [PJS 94] These modifications improve NFS performance at the NFS server and would not significantly help the performance of NFS in a wireless ....

C. Juszczak. Improving the Performance and Correctness of an NFS Server. In USENIX Conference Proceedings, pages 53 -- 63, January 1989.


Not Quite NFS, Soft Cache Consistency for NFS - Macklem (1994)   (4 citations)  (Correct)

....request is retransmitted. There are two problems with this model. First, when a retransmit timeout occurs, the RPC may be redone, instead of simply retransmitting the RPC request message to the server.Arecent request cache can be used on the server to minimize the negative impact of redoing RPCs [Juszczak89]. The second problem is that a large UDP datagram, such as a read request or write reply,must be fragmented by IP and if any one IP fragment is lost in transit, the entire UDP datagram is lost [Kent87] Since entire requests and replies are packaged in a single UDP datagram, this puts an upper ....

Chet Juszczak, Improving the Performance and Correctness of an NFS Server,In Proc. Winter 1989 USENIX Conference, pg. 53-63, San Diego, CA, January 1989.


Recovery Protocol or Spritely NFS - Mogul (1992)   (Correct)

....and so need not recover state after a crash. Statelessness is not inherently good. Since many NFS operations are non idempotent and might be retried due to a communication failure, to get reasonable performance and better correctness the server must cache the results of recent transactions [8]. Such cache state is not normally recovered after a crash, although this exposes the client to a possible idempotency failure. A more serious problem with NFS statelessness is that it forces a tradeoff between inter client cache consistency and client file write performance. In order to avoid ....

Chet Juszczak. Improving the Performance and Correctness of an NFS Server. In Proc. Winter 1989 USENIX Conference, pages 53-63. San Diego, February, 1989.


Recovery in Spritely NFS - Mogul (1993)   (7 citations)  (Correct)

....and so need not recover state after a crash. Statelessness is not inherently good. Since many NFS operations are non idempotent and might be retried due to a communication failure, to get reasonable performance and better correctness the server must cache the results of recent transactions [11]. Such cache state is not normally recovered after a crash, although this exposes the client to a possible idempotency failure. A more serious problem with NFS statelessness is that it forces a tradeoff between inter client cache consistency and client file write performance. In order to avoid ....

Chet Juszczak. Improving the Performance and Correctness of an NFS Server. In Proc. Winter 1989 USENIX Conference, pages 53-63. San Diego, February, 1989.


The 4.4BSD NFS Implementation - Macklem (1993)   (1 citation)  (Correct)

....allocation situations in the BSD kernel where the termination signal will be ignored and the process will not terminate. 7 At best, an extraneous RPC request retransmit increases the load on the server and at worst can result in damaged files on the server when non idempotent RPCs are redone [Juszczak89]. 8 6 IP fragments for an Ethernet, which has an maximum transmission unit of 1500bytes. 9 After the first retransmit timeout, the initial interval is backed off exponentially. 10 Even 0.1 of the total RPCs is probably significant. SMM:06 4 The 4.4BSD NFS Implementation sport. 11 NFS ....

....of trashed RPC replies that are received and should remain zero. 15 The X Replies field counts the number of repeated RPC replies received from the server and is a clear indication of a too aggressive RTO estimate. Unfortunately, a good NFS server implementation will use a recent request cache [Juszczak89] that will suppress the extraneous replies. A large value for Retries indicates a problem, but it could be any of: # a too aggressive RTO estimate # an overloaded NFS server # IP fragments being dropped (gateway, client or server) and requires further investigation. The Requests field is the ....

Chet Juszczak, Improving the Performance and Correctness of an NFS Server, In Proc. Winter 1989 USENIX Conference, pg. 53-63, San Diego, CA, January 1989.


Improving NFS Performance over Wireless Links - Rohit Dube (1997)   (6 citations)  (Correct)

....links, but their results provide useful hints toward the specific problem being considered in this paper. The relation of these studies to our research is discussed in the following paragraphs. The performance of NFS over traditional wired LANs has been improved by using a server reply cache [Jus89] by using write gathering to improve write throughput [Jus94] and by allowing larger than 8KB block sizes and allowing asynchronous writes [PJS 94] These modifications improve NFS performance at the NFS server but would not significantly help the performance of NFS in a wireless ....

C. Juszczak. Improving the Performance and Correctness of an NFS Server. In USENIX Conference Proceedings, January 1989.


Discovery and Hot Replacement of Replicated Read-Only File.. - Zadok (1993)   (5 citations)  (Correct)

....have changed the kernel s client side NFS implementation, and outside the operating system we have made use of the Amd automounter and the RLP resource location protocol. Each is explained briefly below. 2. 1 NFS Particulars about the NFS protocol and implementation are widely known and published [20, 12, 9, 19]. For the purpose of our presentation, the only uncommon facts that need to be known are: ffl Translation of a file path name to a vnode is done mostly within a single procedure, called au lookuppn( that is responsible for detecting and expanding symbolic links and for detecting and crossing ....

C. Juszczak. Improving the Performance and Correctness of an NFS Server. In Proc. 1989 Winter USENIX Conf., pages 53--63, January 1989.


Improving NFS Performance over Wireless Links - Dube, Rais, Tripathi (1997)   (6 citations)  (Correct)

....links, but their results provide useful insights to the specific problem being considered in this paper. The relation of these studies to our research is discussed in the following paragraphs. The performance of NFS over traditional wired LANs has been improved by using a server reply cache [Jus89] by using write gathering to improve write throughput [Jus94] and by allowing larger than 8KB block sizes and allowing asynchronous writes [PJS 94] These modifications improve NFS performance at the NFS server but would not significantly help the performance of NFS in a wireless ....

C. Juszczak. Improving the Performance and Correctness of an NFS Server. In USENIX Conference Proceedings, January 1989.


Non-Volatile Memory for Fast, Reliable File Systems - Baker, Asami, Deprit.. (1992)   (24 citations)  (Correct)

....Traditional distributed file systems, especially file servers running the UNIX fast file system [13] in the NFS [19] environment, have already used NVRAM to reduce disk traffic. It is particularly beneficial for NFS file systems, since the NFS protocol requires many synchronous write operations [11]. The Legato Systems Prestoserve board [15] caches NFS server requests in non volatile memory to reduce the latency of synchronous writes to the file system, and performance improvements of up to 50 have been reported on systems using this board. IBM uses four megabytes of NVRAM on the 3990 3 ....

Juszczak, C., "Improving the Performance and Correctness of an NFS Server", Proceedings of the Winter 1989 USENIX Conference, San Diego, CA, February 1989.


Improving the Write Performance of an NFS Server - Juszczak (1994)   (9 citations)  Self-citation (Juszczak)   (Correct)

.... account for two thirds or more of the total latency and contribute more than its share to server CPU and I O loading [WITT93] Also, the large latencies of NFS write operations can lead to more serious problems on the server when it is faced with retransmissions from impatient clients [JUSZ89]. This paper describes the implementation of a write gathering technique that exploits the fact that there are often several write requests for the same file presented to the server at about the same time. With this technique the data portions of these writes are combined and a single metadata ....

....active writes via VOP SYNCDATA. Flush the metadata via VOP FSYNC. Send all pending replies for the file to the client. Return to rfs dispatch( with a reply done code. 6.9. Duplicate Requests, Stale File Handles, Etc. Stale file handles are client references to files that no longer exist. See [JUSZ89] for a discussion of duplicate NFS requests. The existence of these requests, in the socket buffer e.g. could have caused nfsds to delay their replies. The implementor must not to be too hasty discarding duplicates, etc. meaning I was at first ) this could result in orphaned writes on the ....

Chet Juszczak, "Improving the Performance and Correctness of an NFS Server", Proceedings Winter Usenix 1989, San Diego, CA, 53-63, January 1989.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC