我相信我患有“一切都必须是二权力”的症状。 当要求在VmWare中为VM创build30G磁盘时,我想创build一个32G磁盘。 如果有人需要256G的存储使用LVM我创build1 256,2 128或4 64 …
这个问题很简单,即使我将它们放到Linux上的卷组中,是否会对创build“奇数”大小的磁盘产生性能影响或缺陷? 如果有人要求80G是可以创build一个10,20和50来完成它? 或者我应该尽量坚持2的权力?
我宁愿推荐您关注一个分区是否被称为I / Oalignment的事实,因为这可能会影响I / O性能。 现在,不像安装程序或configuration向导通常在某些"power of 2"边界上自动alignment分区,但是当您手动创build它时,知道它是如何工作仍然是有用的。
我将尝试从虚拟环境借用简单的例子来解释这个概念。 为了简单起见,我们假设VMware vSphere基础架构和VMFS文件系统。 我们必须考虑总共三层 – 一个磁盘arrays,它有大小的数据块请求数据,有一定大小的块的VMFS文件系统,最后是一个以块/簇forms组织的客户操作系统文件系统。
通常,您不必花费时间将VMFS文件系统与磁盘arraysalignment,因为在使用vCenter创build新的VMFS数据存储时会自动执行该操作。 客户操作系统的情况更糟糕。 下面是未alignment图层的图片:

当客户操作系统读取/写入单个块/集群时,底层hypervizor /磁盘arrays将不得不从VMFS文件系统和两个磁盘arrays块中请求一个块,因为该块跨越多个块。 这可能意味着从多个磁盘轴读取或写入,因为根据RAIDconfiguration,这些块可能被分割到多个磁盘上。 当然这不是最佳的configuration。 更好的是一致的:

然后,一个文件系统块请求产生一个磁盘arrays块请求。 不过,大多数现代操作系统都记得I / O在安装时会自动alignment分区。 例如,Windows Server 2008或RedHat Enterprise Linux 6可以这样做,但是Windows Server 2003或更早版本的发行版不能。
所以仍然值得记住,因为自动I / Oalignment通常取决于存储设备的特性,以指示其优先I / Oalignment和I / O块大小。 现代Linux I / O堆栈(例如RHEL 6,parted,LVM,mkfs)可以处理这些信息,并自动执行。 但是,如果它没有按预期工作,你应该手动完成。