8/3/2019 Network File Sharing--version 2 and 3

1/3

Source: Network File System Version 2Ohad Rodeh. Although a few things have been

added to make meaning clearer.

NFS has the issue of making the access of files over the network to communicate with the

file-system domestic in such a way that access of local system for its file-system is

comparable to that over network. FHS is implicitly involved here.

NFS is defined in terms of procedure calls , their arguments etc from an RPC point ofview.

XDRdefines the size, byte order and alignment of basic data types which are going to flow

over the network. The NFS implementation is divided under RPC and XDR. XDR is a data

definition language. RPC calls use itXDR translation procedures used to interpret RPC

protocols.

NFS is stateless protocol setparameters passed to procedure calls have complete

information necessary to implement it; server does not need to remember a thing. This

particularly makes crash recovery very easy because crash of server does not kill procedures

client waits for. But this means one to understand how much parameters can supply, where

is ourbottleneck.

File Handle(fhandle or fh): This is procedureparameterprovided by server and used by

client to reference a file. It is opaqueneither contents nor beyond is visible.

We won't go further into the construct of procedures.

Issues with NFSv2:

No asynchronous read/write

write throughput bottleneck.

8/3/2019 Network File Sharing--version 2 and 3

2/3

Major Changes:

READDIRPLUSprocedure returns fhandle and attributes rendering LOOKUP procedure

useless.

Block concept was dropped for Byte concept.

The server is still stateless and there is weak cache consitency(meaning whenever a block is

modified at client, it is to be modified at server too and that the cache is affective for read traffic but

not the write traffic. Protocols like Alex protocol might be employed)

Problem with replaying non-idempotent request was not addressed.The NFSv3 server expects only asynchronous writes, although supports synchronous ones too. This

is basically because the protocol tends to flush unused(tillstable storage) data before taking new.

8/3/2019 Network File Sharing--version 2 and 3

3/3

Asynchronous Write:

WRITE and COMMIT use an 8-bit write verifier at client side; server uses boot time as

verifier.

Client always matches the write verifiers for each WRITE with subsequent COMMIT

request sent by server with the one it has stored to conclude that server is up, else send

COMMIT data again.

Applications which communicate by storing data inshared files face lot of problems with

asynchronous write.

Prestoserve(Sun)PrestoServe is essentially a way to increase NFS write performance byresponding to an NFS write request immediately and caching the actualright in a fast memory SIMM until it can be written to disk. This alsohas the side affect that a read following the write will also getthe data out of the fast SIMM. Thus PrestoServe ends up speedingup reads and writes. On an SSA with RAID-5 this is a BIG win, becauseof the large write penalty you pay for using RAID-5.