25.02.2013 Views

TCP/IP Tutorial and Technical Overview - IBM Redbooks

TCP/IP Tutorial and Technical Overview - IBM Redbooks

TCP/IP Tutorial and Technical Overview - IBM Redbooks

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

job to synchronize the writers <strong>and</strong> readers accordingly. Though they might not<br />

occur so frequently, take these incidents into consideration.<br />

14.4.3 Lock Manager protocol<br />

14.4.4 NFS file system<br />

14.4.5 NFS version 4<br />

This protocol allows client <strong>and</strong> server processes to exclude the other processes<br />

when they are writing to the file. When a process locks the file for exclusive<br />

access, no other process can access the file. When a process locks the file for<br />

shared access, the other processes can share the file but cannot initiate an<br />

exclusive access lock. If any other process request conflicts with the locking<br />

state, either the process waits until the lock is removed or it returns an error<br />

message.<br />

NFS assumes a hierarchical, or directory-based, file system. In such a system,<br />

files are unstructured streams of uninterpreted bytes; that is, files are seen as a<br />

contiguous byte stream, without any record-level structure.<br />

With NFS, all file operations are synchronous. This means that the file operation<br />

call only returns when the server has completed all work for this operation. In<br />

case of a write request, the server will physically write the data to disk <strong>and</strong> if<br />

necessary, update any directory structure before returning a response to the<br />

client. This ensures file integrity.<br />

NFS also specifies that servers should be stateless. That is, a server does not<br />

need to maintain any extra information about any of its clients in order to function<br />

correctly. In case of a server failure, clients only have to retry a request until the<br />

server responds without having to reiterate a MOUNT operation.<br />

NFS in version 4 (NFSv4) is defined in RFC 3530. The NFS model <strong>and</strong> concepts<br />

are essentially unchanged from version 3 (RFC 1813), <strong>and</strong> the new version<br />

focuses on improving performance, increasing security, augmenting<br />

cross-platform interoperability, <strong>and</strong> providing a design for protocol extensions.<br />

Removal of ancillary protocols<br />

As noted previously, the NFS model incorporated numerous other protocols,<br />

such as the Mount protocol <strong>and</strong> the Lock Management protocol, in order to<br />

address gaps in the basic NFS protocol. The use of the Mount protocol in<br />

pervious versions of NFS was solely for the purpose of obtaining the initial file<br />

h<strong>and</strong>le for individual servers. This has been replaced by the combination of<br />

Chapter 14. File-related protocols 543

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!