Network File System (NFS) Server and Client Configuration in Debian

NFS was developed at a time when we weren’t able to share our drives like we are able to today – in the Windows environment. It offers the ability to share the hard disk space of a big server with many smaller clients. Again, this is a client/server environment. While this seems like a standard service to offer, it was not always like this. In the past, clients and servers were unable to share their disk space.

Thin clients have no hard drives and thus need a “virtual” hard-disk. The NFS mount their hard disk from the server and, while the user thinks they are saving their documents to their local (thin client) disk, they are in fact saving them to the server. In a thin client environment, the root, usr and home partitions are all offered to the client from the server via NFS.

Some of the most notable benefits that NFS can provide are:

• Local workstations use less disk space because commonly used data can be stored on a single machine and still remain accessible to others over the network.

• There is no need for users to have separate home directories on every network machine. Home directories could be set up on the NFS server and made available throughout the network.

• Storage devices such as floppy disks, CDROM drives, and Zip® drives can be used by other machines on the network. This may reduce the number of removable media drives throughout the network.

Note:-

Use nfs-kernel-server package if you have a fairly recent kernel (2.4.27 or better) and you want to use the kernel-mode NFS server. The user-mode NFS server in the “nfs-user-server” package is slower but more featureful and easier to debug than the kernel-mode server.

Installing NFS in Dedian

Making your computer an NFS server or client is very easy.A Debian NFS client needs

# apt-get install nfs-common portmap

while a Debian NFS server needs

# apt-get install nfs-kernel-server nfs-common portmap

NFS Server Configuration

NFS exports from a server are controlled by the file /etc/exports. Each line begins with the absolute path of a directory to be exported, followed by a space-seperated list of allowed clients.

/etc/exports
/home 195.12.32.2(rw,no_root_squash) www.first.com(ro)
/usr 195.12.32.2/24(ro,insecure)

A client can be specified either by name or IP address. Wildcards (*) are allowed in names, as are netmasks (e.g. /24) following IP addresses, but should usually be avoided for security reasons.

A client specification may be followed by a set of options, in parenthesis. It is important not to leave any space between the last client specification character and the opening parenthesis, since spaces are intrepreted as client seperators.

For each options specified in /etc/exports file can be check export man pages.Click here for manpage.

If you make changes to /etc/exports on a running NFS server, you can make these changes effective by issuing the command:

# exportfs -a

NFS Client Configuration

NFS volumes can be mounted by root directly from the command line. For example

# mount files.first.com:/home /mnt/nfs

mounts the /home directory from the machine files.example.com as the directory /mnt/nfs on the client. Of course, for this to work, the directory /mnt/nfs must exist on the client and the server must have been configured to allow the client to access the volume.

It is more usual for clients to mount NFS volumes automatically at boot-time. NFS volumes can be specified like any others in /etc/fstab.

/etc/fstab
195.12.32.1:/home /home nfs rw,rsize=4096,wsize=4096,hard,intr,async,nodev,nosuid 0 0
195.12.32.2:/usr /usr nfs ro,rsize=8192,hard,intr,nfsvers=3,tcp,noatime,nodev,async 0 0

There are two kinds of mount options to consider: those specific to NFS and those which apply to all mounts. Consider first those specific to NFS.

For each options menctioned in /etc/fstab file check the man pages of fstab.Click here for manpage.

NFS Performance Tuning

NFS does not need a fast processor or a lot of memory. I/O is the bottleneck, so fast disks and a fast network help. If you use IDE disks, use hdparam to tune them for optimal transfer rates. If you support multiple, simultaneous users, consider paying for SCSI disks; SCSI can schedule multiple, interleaved requests much more intelligently than IDE can.

On the software side, by far the most effective step you can take is to optimize the NFS block size. NFS transfers data in chunks. If the chunks are too small, your computers spend more time processing chunk headers than moving bits. If the chunks are too large, your computers move more bits than they need to for a given set of data. To optimize the NFS block size, measure the transfer time for various block size values. Here is a measurement of the transfer time for a 256 MB file full of zeros.

# mount files.first.com:/home /mnt -o rw,wsize=1024
# time dd if=/dev/zero of=/mnt/test bs=16k count=16k
16384+0 records in
16384+0 records out

real 0m32.207s
user 0m0.000s
sys 0m0.990s

# umount /mnt

This corresponds to a throughput of 63 Mb/s.
Try writing with block sizes of 1024, 2048, 4096, and 8192 bytes (if you use NFS v3, you can try 16384 and 32768, too) and measuring the time required for each. In order to get an idea of the uncertainly in your measurements, repeat each measurement several times. In order to defeat caching, be sure to unmount and remount between measurements.

# mount files.first.com:/home /mnt -o ro,rsize=1024
# time dd if=/mnt/test of=/dev/null bs=16k
16384+0 records in
16384+0 records out

real 0m26.772s
user 0m0.010s
sys 0m0.530s

# umount /mnt

Your optimal block sizes for both reading and writing will almost certainly exceed 1024 bytes. It may occur that, like mine, your data do not indicate a clear optimum, but instead seem to approach an asymptote as block size is increased. In this case, you should pick the lowest block size which gets you close to the asymptote, rather than the highest available block size; anecdotal evidence indicates that too large block sizes can cause problems.

Once you have decided on an rsize and wsize, be sure to write them into your clients’ /etc/fstab. You might also consider specifying the noatime option.

Important points

Hard or Soft Link

Soft mounts cause data corruption, that I have never tried them. When you use hard, though, be sure to also use intr, so that clients can escape from a hung NFS server with a Ctrl-C.

Udp or Tcp Protocol

Most admins usually end up using udp because they use Linux servers, But if you have BSD or Solaris servers, by all means use TCP, as long as your tests indicate that it does not have a substantial, negative impact on performance.

NFS v2 or NFS v3

NFS v2 and NFS v3 differ only in minor details. While v3 supports a non-blocking write operation which theoretically speeds up NFS, in practice I have not seen any discernable performance advantage of v2 over v3. Still, I use v3 when I can, since it supports files larger than 2 GB and block sizes larger than 8192 bytes.

rsize and wsize options in fstab file

See the section on performance tuning below for advise of choosing rsize and wsize.
NFS security is utterly attrocious. An NFS server trusts an NFS client to enfore file access permissions. Therefore it is very important that you are root on any box you export to, and that you export with the insecure option, which would allow any old user on the client box arbitrary access to all the exported files.

Sponsored Link