主页 / unix / 问题 / 465937
Accepted
wouter205
Asked: 2018-08-31 22:55:13 +0800 CST

强制 fdisk 使用扇区 63 边界是否安全？

  • 772

出于某种原因，我的 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 的性能？

partition fdisk

3 个回答

  1. Best Answer

    扩展大小时，由于它涉及删除分区，因此您必须以它开始的任何数字重新创建它。

    否则充其量不会被识别，最坏的情况可能是数据损坏。

    如果该 VPS 是创建其他 VM 的模板，我会不厌其烦地重新创建/移动开头 * 和 * 数据/扇区到扇区 2048。

    因为它是一个虚拟机，如果你确实想移动分区，我不会完全移动它，我会在旁边创建一个分区，复制数据并使用复制分区启动。这就是使用虚拟机的美妙之处，您有更多的空间来测试事物。

    PS。至于我个人的观点，性能上的小幅提升并不值得将其从 63 扇区移出。我会等待机器退役，它迟早会发生。

    至于分区对齐：

    您希望分区与 4096 字节边界对齐。这样一来，实际扇区肯定会与虚拟扇区保持一致，而 VMWare 将使您的管理程序/虚拟机从硬件中提取更好的性能。

    要了解为什么未对齐的分区是一个性能问题，请参阅 purestorage.com 的这张图片：

    未对齐

    查阅业内存储专家的白皮书，以更好地了解当前的最佳实践：

    来自 Microsoft 和 Linux 分销商（如 Red Hat）的现代供应商支持的操作系统 (OS) 不再需要调整以将文件系统分区与虚拟环境中的底层存储系统的块对齐。

    （例如“保留默认设置”）

    但是，要继续回答原始问题，请访问一些链接的白皮书：

    将分区对齐到 VMDK 和 LUN 中的 4K 边界是推荐的最佳实践

    并且：

    在每个设备的输出中，将 start 乘以扇区大小（通常在 fdisk 输出中为 512），然后除以 4096。如果结果是整数（整数），则为 ALIGNED，否则为 MISALIGNED .

    因此，请检查您关于在第 63 扇区创建分区的问题：

    512 * 63 / 4096 = 7.875 => 错位

    将来我可能会使用并保留默认值 2048。让我们检查一下：

    512 * 2048 / 4096 = 156 => 对齐

    参考：

    常见问题解答：VMware vSphere、其他虚拟环境和 NetApp 存储系统的访客 VM 文件系统分区/磁盘对齐

    如何在 VMware vSphere 5.x 环境中更正来宾 VM 数据分区对齐

    如何在 VMWare ESX 中对齐块

    • 5

  2. 以供参考：

    • 传统 512b 扇区驱动器上的扇区 2048 是1MB 标记之后的第一个扇区。
    • 扇区 63 是32k 标记之前的扇区，最初对应于大多数硬盘第一个盘片上第一个磁道的最后一个扇区（至少，一旦磁盘几何形状变得合理标准化）。

    那么，为什么这些是相关的呢？

    您通常不从扇区 1 开始分区的原因有两个：

    • 它为引导加载程序留出了空间。MBR 格式只为引导加载程序留下了 40 多字节。在 CP/M 和 DOS 时代，这可能已经足够了，但很快它就变得太小了。因此，约定变成了您将第一个盘片的（几乎整个）第一条轨道留给引导加载程序。例如，GRUB 在 MBR 分区磁盘上使用时实际上需要这个。
    • 在处理以多种方式分区的磁盘时，这也很重要。一些分区表格式不是从扇区 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 作为基础实际上应该会稍微提高 VM 的性能。

    它也应该是完全安全的，只需确保在移动后重新安装引导加载程序，因为它可能引用文件系统中的确切块位置而不是文件，移动后不会指向正确的位置。

    • 2
    • 如果您使用 对磁盘进行分区fdisk，则起始扇区将为 2048+。
    • 如果您使用cfdisk，这可能会在您稍后添加磁盘时发生，在初始安装后，起始扇区可以是 63。

    因此，如果您有一个起始扇区为 63 的磁盘并且您想要调整分区大小，那么只需使用cfdisk而不是fdisk.

    我在 ProxMox 中添加和调整虚拟磁盘大小时遇到​​了这个问题。基本上，如果我必须更改一些/dev/sda*我会使用的东西fdisk，如果我需要调整分区大小/dev/sdb|c|d等，那么我会使用cfdisk. 学到了很难的方式。

    • 1

相关问题