Question

我试图找到一个解决方案来将二进制文件存储在磁盘上的最小尺寸。我从一个30字节的数据库中读取车辆的VIN和车牌号，当我把它放在一个txt文件中保存时，它的大小是30B，但它在磁盘上的大小是4KB，这意味着如果我节省了100000文件或更多，它会杀死存储空间。

所以我的问题是如何将这个30B写入单个二进制文件到磁盘上最小的大小，以及磁盘上30B的最小可能大小，包括文件名和权限等其他信息？

注意：我不想将这些文本保存在数据库中，只是我想制作单独的二进制文件。

Answer 1

文件的最小大小始终是磁盘的簇大小，通常为4k。对于这样的数据，在单个文件中包含许多记录确实是唯一合理的解决方案。

虽然另一种可能性是将这些文件存储在存档中，例如zip文件。在Windows下，您甚至可以访问与资源管理器中的普通文件非常相似的zip内容。

另一种创造性的可能性：仅将所有数据存储在文件名中。零字节文件在MFT中仅占用1024个字节。（假设是NTFS）

编辑：读取驻留文件，我发现在较新的4k扇区驱动器上，MFT条目实际上也是4k。因此，无论数据大小是否为0，它都不会小于此值。

另一个编辑：包含数十或数十万个条目的大型目录将变得非常笨重。不要试图在资源管理器中打开一个，或者准备好在装载时喝咖啡。

Answer 2

大多数文件系统将磁盘空间分配给块中的文件。除了可能是零长度文件之外，不可能少于一个块。

Google'群集大小'

Answer 3

您应该考虑使用一些索引文件库，如gdbm：它将任意键与某些任意数据相关联。您不会为每个关联花费一个文件（只有一个文件用于所有关联）。

你应该重新考虑你对“数据库”的反对意见。 Sqlite是库，为您提供SQL和数据库功能。还有noSQL 等mongodb个数据库

当然，所有这些都是特定的操作系统和文件系统（但gdbm和sqlite应该适用于许多系统）。

^{AFAIU，您可以配置和使用gdbm和sqlite，以便能够存储数十万个字节，每个条目都非常有效。}

Answer 4

在文件系统上遇到同样的问题。最小的分配大小是一个数据节点，也是一个i节点。例如，IBM JFS2是最小的块大小4k，你有一个要分配的inode。第二个问题是你会在短时间内写出很多文件。它会产生性能问题，在短时间内写入许多inode。

每个写操作都必须进行jornaled和commit。或者你们我们是一个古老而不是jornaled的文件系统。

Idear是，grep许多数据记录器在它们之间放置一个分隔符并在一个文件中写入200-1000。

例如：

0102030400506070809101112131415;;0102030400506070809101112131415;;...

您可以使用文件名索引dem。序号或左右......