Testing for Saturated Network for NFS

How do we test for saturated network for NFS. Is there a systematic way of doing it? You can read my Linux Cluster blog entry Testing for Saturated Network for NFS

NFS share on Linux client not immediately visible to other NFS clients

If you are using NFS as the shared file system, you may encounter this issue where NFS share on Linux client not immediately visible to other NFS clients. This is due to caching parameters which you must take note of on the NFS Client side. These are

1. acregmin=n. The minimum time (in seconds) that the NFS client caches attributes of a regular file before it requests fresh attribute information from a server. The default is 3 seconds.
2. acregmax=n. The maximum time (in seconds) that the NFS client caches attributes of a regular file before it requests fresh attribute information from a server. The default is 60.
3. acdirmin=n. The minimum time (in seconds) that the NFS client caches attributes of a directory before it requests fresh attribute information from a server. The default is 60
4. acdirmax=n. The maximum time (in seconds) that the NFS client caches attributes of a directory before it requests fresh attribute information from a server. The default is 60
5. actimeo=n. When you wish to sets all of acregmin, acregmax, acdirmin, and acdirmax to the same value.

For more information, see

1. Configuring NFS Client for Performance
2. Why are changes made on an NFS share on my Red Hat Enterprise Linux 5 client not immediately visible to other NFS clients?

NFS and "Permission Denied" Mount Problem at the Client

I've encountered a strange issue with the NFS mount today.

1. On the LINUX Client
# mount /nfs-server
mount: xxx.xxx.xxx.xxx:/nfs-server failed,
reason given by server: Permission denied

We have checked the permission on the nfs-server:/etc/exports and everything is correct. We did a:

# showmount -e nfs-server
Everything was correct too and seem correct. If we do a "rpcinfo -p", it also show correct information
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 615 status
100024 1 tcp 618 status
100021 1 udp 32771 nlockmgr
100021 3 udp 32771 nlockmgr
100021 4 udp 32771 nlockmgr
100021 1 tcp 37569 nlockmgr
100021 3 tcp 37569 nlockmgr
100021 4 tcp 37569 nlockmgr

On the Server side,
We check the /etc/exports and everything is correct. Next we restarted the NFS and the Portmap Services. But the Clients still show the "Permission Denied" Error

We noticed that the /proc/mounts/ did not have the NFS Information. To resolve this issues, we have to manually add NFS information inside the /proc/mounts
nfs-server:/home /home nfs rw,vers=3,rsize=8192,wsize=8192,hard,intr,proto=tcp,timeo=14,retrans=2,sec=sys,addr=n00 0 0

We did the NFS Mount and everything was working!


Related Articles:

• Linux NFS and "Permission denied" mount problem

NFS Performance Tuning

According to an article by NFS Performance Tuning by Ben Martin, adding a async parameter in the NFS mount in fstab. Tested on Fedora 9

fileserver:/home /home nfs async,rsize=8192,wsize=8192,intr 0 0

According to the article, using async will cause the speed of the NFS mount to be close to actual local disk speed. Furthermore, you can increase the buffer size of rsize and wsize from the default 4096 to 8192

intr - allow signal to interrupt file operation especialy if it is hard-mounted
hard - by default

Articles on Parallel NFS

A good series of articles for reading on pNFS which hold promises for those who like the user-friendly NFS protocols and need the Intensive I/O requirements bveyond what the traditional NFS can offer

1. Scale your file system with Parallel NFS (IBM DeveloperWorks)
2. pNFS.com (Information on Parallel NFS)
3. NFSv4 delivers seamless network access (IBM DeveloperWorks)

Network design consideration for NFS

Network Design are an important consideration for NFS. Often we miss the infrastructure design consideration of NFS. Read further at Network design consideration for NFS