Next Previous Contents

4. Setting up a NFS client

First you will need a kernel with the NFS file system either compiled in or available as a module. This is configured before you compile the kernel. If you have never compiled a kernel before you might need to check the kernel HOWTO and figure it out. If you're using a very cool distribution (like Red Hat) and you've never fiddled with the kernel or modules on it (and thus ruined it ;-), nfs is likely automagicaly available to you.

You can now, at a root prompt, enter a appropriate mount command and the file system will appear. Continuing the example in the previous section we want to mount /mn/eris/local from eris. This is done with this command:


mount -o rsize=1024,wsize=1024 eris:/mn/eris/local /mnt

(We'll get back to the rsize and wsize options.) The file system is now available under /mnt and you can cd there, and ls in it, and look at the individual files. You will notice that it's not as fast as a local file system, but a lot more convenient than ftp. If, instead of mounting the file system, mount produces a error message like mount: eris:/mn/eris/local failed, reason given by server: Permission denied then the exports file is wrong, or you forgot to run exportfs after editing the exports file. If it says mount clntudp_create: RPC: Program not registered it means that nfsd or mountd is not running on the server. Or you have the hosts.{allow,deny} problem mentioned earlier.

To get rid of the file system you can say


umount /mnt

To make the system mount a nfs file system upon boot you edit /etc/fstab in the normal manner. For our example a line such as this is required:


# device      mountpoint     fs-type     options              dump fsckorder
...
eris:/mn/eris/local  /mnt    nfs        rsize=1024,wsize=1024 0    0
...

That's all there is too it, almost. Read on please.

4.1 Mount options

There are some options you should consider adding at once. They govern the way the NFS client handles a server crash or network outage. One of the cool things about NFS is that it can handle this gracefully. If you set up the clients right. There are two distinct failure modes:

soft

The NFS client will report an error to the process accessing a file on a NFS mounted file system. Some programs can handle this with composure, most won't. I cannot recommend using this setting, it is a recepie for corrupted files and lost data. You should especially not use this for mail disks --- if you value your mail that is.

hard

The program accessing a file on a NFS mounted file system will hang when the server crashes. The process cannot be interrupted or killed unless you also specify intr. When the NFS server is back online the program will continue undisturbed from where it were. This is probably what you want. I recommend using hard,intr on all NFS mounted file systems.

Picking up the previous example, this is now your fstab entry:


# device      mountpoint     fs-type    options                  dump fsckorder
...
eris:/mn/eris/local  /mnt    nfs        rsize=1024,wsize=1024,hard,intr 0 0
...

4.2 Optimizing NFS

Normally, if no rsize and wsize options are specified NFS will read and write in chunks of 4096 or 8192 bytes. Some combinations of Linux kernels and network cards cannot handle that large blocks, and it might not be optimal, anyway. So we'll want to experiment and find a rsize and wsize that works and is as fast as possible. You can test the speed of your options with some simple commands. Given the mount command above and that you have write access to the disk you can do this to test the sequential write performance:


time dd if=/dev/zero of=/mnt/testfile bs=16k count=4096

This creates a 64Mb file of zeroed bytes (which should be large enough that caching is no significant part of any performance perceived, use a larger file if you have a lot of memory). Do it a couple (5-10?) of times and average the times. It is the `elapsed' or `wall clock' time that's most interesting in this connection. Then you can test the read performance by reading back the file:


time dd if=/mnt/testfile of=/dev/null bs=16k

do that a couple of times and average. Then umount, and mount again with a larger rsize and wsize. They should probably be multiples of 1024, and not larger than 16384 bytes since that's the maximum size in NFS version 2. Directly after mounting with a larger size cd into the mounted file system and do things like ls, explore the fs a bit to make sure everything is as it should. If the rsize/wsize is too large the symptoms are very odd and not 100% obvious. A typical symptom is incomplete file lists when doing 'ls', and no error messages. Or reading files failing mysteriously with no error messages. After establishing that the given rsize/wsize works you can do the speed tests again. Different server platforms are likely to have different optimal sizes. SunOS and Solaris is reputedly a lot faster with 4096 byte blocks than with anything else.

Newer Linux kernels (since 1.3 sometime) perform read-ahead for rsizes larger or equal to the machine page size. On Intel CPUs the page size is 4096 bytes. Read ahead will significantly increase the NFS read performance. So on a Intel machine you will want 4096 byte rsize if at all possible.

Remember to edit /etc/fstab to reflect the rsize/wsize you found.

A trick to increase NFS write performance is to disable synchronous writes on the server. The NFS specification states that NFS write requests shall not be considered finished before the data written is on a non-volatile medium (normally the disk). This restricts the write performance somewhat, asynchronous writes will speed NFS writes up. The Linux nfsd has never done synchronous writes since the Linux file system implementation does not lend itself to this, but on non-Linux servers you can increase the performance this way with this in your exports file:


/dir    -async,access=linuxbox

or something similar. Please refer to the exports man page on the machine in question. Please note that this increases the risk of data loss.


Next Previous Contents