为什么“大小”和“磁盘大小”之间有如此大的差异？

如下所示，文件夹中的“ 大小”和“磁盘大小”字段之间有很大差异。这是为什么？

我知道由于Windows中的分配单位，磁盘上的Size应该比Size大一点，但是为什么会有如此大的差异呢？可能是因为文件数量大吗？

顺便说一句，这个文件夹在我的Android手机的SD卡上。在此内部，我的地图应用程序存储了其缓存的地图，并且该应用程序从Google Maps获取其地图。

^{我将假设您在这里使用FAT / FAT32文件系统，因为您提到这是SD卡。NTFS和exFAT在分配单位方面表现相似。其他文件系统可能有所不同，但是Windows仍然不支持它们。}

如果您有很多小文件，这肯定是可能的。考虑一下：

• 50,000个文件。

• 32 kB群集大小（分配单位），这是FAT32的最大值

好的，现在最小占用空间为50,000 * 32,000 = 1.6 GB（使用SI前缀而不是二进制，以简化数学）。每个文件在磁盘上占用的空间始终是分配单元大小的倍数-在这里，我们假设每个文件实际上足够小以适合单个单元，并留有一些（浪费）空间。

如果每个文件的平均大小为2 kB，则总共将获得100 MB的空间-但由于分配单元的大小，平均浪费了15倍（每个文件30 kB）。

深入的解释

为什么会这样？好了，FAT32文件系统需要跟踪每个文件的存储位置。如果要保留每个字节的列表，则表（如地址簿）将以与数据相同的速度增长-并浪费大量空间。因此，他们要做的是使用“分配单位”，也称为“集群大小”。卷被划分为这些分配单元，就文件系统而言，它们不能被细分-这些是它可以处理的最小块。就像您有门牌号码一样，但邮递员并不在乎您有多少间卧室或住在其中的人。

那么，如果文件很小，会发生什么？嗯，文件系统不在乎文件是0 kB，2 kB甚至15 kB，它会为它提供最小的空间-在上面的示例中为32 kB。您的文件仅使用了少量的空间，其余的基本上被浪费了，但仍属于该文件-就像您闲置的卧室一样。

为什么会有不同的分配单位大小？好吧，这是一种权衡取舍，要有更大的桌子（例如通讯录，例如说约翰在假街123号，假街124号，撒旦巷666号等处拥有房屋），或者在每个单元（房屋）中浪费更多的空间。如果文件较大，则使用较大的分配单位更有意义-因为在所有其他文件都填满之前，文件不会获得新的单位（房屋）。如果您有很多小文件，那么无论如何，您都将有一张大桌子（地址簿），因此也可能给他们小的单位（房子）。

通常，如果您有很多小文件，则大的分配单元将浪费大量空间。通常，通常没有充分的理由要超过4 kB。

碎片化？

至于碎片，碎片不应以这种方式浪费空间。大文件可能会被分割成多个分配单元，也就是将其拆分成多个分配单元，但是每个单元都应该在下一个分配单元开始之前被填充。碎片整理可能会在分配表中节省一些空间，但这不是您的特定问题。

可能的解决方案

正如gladiator2345所建议的那样，此时您唯一真正的选择是使用它或使用较小的分配单元重新格式化。

您的卡可能采用了FAT16格式，这对表大小有较小的限制，因此需要更大的分配单位才能处理更大的卷（对于32 kB分配单位，上限为2 GB）。来源由Braiam提供。如果真是这样，您仍然应该能够安全地将其格式化为FAT32。

这是压缩/存档到单个文件中可能会帮助的情况之一。什么鲍勃在他的回答说是真实的，但解决方案可能比reformating盘其他答案建议更容易。如果压缩或存档目录（使用zip，tar或任何其他方法），则文件系统将看到您只有一个大文件，而不是几个较小的文件。即使不进行压缩，您也将获得近1.4 GiB的空间，因为所有这些“小文件”将被计为一个大文件。

在此内部，我的地图应用程序存储了其缓存的地图，并且该应用程序从Google Maps获取其地图

也许您应该与开发人员讨论使用存档或数据库而不是多个文件。这可能也将有助于减少磁盘碎片，并肯定会节省空间，特别是如果它是NAND闪存驱动器。如果您解释了100MB有效负载/有用数据变为1.4GiB的荒谬情况，则数据的存储方式存在问题，开发人员应提出更好的解决方案。

万一有人遇到此问题，知道另一个在磁盘上的文件大小/空间有很大差异的另一个原因可能是有用的，即使用备用数据流（ADS）

据我所知，这仅适用于NTFS。ADS既有合法用途，又有不合法用途：

• 将文件标记为从Internet下载
• 存储元数据（Microsoft希望包括某些Apple OS功能，例如不使用文件扩展名来确定文件类型）
• 隐藏恶意软件中的数据或代码。

简单地使用ADS：任何NTFS文件都可以容纳多个数据流（理解“子文件”）。一个是主流，由Windows资源管理器和其他Windows工具使用，它包含文件的常规内容。备用数据流可能包含与主流完全相同的其他信息，但是Windows工具无法直接处理它们（特别是资源管理器将文件大小显示为等于主流的大小，而与ADS的大小无关），您必须使用专门的工具或代码来编写，读取和定位ADS。

要点是，如果观察到较大的文件大小差异，请不要忽略ADS和隐藏的恶意软件的可能性。

另一个环节。

为了安全地试用ADS，请在DOS / CMD级别上尝试此操作...

创建并在C的根目录中显示文件的内容：

C:\> echo The main data stream> test.txt
C:\> type test.txt

结果：

C:\> The main data stream

现在，使用相同的方法添加ADS，只需在文件名之外指定ADS名称即可：

C:\> echo The secret message> test.txt:secret

您刚刚将秘密消息隐藏在文件中。请注意，尽管我们在ADS“秘密”中添加了字节，但资源管理器中的文件大小并未更改。

尝试显示ADS内容：

C:\> type test.txt:secret

结果：

The filename, directory name, or volume label syntax is incorrect.

CMD type无法显示ADS的内容。我们将改用记事本：

notepad test.txt:secret

在记事本中，我们可以看到ADS的内容：

The secret message

您也可以将完整的可执行文件隐藏在纯文本文件的ADS中，然后随时运行它。财富对黑客无害：-)

问题可能是由于群集大小。

根据微软的说法：

如果您不对卷中包含的任何文件或文件夹使用NTFS压缩，则SIZE和SIZE ON DISK之间的差异是浪费的空间，因为群集的大小超出了必要。您应尝试使用最佳群集大小，以使SIZE ON DISK值尽可能接近SIZE值。SIZE ON DISK和SIZE值之间的差异过大表示默认群集大小对于卷上存储的平均文件大小而言太大，应该减小它。只能通过备份该卷，然后使用format命令和/ a开关来指定适当的分配大小来重新格式化该卷，以完成此操作：IE ：（format D: /a:2048 此示例使用2 KB群集大小）。

尝试使用较小的群集大小格式化驱动器。

我看到许多人建议使用较小的群集大小重新格式化驱动器。由于这是SD卡，因此请注意，许多供应商都将卡预格式化为建议的群集大小，以与NAND群集大小相匹配（保持同步对于获得最佳的读/写性能和减少磨损非常重要）。

您无法更改NAND的群集大小（这是SD卡硬件的物理属性）。

首先在SD卡上运行scandisk / chkdsk，以确保大小报告问题不存在于损坏的文件系统中。

其次，建议您将错误报告给Google Map开发人员，因为这是他们的责任。他们应该使用更好的存储方法。修复它还应该使该应用程序在I / O和文件系统的驱动程序活动较少的情况下在许多设备上更快地运行。

这是许多文件系统的普遍问题。这里有两个因素在起作用，文件系统每个逻辑卷可以处理的“块”的最大数量以及存储介质的物理限制。只能将1个文件分配给任何给定块（文件通常占用所需数量的块）。因此，具有64个字节的文本文件通常可以占用4k至32k的任何空间，具体取决于其所在文件系统的块大小。

考虑这种情况的一种方法是将文件系统中的每个块视为一个盒子，将文件系统视为一个房间。您所有的盒子都一样大小，并且您要尽可能地容纳一个房间。如果将它们全部容纳而剩下更多空间，则必须获得更大的盒子，以便房间完全充满盒子。

将物品放入盒子的规则之一是您不能将两个无关的物品放入盒子。它们必须是同一文档的一部分。因此，如果我要键入一页文字，它将有它自己的框。如果我输入的文字有太多页面，我无法将所有内容都放在一个盒子中，那么我会简单地找到另一个盒子，然后继续放置页面，重复一次，直到将所有页面归档为止。我还要写下用于该文档的框以及按顺序读取框的顺序。

根据我整理箱子的方式，清单中可能只有足够的空间容纳一定数量的箱子。因此，如果我有一个大房间要装满，但只有少量的箱子，我将不得不使用非常大的箱子才能达到房间的容量。

因此，在那种情况下，我的一页文档仍将占据一个框，没有其他共享框。

在各种存储解决方案中也会出现相同的情况。FAT32仅能管理当今巨大的硬盘驱动器上很少的“盒子”，因此它最终以非常大的“盒子”来弥补。

除群集大小外，由于以下情况，您可能还会出现差异：

• 压缩或加密的文件可能会占用与逻辑文件大小不同的空间。
• 链接文件将报告n倍于链接数乘以文件大小得出的逻辑文件大小，但是通常使用的物理空间会更少。

您应该查看Wikipedia中的“块子分配”条目。这就是你正在发生的事情。使用文件系统支持尾包包装是解决此问题的文件系统级解决方案，除了更改分配群集的大小。

所有这些都有需要重新格式化磁盘的不便之处。

在某些情况下，仅将这些文件存储在存档中即可解决此问题（小文件除了在文件末尾停止丢失空间外，还将被压缩）。这花费了一些时间进行减压的不便。

如果由于某些与应用程序相关的特定问题而导致文件太多，则另一个选择是使用另一种方法（可能在数据库中）存储软件数据。但这当然是针对程序员而非最终用户的解决方案。

http://en.wikipedia.org/wiki/Tail_packing

我注意到单个文件在Windows 10中存在巨大的文件大小差异，但是如果从Windows XP的同一位置（网络驱动器）查看SAME文件的属性，则不会存在较大差异；只是很小的差异，这就是您所期望的。我认为Windows 10中存在一个错误。一个449MB的文件可能不会占用3.99GB，这就是Windows 10告诉我的。