为什么 GParted 分 Btrfs 会剩 1MB 尾巴？

一、为什么 GParted 分 Btrfs 会剩 1MB 尾巴？

1. 现代硬盘的扇区是 4K（物理扇区），而分区表（GPT/MBR）要求分区起始位置必须和 1MB 对齐，才能保证读写性能最优。
2. 很多工具默认会给每个分区的末尾留 1MB 空白，用来做分区表的安全缓冲，或者给文件系统的元数据留一点冗余空间，避免后续扩容 / 缩小时出错。
3. 尤其是 Btrfs，它的元数据、校验和结构本身就需要一定的起始 / 结束空间对齐，GParted 会自动帮你留好，你手动拖不到最末尾。

二、为什么终端和 GParted 显示的分区大小不一样？

1. 「分区表记录的大小」≠「文件系统实际可用大小」

• GParted 里显示的 “分区大小”：是这个分区在磁盘上的物理占用（比如 30GB），是分区表记录的固定值。
• 终端（lsblk/df -h）里显示的 “大小”：是文件系统格式化后，实际能给你存数据的空间。
  • Btrfs 格式化时，会自动预留：
    • 一部分空间给元数据（metadata）（用来存文件索引、校验和）
    • 一部分给校验码 / 冗余数据
  • 所以你分了 50GB 的分区，Btrfs 格式化后实际可用会变成 53.7G？不对，反过来：
    • 你说的 “50G 分区，终端显示 53.7G”，大概率是单位坑：
      • GParted 用的是 1GB = 1000MB（十进制）
      • 终端lsblk用的是 1GiB = 1024MiB（二进制）
    • 换算一下：50GB（十进制）= 约 46.57GiB（二进制），反过来也一样，两边显示差一点很正常。

2. 你说的 “30/100 变成 32/107，未分配也差了”

• GParted 里你输入的 30GB，它会自动按 1MB 对齐，算出来的实际占用是 32GB（十进制转二进制的对齐结果）
• 终端里lsblk显示的是二进制的 GiB，再加上分区表本身的几 MB 占用，数字就会差一点。
• 未分配空间的差异：GParted 显示的是「磁盘总容量 - 所有分区的物理占用」，而终端里你自己算的是「分区大小的近似值」，没把分区表本身的几 MB、对齐预留算进去，所以会差几 GB。

三、一句话总结所有差异

四、给你一个简单的验证方法

1. 用lsblk -b命令，它会按字节（bytes） 显示大小，两边的数字就完全一致了，不会有任何差异。
2. 再用df -h看 Btrfs 分区，会发现它的 “Size” 比分区物理大小略小，这是因为文件系统本身预留了空间给元数据，是正常现象。

• 工具里的「GB」是十进制的 1GB = 1000MB，终端里的「GiB」是二进制的 1GiB = 1024MiB，两边天生就差一点。
• 再加上 GParted 会自动做分区对齐、留一点冗余空间，看起来就差得更多了。