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