由于某种原因，我的 VPS（运行 Debian 8）的第一个分区与扇区 63 对齐（而不是 2048）
Model: VMware Virtual disk (scsi)
Disk /dev/sda: 314572800s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 63s 79971569s 79971507s primary ext4 boot
2 79971570s 83875364s 3903795s primary linux-swap(v1)
83875365s 314572799s 230697435s Free Space
现在我想调整分区大小以分配可用空间，不幸的fdisk是第一个扇区从 2048 开始。但正如我所读到的这里使用此命令可以强制fdisk从 63 启动。
fdisk -c=dos -u=cylinders /dev/sda
这有多安全？此外，由于此方法已被弃用，这是否会损害我的 VPS 的性能？
答案1
扩展大小时，由于涉及删除分区，因此您必须以它开始的任何编号重新重新创建它。
否则，最好的情况是无法识别，最坏的情况可能会导致数据损坏。
如果该 VPS 是用于创建其他虚拟机的模板，我会不厌其烦地重新创建/移动开头*和*数据/扇区到扇区 2048。
由于它是一个虚拟机，如果你确实想移动分区，我不会完全移动它，我会在侧面创建一个分区，复制数据并使用复制分区启动。这就是使用虚拟机的美妙之处，您有更多的空间来测试事物。
附言。就我个人的观点而言，性能上的微小提升并不值得将其从扇区 63 中移出。我会等待机器退役，这迟早会发生。
至于分区对齐：
您希望分区与 4096 字节边界对齐。这样，真实扇区基本上肯定会与虚拟扇区保持一致，并且 VMWare 将使您的虚拟机管理程序/VM 将从硬件中获取更好的性能。
要了解为什么未对齐的分区会导致性能问题，请参阅 purestorage.com 中的此图片：
查阅行业存储专家的白皮书，更好地了解什么是当前的最佳实践:
来自 Microsoft 和 Linux 发行商（例如 Red Hat）的现代供应商支持的操作系统 (OS) 不再需要调整来将文件系统分区与虚拟环境中的底层存储系统的块对齐。
（例如“保留默认设置”）
然而，要继续回答原来的问题，请访问几个链接的白皮书：
建议的最佳实践是将 VMDK 和 LUN 中的分区与 4K 边界对齐
并且：
在每个设备的输出中，将起始位置乘以扇区大小（fdisk 输出中通常为 512），然后除以 4096。如果结果是整数（整数），则为 ALIGNED，如果不是，则为 MISALIGNED 。
因此，检查有关在扇区 63 处创建分区的问题：
512 * 63 / 4096 = 7.875 => 未对齐
我将来可能会使用并保留默认值 2048。让我们检查一下：
512 * 2048 / 4096 = 156 => 对齐
参考：
常见问题解答：VMware vSphere、其他虚拟环境和 NetApp 存储系统的来宾虚拟机文件系统分区/磁盘对齐
答案2
以供参考：
- 传统 512b 扇区驱动器上的扇区 2048 是第一个扇区后1MB 标记。
- 63 扇区是右边的扇区前32k 标记，最初对应于大多数硬盘第一盘片第一磁道的最后一个扇区（至少在磁盘几何结构变得合理标准化之后）。
那么，为什么这些都是相关的呢？
通常不从扇区 1 开始分区有以下几个原因：
- 它为引导加载程序留下了空间。 MBR 格式只为引导加载程序留下了 40 多个字节。在 CP/M 和 DOS 时代，这可能已经足够了，但很快就变得太小了。因此，惯例是您将第一个盘片的（几乎整个）第一条轨道留给引导加载程序。例如，当在 MBR 分区磁盘上使用 GRUB 时，实际上需要这样做。
- 当处理以多种方式分区的磁盘时，它也很重要。有些分区表格式不是从扇区 0 开始。现代的一个例子是 GPT，它从扇区 1 开始，通常一直到扇区 31。一个更古老的例子是 Apple 系统使用的分区表格式与经典操作系统。这是一个更小众的用法，但由于 GPT，它至少仍然有一定的相关性。
- 对齐分区，使其在硬盘驱动器几何形状的自然边界（例如柱面或磁道边界）上开始和结束，可以提高性能。扇区 63 恰好位于自然边界处，并且大多数文件系统实际上并不经常接触它们的第一个扇区（如果有的话），因此它最终将第二个扇区放置在新柱面的开头，并且通常也位于新轨道的开始，通常在某些较旧的文件系统中非常频繁地访问（尽管在其他一些文件系统中根本不访问，例如 ext4 和 BTRFS 通常不会触及它）。
由于第 1 点和第 3 点，扇区 63 最终成为标准。然而，由于我将在下面概述的原因，它基本上已不再使用。
好的，那么为什么它增加到 1MB 呢？
这个有点棘手。我还没有看到任何实际明确的历史参考答案为什么选择 1MB，甚至在这开始成为常态时也是如此。但 IT 有一些优势：
- 它恰好针对 512b 和 4k 扇区大小正确对齐，这与从扇区 63 开始不同，这通常会导致您的大部分文件文件系统本身未对齐（这最初不是 FAT12 和 FAT16 的问题，因为它们通常默认在内部使用 512b 扇区进行操作）。
- 许多网络存储协议将 1MB 定义为读取和写入的最大块大小。通过像这样对齐分区，您最终可以与这些块协议正确对齐，从而避免当您只想进行部分写入时必须执行 RMW 周期的可能性。
- 大多数现代 SSD 都具有 512b 或 4k 扇区，但它们实际上在内部使用更大的块进行操作。现在通常这些块是 2MB 或 4MB 块，但许多较旧的块使用 1MB 块。正确对齐这些块实际上可以显着提高某些 SSD 的预期寿命，并且还可以显着提高写入性能。
好的，但是原来的问题呢？
鉴于上述情况，改为 2048 作为基础实际上应该会稍微提高虚拟机的性能。
它也应该是完全安全的，只需确保在移动后重新安装引导加载程序，因为它可能引用文件系统中的确切块位置而不是文件，而文件在移动后不会指向正确的位置。
答案3
- 如果您使用 分区
fdisk，起始扇区将为 2048+。 - 如果您使用
cfdisk，这可能会在初次安装后添加磁盘时发生，起始扇区可能是 63。
因此，如果您的磁盘起始扇区为 63，并且您想要调整分区大小，则只需使用cfdisk代替fdisk.
我在 ProxMox 中添加虚拟磁盘并调整其大小时遇到了这个问题。基本上，如果我必须更改某些内容，/dev/sda*我会使用fdisk，如果我需要调整分区大小/dev/sdb|c|d等，那么我会使用cfdisk.经过艰苦的努力才知道这一点。