自 Windows 3.1 以来，我可能已经安装了数千次 Windows。我忘记了Win 3.1的情况，但是从Windows 95开始，Windows从来没有尊重过分区大小的现实，今天又发生了，我想也许这里有人可以启发我......
例如，当我有一个新擦除的硬盘时，Windows 会询问我希望新系统分区的大小（以 MB 为单位），因此，在这种情况下我想要 64 GB，我输入 65536 ... 正好是 64 GB，正确的？错误的！...一旦您这样做，Windows 就会报告新的分区大小为 63.9 GB。
微软是否一直在对我们开了 20 多年的恶作剧？...或者，Microsoft 将 Windows 中的 65536 MB 报告为 63.9 GB 而不是 64 GB 是否有充分的理由？
这不是要知道的最重要的问题，但我很想知道是否有人有一个好的答案，因为它让我很长时间摸不着头脑（如果这可以通过 NTFS 表占用一些空间或什么，你会说什么是让 Windows 设置 64 GB 驱动器的正确方法）？?
您的试错法是一个好主意，但与其查看仅显示冗长数字的前导数字的位置，不如查看分区/卷的属性，您可以在其中找到以字节为单位的确切长度。该信息对您尝试以迭代方式接近目标大小的方法更有帮助。
使用 Windows 7（64 位）时，我会看到确切的字节大小和基于前导数字的缩写数字，这似乎与 Windows 资源管理器中显示的数字相对应。显然，您正在查看的缩写数字不是确定实际长度的好方法！
为什么要反复试验？
运行试错策略的原因是 Windows 格式化行为可能会随着时间而改变。
磁盘几何首先影响分区
最初，受 MBR 分区表中旧的 CHS（柱面、磁头、扇区）概念的影响，如果我没记错的话，Windows XP 总是尝试将分区开始放置在柱面 (x,0,1) 的开头。
高级格式现在影响分区
随着真正的物理扇区大小为 4096 字节（高级格式）和 512 字节的逻辑模拟（在接口处）的到来，旧的格式化策略导致不对齐，导致分区从 512 字节的倍数开始，这总是在逻辑扇区的开头，但不一定在大小为 4096 字节的物理扇区的开头。这种与物理扇区大小有关的错位导致写入时可避免的磨损和减速。后来的微软操作系统必须以不同的方式分配分区空间以避免这种情况。
某些 linux 操作系统中的 Gparted 分区工具可以选择以 MB 的倍数分配空间（不知道这是一个 10^6 数字还是 2^20 字节）。也许使用 pendrive linux 可以帮助您匹配您的格式化目标。
请阅读以下文章以了解尺寸条款带来的混乱：
https://en.wikipedia.org/wiki/Binary_prefix#gibi