4 KB 扇区磁盘上的 Linux：实用性建议

4 KB 扇区磁盘上的 Linux：实用性建议

确保 Linux 在所有柱面上都处于启动状态

高级的格式化磁盘使用的是 4,096 字节的扇区，而不是更常见的 512 字节的扇区。为了让操作系统正常运行，人们使用固件将 4,096 字节的物理扇区分成 512 字节的逻辑分区，以此掩盖了这一变化，但是较大物理扇区的使用给磁盘布局和系统性能带来了一些隐患。本文将查看这些隐患，包括基准测试，它们描述了对一些常见 Linux 文件系统的可能的实际影响。随着高级的格式化磁盘变得越来越普遍，对于那些想要避免与次优配置相关的严重性能损失的人来说，了解如何处理这些磁盘也成为了一项重要的技能。

如果您熟悉磁盘结构，就会知道磁盘被分解成了多个扇区，这些扇区的大小通常为 512 字节；所有读写操作均在成倍扇区大小的空间内进行。如果仔细观察您就会发现，硬盘的各个扇区之间还包含额外的数据。磁盘使用这些额外字节的数据来检测和纠正每个扇区内的错误。

当扇区大小从 512 字节增加为更大的值时，就可以使用更有效的、功能更强大的纠错算法。因此，更改为较大大小的扇区可获得两个实际的好处：增加可靠性和扩大磁盘容量，至少从理论上将是这样的。

高级格式化磁盘将每个 4,096 字节的物理扇区转变成 8 个 512 字节的逻辑扇区。对于固件、操作系统和所有磁盘实用程序，磁盘看起像是 512 字节的扇区，但实际上，基础的物理扇区大小是 4,096 字节。然而，改变固件中表面的扇区大小会导致性能下降。要想了解其中的原因，则需要了解文件系统数据结构方面的知识，以及如何将分区放置在硬盘上。

4KB 扇区磁盘上的 Linux：实际建议 

文件系统数据结构为何会影响性能

当今的文件系统使用的是 4,096 字节或更大的数据结构。因此，大部分磁盘 I/O 操作使用了此数量的成倍大小的扇区。试想一下，如果 Linux 想在一个拥有 4,096 字节扇区的新磁盘上读写这些数据结构中的某一个，将会出现什么情况。如果文件系统数据结构恰好与基础物理扇区大小完全一致，那么读写 4,096 字节的数据结构就会产生单一扇区的读写。硬盘的固件不需要采取任何特别措施，但是，如果文件系统数据结构与基础物理扇区不完全一致，那么读写操作必须访问两个物理扇区。图 1 显示了这种差异：

图 1. 磁盘数据结构可以跨越高级格式化磁盘上的物理扇区

从理论上讲，读操作受到未对齐的影响小于写操作受到的影响。在执行磁盘读取操作时，磁盘的读/写磁头很可能忽略一个接着一个的扇区，因此固件返回 4 KiB 数据结构的任务就比较简单。相比之下，未对齐的数据结构的写操作要求磁盘的固件读取两个扇区，修改两个扇区的部分，然后写入两个扇区。这项操作花费的时间多于 4,096 字节数据占用单个扇区的时间。因此，会导致性能下降。实际上，读操作受到的影响有时与写操作受到的影响一样严重。

如何才能知道数据结构是否恰好对齐？大多数文件系统将其数据结构与包含数据结构的分区的开始部分对齐。因此，如果分区开始时是 4,096 字节（8 个扇区）的边界，则能恰好对齐。不过，在大约 2010 年以前，Linux 分区工具并不是采用这种方式来创建对齐的分区。即使在今天，这种方式仍然存在一些缺陷，因此创建分区时一定要小心谨慎。（要想了解如何使用常见的 Linux 分区软件完成这项工作，请转到下一小节，对齐分区。）

测试参数

为了了解正确对齐究竟有多重要，我在三台计算机上使用了三个高级格式化磁盘来执行测试：

• 一个 1TB 的西部数据 WD-10EARS 高级格式化驱动器 — 在使用了一个 NVIDIA MCP61P 芯片组和一个 64 位 2.6.32.3 内核的计算机上首批引入（2009 年末）的高级格式化磁盘之一。测试结果发布在本文的第一版中（2010 年出版）。
• 一个 2TB 的希捷 ST2000L003 驱动器，于 2012 年购买，该驱动器位于具有较新的 AMD 760G/SB710 芯片组和一个 64 位 3.4.1 内核的计算机上。
• 一个 3TB 的东芝 DT01ACA300 驱动器，于 2013 年末购买，该驱动器位于具有一个 Intel® H77 芯片组和一个 64 位 3.11.7 内核的计算机上。

在三个测试中，我都使用了全局惟一标识符 (GUID) 分区表 (GPT) 系统对磁盘进行分区，对齐的分区从逻辑扇区 40 开始，未对齐的分区从逻辑扇区 34（在使用具有默认分区表大小的 GPT 磁盘时，该扇区是第一个可用的扇区） 开始。被测试的文件系统是第三扩展文件系统 (ext3)、第四扩展文件系统 (ext4)、ReiserFS (V3)、日志文件系统 (JFS)、扩展文件系统 (XFS) 和 B-tree 文件系统 (Btrfs)。

在所有测试中，一个脚本执行了一系列的磁盘 I/O 操作，包括创建新的文件系统，将未压缩的 Linux 内核原始码 (tarball) 提取到测试驱动器中，将原始码复制到驱动器，读取测试驱动器上未压缩的原始码，从驱动器中读取原始码，以及删除 Linux 内核目录。源 Linux 内核原始码存储在另一个磁盘中，用于读取测试，输出被定向到 /dev/null。在执行每个写入测试后，都会立刻卸载测试驱动器，以此作为确保 Linux 磁盘缓存中没有保留任何操作的一种手段。报告的数字包括执行卸载操作所需的时间。

用于第一次测试的内核原始码的大小为 365MiB，用于第二次和第三次测试的内核原始码的大小为 451MiB。所有磁盘都有 64MiB 的缓存，因此两个测试中的原始码的大小都大大超过了磁盘的缓存大小。我在每个文件系统上运行每个测试序列各 6 次，3 次是在正好对齐的分区中，3 次是在未对齐的分区中。这些运行之间的变化不大。通过将平均对齐时间除以平均未对齐时间，就可以确定性能对未对齐的影响程度。值大于 1.00 表示未对齐存在一些性能损失。

更多详情见请继续阅读下一页的精彩内容：