在过去的几年里，NFS一直在为我工作，但是现在我面临一个性能问题，我实际上找不到解决scheme。
我的问题是，在NFS服务器上，我有大约5Gb的小文件，而从客户端，我做一个“ls”或“杜”进入挂载的目录，可能需要超过2分钟列出所有的文件。
我认为这个问题是由于每个文件都会发送NFS文件的统计信息，等待响应，然后发送一个新的查询文件。 如果是这样，我很确定这是什么原因造成我的糟糕的性能问题。
现在，我试图寻找一个解决scheme，但我没有设法find一个，所以我决定打开这个线程。
您是否有任何想法可以解决我的性能问题？
非常感谢一个Linux系统pipe理员padawan。
我的感觉是，这个问题不是特定于NFS的。 从历史上看，UNIX文件系统通常在包含大量文件的平面目录中存在问题。 当然，我之前被告知的经验法则是，性能随着目录文件大小的平方而降低。 正如你指出的，做一个ls -la意味着stat每个inode，并且一旦目录文件开始增长，这需要很多时间。 由NFS添加的延迟会加剧这种情况，但这只会给您的注意力带来潜在的问题，而不会造成这种情况。
正如我不断地告诉我的开发者，解决scheme并不是将大量文件存储在浅而宽的结构中，而是存储在狭窄，深层的文件中。
看看现有的实用程序如何在存储多个文件时存储文件： yum在/var/lib/yum/yumdb下创build了许多文件，因此通过引导初始值将它们存储在子目录中：
drwxr-xr-x. 4 root root 4096 Sep 9 2011 C drwxr-xr-x. 3 root root 4096 Sep 9 2011 M drwxr-xr-x. 3 root root 4096 Jul 13 10:05 S drwxr-xr-x. 24 root root 4096 Jul 13 10:05 a drwxr-xr-x. 18 root root 4096 Nov 7 11:10 b [c through y omitted to save space] drwxr-xr-x. 5 root root 4096 Dec 28 2011 z
Squidcaching在使用squid -z进行初始化时，会生成/var/spool/squid/0[0-F] ，并在每个子目录下创build子目录./[0-F][0-F] 。 innd拉类似的技巧，如果内存服务，当它不使用环缓冲区types的文件结构。 所有这些守护进程和其他许多类似的守护进程都知道，如果他们需要存储大量的小文件，那么有一组深层的子目录来存储它们对于高效操作是非常重要的 。
编辑 ：1s是一个很长的时间来做一个ls在一个单一的本地目录。 正如我所说，我认为NFS延迟加剧了您的问题; 但对这个问题不负任何责任，只是为了让它大到让你悲伤。