我认为自己患有“一切都必须为 2 的幂”综合症。当被要求在 VmWare 中为虚拟机创建 30G 磁盘时，我想创建一个 32G 磁盘。如果有人需要使用 LVM 的 256G 存储空间，我会创建 1 个 256、2 个 128 或 4 个 64...
问题很简单，创建“奇数”大小的磁盘是否会对性能产生影响或带来缺点，即使我将它们放入 Linux 上的卷组中？如果有人要求 80G，创建 10、20 和 50 可以吗？或者如果可以的话我应该尝试坚持使用 2 的幂吗？
答案1
我建议您留意分区是否是所谓的 I/O 对齐的，因为这可能会真正影响 I/O 性能。如今，这不再是问题，因为安装程序或配置向导通常会在某些"power of 2"边界上自动对齐分区，但当您手动创建分区时，了解其工作原理可能仍然很有用。
我将尝试通过从虚拟环境中借用的简单示例来解释这一概念。为了简单起见，我们假设 VMware vSphere 基础架构和 VMFS 文件系统。我们必须考虑总共三层 - 具有一定大小的块用于请求数据的磁盘阵列、具有一定大小的块的 VMFS 文件系统以及最后以块/群集组织的客户操作系统文件系统。
通常，您不必花时间将 VMFS 文件系统与磁盘阵列对齐，因为当您使用 vCenter 创建新的 VMFS 数据存储时，此操作会自动执行。客户操作系统的情况更糟。下面是未对齐层的图片：
当客户操作系统读取/写入单个块/集群时，底层虚拟机管理程序/磁盘阵列将必须从 VMFS 文件系统请求一个块和两个磁盘阵列块，因为该块跨越多个块。这可能意味着从多个磁盘主轴读取或写入，因为这些块可能根据 RAID 配置分布在多个磁盘上。这当然不是最佳配置。更好的是对齐的配置：
然后，一个文件系统块请求会生成一个磁盘阵列块请求。尽管如此，大多数现代操作系统都会记得在安装期间自动对齐 I/O 分区。例如，Windows Server 2008 或 RedHat Enterprise Linux 6 会这样做，但 Windows Server 2003 或更早的发行版不会这样做。
因此，仍然值得记住这一点，因为自动 I/O 对齐通常取决于存储设备功能，以指示其首选的 I/O 对齐和 I/O 块大小。现代 Linux I/O 堆栈（例如 RHEL 6、parted、LVM、mkfs）可以使用此类信息并自动执行。但如果它没有按预期工作，您应该手动执行。