What is the performance and data transfer rate of NFS gateways? How does DiskShare performance compare with competing products? These are simple and fair questions to ask. But the answer may not be simple, because there are to many variables in the network configuration which impact the performance and data transfer rate. The performance and transfer rate are affected by things such as:

• Reads or Writes, they perform differently
• copying directory trees of small files
• copying large files or testing I/O with a program
• What application is being used to intiate the file transfer
• The Windows OS, Service Pack and fixes
• Amount of memory in the Windows system
• Fragmentation, cluster size of the Windows partition that is being accessed
• Tuning of the Windows OS
• Network card used in the Windows machine
• What other Applications are running on the Windows machine
• OS and version running on the Client
• memory in the Client
• network card in the Client
• Network hardware between the Client and Server
• Network load outside of NFS
• tuning of the OS on the Client
• version of the NFS modules on the Client
• NFS tuning on the Client
• ….

This list could get much longer but you get the idea.

NFS Performance Tests and Results

Tests are done and presented by Dr. Jack Fegreus, Technology Director of Strategic Communications, on the performance of a few leading NFS gateway and CIFS products: NFS/DiskShare, NFS/SFU and CIFS/SAMBA. All of the disk volumes that the Windows server would export via NFS/DiskShare, NFS/SFU, and SAMBA/CIFS were created on a Fibre Channel nStor 4520 Storage System. In creating the logical devices, the key was to maximize streaming throughput and not random access as databases are not good candidates for NFS. He ran directory- and file-based read and write tests on all of the shared volumes. In these tests, he ran normal copy and backup operations rather than our optimized benchmarks to better simulate the performance an end user would encounter. He measured Ethernet-based data throughput to and from our client system and Fibre Channel-based data throughput to and from the nStor Server System. This provided an overall perspective of performance at all points of the process.

NFS throughput averaged about 48MB per second versus 25MB per second with Samba. This was mirrored precisely at the back end where we were able to measure data throughput more accurately. Equally interesting, we observed far greater variation in instantaneous throughput using NFS. The highest instantaneous throughput was measured with NFS accessing a volume exported via DiskShare. In this case throughput often reached peaks of 80MB per second. Average overall throughput at the backend, however, was identical. Measured at the front end as Ethernet traffic at the client, however, SFU had a consistent 5% advantage in throughput. He postulate that SFU might be gaining that very slight advantage through its handling of the NT cache.

The following are some specific results based on a few scenarios:

1. Measure data throughput performance reading files and directories at the client server. Reading files, NFS demonstrated a 2-to-1 advantage and SFU shares held a 5% edge over DiskShare.

2. In addition to measuring data throughput on reads at the client, we measured backend disk throughput for the Windows server coming from the FC disk array. While Ethernet-based client I/O exhibited an edge for SFU, overall backend throughput for DiskShare and SFU was virtually identical.

3. File and directory writes proved to be a serious problem for NFS with SFU shares. For most of the data transfer process, directory writes proceeded at a glacial 3-to-5MB per second.

Conclusion

After many tests, Dr. Jack Fegreus concluded that for Gigabit Ethernet server-to-server file I/O traffic between UNIX/Linux servers and Windows Server 2003, the performance choice is to put NFS on Windows rather than utilize CIFS (SAMBA). When it comes to putting NFS on Windows there are then two choices: Microsoft Services for UNIX (SFU) and DiskShare.

For ease of installation and configuration, however, there is only one choice. While we encountered no problems setting up file sharing with DiskShare, a number of critical issues surfaced with SFU. The problems were amplified by the consistent behavior to simply fail without providing any feedback. In particular we encountered such incidents when mapping multiple Linux users to the same Windows user and when using NIS without a Windows domain. Equally troubling was the inability to provide root access while using NIS. Write performance with NFS shares via SFU was abysmal. Writing files was considerably slower when using an SFU share. Writing directory trees often crawled at 3MB per second.

On the other hand, write performance using a DiskShare exported volume was at a par with CIFS exported volumes. More importantly, read throughput was twice that of the CIFS share accessed with Samba. As a result, we were able to backup the Windows server over NFS/DiskShare mounts without special client software at a throughput rate that rivaled the throughput of local files.