服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

XFS上的高目录 – 文件比率的影响

我们正在构build一个可能会产生非常大的XFS卷的产品,并且我正试图发现在给定架构的情况下我们可能遇到的扩展瓶颈。 当我们操作文件时,它们被放置在XFS卷上的目录中。 由于我们处理的文件数量众多,文件数量肯定在数千万之内,而且在发布之后太久之前可能会达到数亿。 我们知道这是因为我们目前的产品是这样的,所以期待我们的下一个产品是类似的。 因此,正确的早期工程是有序的。 本周这些文件基于以下粗略布局: $ProjectID/$SubProjectID/[md5sum chunked into groups of 4]/file 其中给出了这样的目录: 0123456/001/0e15/a644/8972/19ac/b4b5/97f6/51d6/9a4d/file 分块md5sum的原因是为了避免“一大堆文件/目录在一个目录中”的问题。 由于md5sum分块,这意味着1个文件导致8个目录被创build。 这对inode有着非常明显的影响,但我不清楚一旦我们达到规模,对XFS的影响会是什么。 有什么影响? 顺便说一下,这是内核2.6.32,目前CentOS 6.2(如果需要可以更改)。 在testing中,我已经创build了默认的xfs卷,并没有使用任何安装选项。 这是为了早日排除问题。 因为我们不需要它,所以noatime是一件简单的事情。 总体来说,XFS调整是我需要解决的另一个问题,但现在我担心我们现在devise的元数据乘数效应。 我已经知道一个更好的解决scheme将是什么,我只是不知道是否有案件推动改变。 由于md5sums在第一个数字中是非常独特的,单个子项目很less超过500万个文件,所以在我看来,我们只需要前两个数据块。 这将产生如下的布局: 0123456/001/0e15/a644/897219acb4b597f651d69a4d/file 完全完整的第一级和第二级将在每个第一级目录中具有2 16个第一级目录和2 16个第二级目录,卷上总共有2 32个目录。 因此假设的5百万个文件子项目因此将具有2 16个第一级目录,每个大约76(+/- 2)个二级目录以及每个第二级目录中的一个或两个第三级目录。 这种布局有更多的元数据效率。 我只是不知道是否值得努力改变现在的情况。