What effect does using a larger NFS block size do? Obviously, the larger block sizes are only available on 64-bit. Does the NFS block size affect SMB?
Printable View
What effect does using a larger NFS block size do? Obviously, the larger block sizes are only available on 64-bit. Does the NFS block size affect SMB?
We support 1MB NFS block size and not for SAMBA (SMB).
Some good point for NFS concerning your question.
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,nos uid 0 0
195.12.32.2:/usr /usr nfs ro,rsize=8192,hard,intr,nfsvers=3,tcp,noatime,node v,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.
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.
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, your data does 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
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.