我在HP ML370 G5，Smart Array P400，使用RAID 1 + 0组合的SAS磁盘上使用Openfiler 2.3。
我使用Openfiler的基于Web的configuration从ext3分区设置了一个NFS共享，并且我成功地从另一个主机装载共享。 两台主机都使用专用的千兆链路连接。
使用dd简单基准：
$ dd if=/dev/zero of=outfile bs=1000 count=2000000 2000000+0 records in 2000000+0 records out 2000000000 bytes (2.0 GB) copied, 34.4737 s, 58.0 MB/s
我看到它可以达到中等传输速度（58.0 MB /秒）。
但是，如果我复制一个包含许多小文件（ .php和.jpg ，每个文件约1-4 kB）的总大小为300 MB的目录，则cp过程将在大约10分钟内结束。
NFS不适合像上面那样的小文件传输？ 还是有一些参数需要调整？
传输大量小文件总是比传输单个大文件要慢许多原因。 对于阅读而言，文件更可能分散在磁盘周围，需要到处找寻。 正如Evan所提到的那样，在NFS（或其他任何文件系统）的情况下也涉及元数据，这也使事情变得复杂。
您可以尝试增加您的rsize和wsize参数到NFS挂载，看看这是否会有助于性能。 另外检查这个问题在调整NFS最小延迟，因为它有很多有用的build议，这将有助于在许多小文件传输的情况下。
我没有很多NFS的经验，但是我对其他networking文件共享协议的经验表明，几乎普遍存在“很多小文件”情况下的性能。 你会产生往返延迟，以及一大堆延迟加起来的文件。
你有没有尝试过不同的文件系统，如XFS？ 它解决了所有我的问题，当进行大量的小型iSCSI块传输。 不知道为什么。
此外，iSCSI / NFS通常configuration为非常大的dataframe（巨型帧等），如果您一次只复制一个小文件，可能会伤害到您。 也许tar'ing，然后转移将帮助你。
检查你使用的是TCP连接（ mount -t nfs -o tcp host：/ mount / target ）。 在现代系统上的性能不会受到影响，但是如果你的networking被加载的话，小的IO可能会有显着的提高。
你也应该尝试一些其他的文件系统; ext3基本上是最慢的。 它是稳定的，众所周知的，但它是不适合文件服务器。 XFS更好，而且在小IO上reiserfs也好多了。
只是为了增加Evan的答案，你也有为每个你正在复制的文件创build元数据（目录条目等）的所有开销。
如果要通过NFS传输小文件的大目录树，并且可以login到服务器，最好的方法是制作一个在客户端上自动提取的tar文件，如下所示：
tar c mydirectory | ssh user @ host tar -xf – -C destdir
这样，只有一个“文件”通过networking传输，并且您立即拥有主机上的所有文件。
克里斯的答案类似的解决scheme是将您的文件定期rsync到客户端。 如果您想要进行双向更改，您也可以使用同一性。