这是Linux NFS客户端缓冲区吗？

在NFS挂载(具有古老的2.6.18内核的RedHat 5.6上的标准选项)中,在我看来,大写和多写操作会延迟较小的读操作.例如,如果同时运行cp或dd,则在目录中执行简单的ls将花费几秒(或几分钟).
这个问题有点缓解,因为 Linux缓存元数据几秒钟,但是当要写入大量数据时,NFS挂载变得无法使用.

起初我虽然这只是一个NFS服务器问题,但运行如下：

for((i=0; i<60; i++)) do
  strace -f -t -o strace.$i.log time stat /mnt/nfs/data > out.$i.log 2>&1
  sleep 1
  if ((i == 30)); then
    dd if=/dev/zero of=/mnt/nfs/data bs=1M count=1000 &
  fi
done

wait

并行的tcpdump告诉我以下内容：

1)每当dd开始时,执行缓存未命中的下一个统计信息需要15秒

23261 16:41:24 munmap(0x2ad024d0e000,4096) = 0
23261 16:41:24 lstat("/mnt/fermat_emctest/data",{st_mode=S_IFREG|0600,st_size=1048576000,...}) = 0
23261 16:41:40 open("/proc/filesystems",O_RDONLY) = 3

2)tcpdump显示当dd正在运行并且发出WRITE调用时,不会发送单个GETATTR.
鉴于RPC是异步的,我本来希望看到GETATTR调用与WRITE多路复用,但事实并非如此.
GETATTR不是很慢(提交时需要几个我们),它是在所有WRITE之后排队的内核.

这就是为什么stat需要很长时间,因为它等待内核提交GETATTR调用.

我对吗 ？
这看起来像一个bufferbloat问题,内核正在挨饿我的stat,因为这个mount(服务器？)的客户端操作队列已满.

我认为这与我的其他问题How to achieve multiple NFS/TCP connections to the same server?有某种关系.

有没有办法调整内核NFS操作队列？