如果要在共享的 nfs 文件系统上访问深层目录，我正在尝试找出大型目录结构的性能。结构过于庞大，有 4 级嵌套目录，每级包含 1024 个目录。（根目录中的 1024，给定子目录中的 1024，依此类推）。
该文件系统将位于用户将访问以获取其个人信息的网络存储库上。数据将被复制到多台服务器上并进行负载平衡，但每台机器在任何时候都会有不错的负载。
如果第 4 级包含用户正在寻找的信息，性能会有多差？如果所有人都在访问不同的子目录？这可以通过缓存 inode 信息来解决吗？
我已经对此进行了一段时间的搜索，但我主要是在查找有关大文件而不是大型目录结构的信息。
我曾经在工作中这样做过。不记得确切的数字，但我认为它有 8 层深，每层有 10 个子目录（用户 id 87654321 映射到目录 8/7/6/5/4/3/2/1/。结果是不是一个好主意，开始遇到文件系统 inode 数量限制的问题，iirc（10^10 = 10000000000 个目录，不好）。切换到每个级别的子目录更多，级别更少；问题消失了。您的情况听起来更易于管理，但仍然要检查您的文件系统是否支持您预期的文件和目录计数类型。
这里的答案将高度依赖于您的操作系统，您能否提供更多信息？我发现 Linux 下的文件打开时间在几万个目录大小下是合理的，但我没有尝试过任何与你一样大的目录结构的测试（你知道 1024 的四次方是 1,099,511,627,776 对？那是地球人口的180倍，对吧？）
似乎您只想编写一个测试应用程序来生成 1024 个文件夹，向下迭代 8 个级别，每个文件夹包含一些（100 - 1000 个？）大小为 1KB 的文件，然后随机查找并访问这些文件。
跟踪多次通过的访问时间，看看它是否符合您的要求。