数百万个小文件的块大小

我在Debian Wheezy的硬件RAID1中有2个4TB磁盘（可能是LSI MegaRaid）。物理块大小为4kB。我将存储150-200百万个小文件（3到10kB之间）。我并不是在要求性能，而是在寻求最佳文件系统和块大小以节省存储空间。我已经将8200字节的文件复制到块大小为4kB的ext4上。这占用了32kB的磁盘！是记日记的原因吗？那么，有哪些选项可以为此类小文件节省大部分存储空间？

— 拉布德
source

另请参阅：如何确定Linux上ext3分区的块大小？

— 克里斯·S

如果遇到这种情况，我将寻找一个数据库，该数据库可以将所有数据存储在具有紧凑的，基于偏移量的索引的单个文件中，而不是作为单独的文件存储。也许具有FUSE驱动程序的数据库可在必要时作为文件与之交互，而实际上它们并没有成为单独的文件。

或者，您可以看一下文件大小的60％至70％，并尝试将文件大小直接放入文件系统树节点中，而不是作为磁盘上的单独块。在每个节点中存储10k可能是一个很大的问题，但是如果您可以在那里存储60％-70％的文件，那将是一个巨大的胜利。

只有某些文件系统才能做到这一点（reiserfs是其中之一），我想这全都取决于百分位数的大小，以及它是否适合树形结构。您可能可以对其进行调整。我想尝试将其余的块合并为一个块。

不用担心期刊；他们仍然有大小上限。

不，不，不，不，不，不只是...对您的第一段。几年前，我犯了这个错误，以后必须撤消。我也继承了使用此设计模式的系统。如果必须将文件组合在一起，则文件属于SQL Server FileStream对象中的文件系统，或者作为妥协，属于文件系统（因此，可能是FUSE驱动程序，但仍然不是）。在文件系统中工作时，还有其他注意事项，例如不要将400万个文件放在一个文件夹中（我也犯了这个错误）。

— Mark Henderson

@MarkHenderson，但是问题在于定义了什么应该是文件，什么应该是记录。在没有提供更多细节的情况下，成千上万的微小事物听起来更像唱片。仅仅因为他当前将它们作为文件保存，并不意味着它们需要保持这种状态，或者应该一直保持这种状态。另外，我从不建议使用SQL Server来完成工作；）

5年前，我继承了一个系统，该系统在一个文件夹中有100万个文件，每天大约有10,000个新的1-4KB文件。我决定将它们全部放入ISAM表中，因为“嘿，它们只是用于分析的纯文本！” 后来发现这是一个巨大的错误，因为我现在只有一个12GB的表，其中包含成行的行，在处理完这些行后它们几乎什么都不做。因此，我转回基于文件名的GUID将它们放入带有目录文件夹的文件系统中。

— 马克·亨德森2014年

（为什么只有一个12GB的表带有排行，这是一个问题，所以我不在这里讨论）

— Mark Henderson

@MarkHenderson：这不是一个不同的问题，这就是为什么您说这是错误的解决方案（“……大错，因为我现在只有一个12GB的表，有成排的行……。”）您选择了错误的数据库引擎/表格式，但是只要您做对了，就可以用INDEX将很多小东西放到一个文件中的想法是合理的。您想要的是一个数据库，该数据库擅长于具有自动分片功能的数百万个小对象的键/值存储。另请注意，他甚至根本不在乎性能，而只是在乎空间。