Western Digital Green 驱动器从 512 字节扇区（跳线）到 4k 字节扇区（去除跳线）

Question

我使用的是 WD20EARS 驱动器，其引脚 7 和 8 跳线，以便在不支持 4k 扇区的操作系统上使用它。但是现在，我想将该硬盘驱动器转移到具有 4k 扇区支持的操作系统。

我移除了跳线，将其连接到 Windows Server 2008 R2，并执行了快速格式化。但是，DiskCheckup仍将“每个扇区的字节数”属性报告为 512。

为了将此驱动器用作 4k 扇区驱动器，我还需要做什么？

Answer 1

我认为这是正确的行为。4k 磁盘在接口端仍报告 512 字节扇区。尽管它们在内部以 4k 块的形式寻址扇区。

大多数驱动器中的跳线只是启用扇区移位。在大多数驱动器上，它将扇区寻址移动 1。原因是像 Winodws XP 这样的非 4k 感知操作系统。为了理解您需要知道 Windows XP 确实创建了从扇区 63 开始的第一个分区（是的，这不是错字）。

在大多数情况下，Windows 将使用具有 4k 分配单元（NTFS 群集）的文件系统。因此，您会假设当您从传统驱动器读取 NTFS 群集时，它只需要读取 8 个物理块。非常简单。

现在驱动器也将使用 4k 扇区大小。这完全没问题，因为操作系统永远不会读取小于 4k 的集群，因为这是最小的分配单元（假设您在格式化期间没有强制使用较小的 FS 集群）。正如我写的那样，出于兼容性原因，驱动器仍然在接口级别公开 512 字节扇区。但是，如果您只读取一个 512 字节的块，那么驱动器内部无论如何都会读取一个 4k 扇区，然后将其拆分为仅通过电缆接口发送 512 字节。

那么现在问题出在哪里呢？###

Windows XP 的问题在于，默认情况下分区与块 63 对齐。这会导致 NTSF 簇与物理块的错位。我创建了一个小图片来说明这一点：

正如您在 Windows XP 上的图片中看到的，逻辑集群没有与物理 4k 块对齐。因此，如果 Windows 读取逻辑 NTFS 群集，它需要驱动器读取两个块，而不仅仅是一个。更糟糕的是，如果您只需要一个 NTFS 集群，它会读取两个扇区，并且必须合并它们以便仅将请求的数据返回给操作系统。

对于写操作，情况更糟。在这种情况下，驱动器必须读取两个物理 4k 扇区，然后将它们的内容与新 NTFS 群集的内容合并，然后才能将两个扇区保存回磁盘。这意味着不仅仅是通过覆盖来替换 HDD 上的扇区，驱动器必须读取 8k，合并到缓冲区中并写入 8k。这会大大减慢写入操作的速度。

为了防止不必要的合并硬盘制造商添加了一个“兼容性”黑客，可以通过跳线启用。它只是将每个 512 字节的扇区地址加 1。因此，Windows 创建的第一个分区将从扇区 64 开始，映射如下所示：

现在，对逻辑 4k NTFS 块的任何读/写都会导致完全读/写一个物理扇区。

当然，如果您已经创建了与 4k 扇区边界对齐的分区，则根本不需要这种变通方法。例如在 Linux 上，您可以简单地使用fdisk来定义您的分区从哪个块开始。因此，在这里使用 8 的乘法是个好主意。

自 Vista 以来，Windows 将在扇区 2048 AFAIR 处启动第一个分区。所以这里不再出现这个问题。

警告：如果您仍然在支持 4k 的操作系统（如 Vista、Win7 或 Win2k8 R2）上使用跳线变通方法，那么这实际上可能会破坏扇区对齐。原因是驱动器将再次将扇区地址增加 1，导致第一个分区与扇区 2049 对齐，这再次导致严重的性能下降。

因此，如果您使用的是支持 4k 的操作系统，请确保在对驱动器进行分区之前移除跳线。在您的特定情况下，我认为只要您在移除跳线的情况下重新分区驱动器，一切都应该没问题。格式化驱动器与扇区对齐和 4k 寻址无关。在格式化过程中唯一应该确保的是，不要使用小于 4k 的簇大小，因为 2k NTFS 簇只会导致要求仍然为来自操作系统的每个 HDD 访问读取完整的 4k 扇区。顺便说一句：使用 8k NTFS 集群仍然完全可以，因为磁盘会为每个 NTFS 读/写操作简单地读取 2 个扇区。