徐小疼前一阵帮公司运维一台存储服务器，要上一块16TB的机械盘做备份仓库。我习惯性地敲下 fdisk /dev/sdb，进交互界面以后突然反应过来：MBR分区表从设计上就撑不住 2TB 以上的容量，fdisk 在这种场景下根本没法把整块盘用起来。这才老老实实切到 parted，用 GPT 分区表重新规划。
如果你也遇到过"插上大容量磁盘、fdisk 却只能用到 2TB"的困境，这篇就是给你写的。文章会讲清楚 parted 为什么在大磁盘分区场景里几乎是必需品，MBR 和 GPT 到底差在哪，以及从分区、格式化到挂载、写 fstab 的完整实操流程。无论是给新盘做初始化，还是要调整已有分区，照着做基本不会踩坑。
1. 2TB这道坎：为什么大磁盘分区绕不开parted
1.1 MBR的先天限制
老牌的 fdisk 默认操作的是 MBR（Master Boot Record）分区表。这种分区表最早出现在 1980 年代初的 PC 环境里，我查过资料，它的磁盘寻址用的是 32 位 LBA 扇区编号。每个扇区按 512 字节计算，2 的 32 次方乘以 512 字节，容量上限大约是 2 TiB，换算成常见的十进制单位就是 2.2TB 左右。
这意味着什么？往一块 4TB、8TB、16TB 的盘上跑 fdisk，即使你强行把分区建出来，超过 2.2TB 的那部分空间也会被直接忽略或者产生不可预料的报错。MBR 还有另一个限制：整块磁盘最多只能有 4 个主分区。想用更多分区就只能靠扩展分区和逻辑分区绕，逻辑分区本身又多一层间接寻址，复杂不说，还容易踩容量边界。
我见过一台上古服务器，当时系统盘只有 500GB，运维用 fdisk 也够用。但今天随便一块监控盘或者下载盘都是 4TB 起步，继续守着 fdisk 就纯属自我设限。
1.2 GPT突破了什么
GPT（GUID Partition Table）是替代 MBR 的现代分区表方案。它使用 64 位 LBA 扇区编号，容量上限在很长一段时间里都不会成为瓶颈。除了容量，GPT 还有几个实打实的优势：
- 分区数量默认支持到 128 个，基本告别了"主分区不够用"的窘境。
- 分区表和备份分区表在磁盘开头和结尾各存一份，单点损坏时还有恢复机会。
- 每个分区有独立的 GUID 和名称，方便识别和管理。
- 对 UEFI 引导非常友好，现在新装系统基本都是 UEFI + GPT 组合。
关于"为什么这个场景首选 parted"，核心原因其实很朴素：parted 原生支持 GPT，而且能把对 MBR 的理解很好地保留下来。GNU parted 项目的目的就是提供一个比 fdisk 更灵活的分区工具，交互逻辑直观，命令可脚本化，对 GPT 操作的支持也比传统 fdisk 完整。
可以看这张工具对比，理解一下为什么 fdisk 被很多人戏称为"古董工具"：
| 特性 | fdisk | parted |
|---|---|---|
| MBR | 支持 | 支持 |
| GPT | 新版支持但提示繁琐 | 原生完整支持 |
| 分区大小上限 | 2TiB（MBR 模式下） | 受文件系统和磁盘限制 |
| 非交互 / 脚本 | 支持但写法绕 | 命令直接，天然适合脚本 |
| 分区对齐控制 | 需手动计算 | 支持百分比、MiB、扇区等多种单位 |
1.3 parted能做到的事情
先用一句话说清楚 parted 的角色：它是一个分区表管理工具，不是格式化工具。分区是"在磁盘上划定边界并记录元数据"，格式化是"在划定好的边界里写入文件系统"。分工明确，后面实操时你就会体会到这种边界感。
parted 能做的事主要包括：
- 创建、删除、调整分区。
- 在 MBR 和 GPT 分区表之间切换。
- 查看磁盘整体布局和空闲空间。
- 检查分区是否对齐到最优边界。
- 以非交互模式执行单条命令，方便写自动化脚本。
它不能做的事也很明确：不能给你创建文件系统，像 ext4、xfs 这类文件系统必须用 mkfs 系列命令完成。
所以完整的磁盘使用流程应该是：parted 划分分区表 → 内核感知新分区 → mkfs 格式化 → mount 挂载 → 修改 fstab 实现开机自动挂载。后面我按这个链路一步步拆。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 动手前的磁盘模型：parted的交互逻辑与输出解读
2.1 进入交互模式，先看懂print free
parted 支持两种使用方式：直接带参数执行单条命令，或者不带参数进入交互模式。对于还不熟悉命令的读者，建议第一次先进入交互模式操作，这样能实时看到反馈，心智负担小很多。
bash复制parted /dev/sdb
进入后提示符会变成类似 (parted) 。我先说最常用的查看命令：
bash复制(parted) print free
这条命令会列出磁盘信息、分区表和所有空闲空间。输出类似这样：
code复制Model: ATA WDC WD160EDGZ-11 (scsi)
Disk /dev/sdb: 16.0TB
Sector size (logical/physical): 512B / 4096B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
17.4kB 16.0TB 16.0TB Free Space
这个输出信息量很大。Partition Table: gpt 说明当前磁盘已经是 GPT 分区表；如果是 msdos 就说明还是 MBR。Sector size 里的 512B / 4096B 代表逻辑扇区是 512 字节、物理扇区是 4096 字节，这种 4K 对齐需求在机械盘和 SSD 上都很常见，后面讲对齐时会再提到。
Free Space 表示整块盘还没有分区。如果已经分过区，这里会显示分区编号、起始结束位置、文件系统类型和名称。
2.2 用 mklabel 切换分区表格式
如果 print 显示的 Partition Table 是 msdos，而这块盘大于 2TB 或者你想换成 GPT，就需要用 mklabel 重新创建分区表：
bash复制(parted) mklabel gpt
执行后会提示确认，输入 Yes 即可。这一步会清空磁盘上已有的所有分区信息，所以操作前务必确认磁盘上没有需要保留的数据。
我习惯在换分区表前先执行 lsblk 和 df -h 双重核验，确认没有分区被挂载使用中。磁盘一旦被系统占用，parted 通常也会拒绝执行。
2.3 三种位置单位，哪种最容易踩坑
parted 里最让人困惑的就是位置单位。新建分区时，你可以用扇区号、MiB/GiB/TiB、百分比三种方式来指定起始和结束位置。三类写法各有优缺点：
| 写法 | 示例 | 优点 | 缺点 |
|---|---|---|---|
| 扇区号 | mkpart primary 2048s 100% |
精确 | 需要自己算，容易写错 |
| 容量单位 | mkpart primary 1MiB 500GiB |
直观明了 | 不指定起点时容易忽略起始对齐 |
| 百分比 | mkpart primary 0% 100% |
适合整盘划分 | 对中间某个位置不友好 |
我最常用的是 MiB 和 GiB 混合。比如要分一个 500GB 的数据分区，我会写成：
bash复制(parted) mkpart primary 1MiB 500GiB
从 1MiB 开始而不是 0 开始，这个习惯很重要。因为 GPT 分区表本身会在磁盘开头占用一部分空间，0 号扇区附近通常用来存放保护性 MBR 和 GPT 头，直接从 0 开始纯属找麻烦。从 1MiB 开始可以完美避开这些元数据。
百分比写法比较适合懒人，前提是磁盘总容量能被整除。如果你打算整块盘只分一个区，0% 100% 是最简单的。如果磁盘容量奇奇怪怪，百分比反而可能算出非常规的扇区位置，增加对齐风险。
2.4 对齐问题：optimal 的意义
现代磁盘物理扇区普遍是 4096 字节，SSD 的读写单位更是按页和块来算。如果分区起始位置没有对齐到物理扇区边界，每次 IO 都可能跨越两个物理扇区，性能下降明显，特别是随机读写场景。
parted 从 2.x 版本开始，许多单位在创建分区时会默认做对齐计算。实际上，只要你用 MiB、GiB 这种较大的单位，parted 会默认将起始位置对齐到 1MiB 的整数倍，这通常已经满足 4096 字节物理扇区的对齐要求了。
但是，如果你直接输入一个裸的扇区号，比如 mkpart primary 2048s 100%，虽然 2048s 实际上是 1MiB，看起来没问题，可一旦写成 100s、200s 这种奇葩数字，不对齐的坑就埋下了。
可以用 align-check 命令检查分区是否对齐到最优边界：
bash复制(parted) align-check optimal 1
如果对齐没问题，会返回 1 aligned。如果没对齐，最好删掉重建，不要图省事强行留着。
我不太喜欢一上来就把所有细节全堆给读者，但分区对齐这件事真的值得认真对待。很多性能问题排查到最后都是当年分区没对齐留下的后遗症，与其事后返工，不如建分区时就花一分钟检查。
3. 实战：一块4TB新盘从分区到挂载全流程
3.1 设备确认：先摸清底细再说
正式操作前，我会先看系统识别到哪些新磁盘，避免误操作到系统盘。
bash复制lsblk
输出里重点看有没有 sdb、sdc 这类没有挂载点的新设备。再用 parted 自带的 print 确认型号和容量：
bash复制parted /dev/sdb print
如果显示 unrecognised disk label，说明磁盘目前没有分区表，需要先建 GPT。这一步花不了多长时间，但能避免你在错误的设备上敲下破坏性命令。
3.2 创建GPT分区表和主分区
假设新盘是 /dev/sdb，容量 4TB，我想把它分成两个区：第一个区 1TB 给数据仓库，剩下的空间作为第二个分区备用。
第一步，创建 GPT 分区表：
bash复制parted /dev/sdb mklabel gpt
小心这里的细节：如果你想非交互执行，mklabel 通常不会弹出确认提示；但我实际操作中发现，在某些版本的 parted 中，创建分区表时会因为磁盘原有 MBR 残留而询问，用 -s 参数可以跳过交互确认。
第二步，创建第一个分区：
bash复制parted /dev/sdb mkpart primary 1MiB 1TiB
输出可能会提示：
code复制Warning: The resulting partition is not properly aligned for best performance.
这说明我对齐出了问题。正常用 MiB 为单位不会报这个错，如果报了就检查起始位置是不是太随意。
第三步，创建第二个分区，把剩余空间都用上：
bash复制parted /dev/sdb mkpart primary 1TiB 100%
再次查看结果：
bash复制parted /dev/sdb print
这时候应该能看到两个分区和各自的大小。用 print free 还能看到剩余空间是什么样的。
3.3 让内核感知新分区表
分区创建完成后，系统内核不一定立刻识别到。有人会直接重启，其实没必要，用 partprobe 手动让内核重新读取分区表即可：
bash复制partprobe /dev/sdb
这是我个人非常推荐的一个步骤，因为它能避免大部分"分区建好了但看不到 /dev/sdb1"的尴尬。执行完 partprobe 后，再执行：
bash复制lsblk /dev/sdb
看到 sdb1 和 sdb2 出现，就说明分区已被内核接纳，可以进行格式化了。
3.4 格式化：文件系统选型与命令
分区完成后是文件系统选型。Linux 下最常见的两个选择是 ext4 和 xfs。
- 如果分区主要存大量小文件，比如代码、网站动静分离的数据，ext4 在小文件处理上表现不错。
- 如果分区主要存大文件、备份文件、视频素材，xfs 吞吐能力更强，且对超大文件支持更好。
我常用 xfs 来做大容量存储。格式化命令如下：
bash复制mkfs.xfs /dev/sdb1
如果选了 ext4：
bash复制mkfs.ext4 /dev/sdb2
注意 mkfs.xfs 执行速度一般比 mkfs.ext4 慢一些，这是正常现象，特别是 1TB 以上的分区。格式化完成后再用 blkid 查一下分区 UUID，后面写 fstab 会用到：
bash复制blkid /dev/sdb1 /dev/sdb2
3.5 创建挂载点并临时挂载
格式化的下一步就是挂载。先创建挂载目录，目录名建议根据用途取，方便后期识别。比如：
bash复制mkdir -p /data/backup
mount /dev/sdb1 /data/backup
挂载成功后用 df -hT /data/backup 验证一下，可以看到文件系统类型已经变成了 xfs 或 ext4。
但这里有个新手常犯的错误：以为 mount 挂上就万事大吉了，结果重启后分区又不见了。要做到开机自动挂载，必须把挂载信息写进 /etc/fstab，这部分的坑我单独在第 5 章细说。
4. 非交互式分区：脚本化操作与批量初始化
4.1 单条命令完成分区
实际运维中，可能一次要给好几台机器做同样的大规模磁盘初始化。如果每台都进入 parted 交互模式一条条敲，不仅慢还容易出错。这时候非交互模式就是刚需。
parted 的 -s 参数表示 script 模式，也就是不进入交互界面、不等待确认，直接执行后面跟的命令。一条命令建 GPT 分区表：
bash复制parted -s /dev/sdb mklabel gpt
一条命令创建两个分区：
bash复制parted -s /dev/sdb mkpart primary 1MiB 1TiB
parted -s /dev/sdb mkpart primary 1TiB 100%
有读者可能会问：-s 参数会不会在危险操作时也不加确认？答案是：它确实会跳过所有交互确认，所以任何带 -s 的 mkpart、rm、mklabel 操作都必须在命令执行前做足检查。我在生产环境写脚本时，会强制在脚本开头加一个设备名校验：
bash复制#!/bin/bash
TARGET_DISK=$1
if [ "$TARGET_DISK" != "/dev/sdb" ]; then
echo "仅允许操作 /dev/sdb，请检查输入设备"
exit 1
fi
parted -s "$TARGET_DISK" mklabel gpt
这种强制白名单的思路虽然笨，但确实避免过几次灾难。
4.2 align-check 给脚本加一道保险
脚本批处理时，我很建议在分区命令后加一个对齐检查。parted 支持一条命令直接检查：
bash复制parted -s /dev/sdb align-check optimal 1
如果返回值不是成功状态，脚本就要停止。这可以这么写：
bash复制if ! parted -s /dev/sdb align-check optimal 1; then
echo "分区1未对齐，请检查起始位置"
exit 1
fi
加上这层保护后，批量初始化时即使磁盘型号不同、容量不同，也能尽早发现错误，而不是等跑完全部命令后才意识到分区建歪了。
4.3 脚本化容易翻车的几个细节
我踩过的坑大致有三个，写下来给大家提个醒。
第一个坑是 parted 在脚本中单位选择。如果脚本里写的是 1049kB 这种小单位，不同磁盘型号可能因为扇区大小不同而计算出不一样的行业结果。用 1MiB 这种明确的大单位最稳妥。
第二个坑是 lsblk 设备名漂移。服务器可能上一块盘是 /dev/sdb，重启后因为内核枚举顺序变化就变成 /dev/sdc 了。脚本里如果硬编码设备名，非常容易把盘搞错。最好用 /dev/disk/by-id/ 路径来确认设备，或者至少用 lsblk -o NAME,SERIAL,MODEL 手动复核一遍。
第三个坑是忘记在 mkpart 之后执行 partprobe。脚本执行完分区后立即执行 mkfs 会看到 No such file or directory 或者 cannot open /dev/sdb1 这样的报错，因为内核还没识别到这个分区。解决办法是在 mkpart 后加一句：
bash复制partprobe /dev/sdb
sleep 2
这里的 sleep 是为了给内核一点时间完成设备扫描，实测很稳。
5. 收尾没有结束：UUID、挂载与fstab的正确姿势
5.1 为什么 fstab 里要写 UUID 而不是 /dev/sdb1
每次讲到 fstab，我都要强调一遍：不要在 /etc/fstab 里写 /dev/sdb1 这种设备路径。
设备名的分配顺序不固定，今天你的备份盘是 /dev/sdb1，下次重启可能因为加了块新盘变成 /dev/sdc1，系统在启动时找不到对应设备，直接进入紧急模式，卡在那里等你手动处理。
而 UUID 是文件系统在格式化时生成的全局唯一标识符，只要不重新格式化就不会变化。用 UUID 挂载可以避免设备名漂移的问题。获取 UUID 的方式很简单：
bash复制blkid
输出形如：
code复制/dev/sdb1: UUID="a1b2c3d4-...-..." TYPE="xfs" PARTUUID="..."
把 UUID= 后面引号里的内容复制出来即可。
5.2 fstab 字段逐项拆解
/etc/fstab 每行有 6 个字段，分别表示设备、挂载点、文件系统类型、挂载选项、是否 dump、是否 fsck。
一个典型写法是：
code复制UUID=a1b2c3d4-...-... /data/backup xfs defaults 0 0
字段含义对照：
| 字段 | 示例 | 说明 |
|---|---|---|
| 1 | UUID=... | 要挂载的块设备 |
| 2 | /data/backup | 挂载点，必须已存在 |
| 3 | xfs | 文件系统类型 |
| 4 | defaults | 挂载选项，默认包含 rw、suid、dev、exec、auto 等 |
| 5 | 0 | 是否被 dump 备份程序跟踪，通常填 0 |
| 6 | 0 | 是否在启动时执行 fsck，xfs 通常填 0，ext4 可填 2 |
在 xfs 文件系统上，第 6 个字段不建议填 1。因为 xfs 的 fsck 实际是 xfs_repair，它不适合在挂载状态下自动执行，填 0 是惯例。ext4 分区填 2 可以，根分区一般填 1。
5.3 写 fstab 之前的安全验证法
我写 fstab 有个铁律：改完先执行 mount -a 验证，不要直接重启。mount -a 会按照 fstab 内容重新挂载所有未挂载的文件系统。如果语法或设备写错了，它会立即报错，而不是等到重启才发现。
具体操作流程是：
bash复制vim /etc/fstab
# 追加你的挂载行
mount -a
如果没有任何报错，再执行：
bash复制df -hT /data/backup
看到挂载信息就说明 fstab 写对了。如果 mount -a 报错，大概率是 UUID 复制多了一个空格、挂载点目录不存在或者文件系统类型写错。改完再执行一遍，直到通过为止。
5.4 万一 fstab 写错了，怎么救
谁都有手滑的时候。如果 fstab 写错导致重启后进不了系统，卡在 emergency mode，不要慌。系统会提示输入 root 密码或按 Ctrl-D 重启。进入 shell 后执行：
bash复制mount -o remount,rw /
然后编辑 fstab，把错的那行注释掉或改对，最后重启即可。
为什么 root 文件系统会被挂载成只读？这是因为系统在发现 fstab 错误后进入紧急模式，出于保护会以只读方式挂载根分区。不先执行 remount,rw 就直接编辑文件，你会发现保存时报只读文件系统错误。
我在测试环境特意故意写错过一次 fstab，逼自己走了一遍上述流程。这种练兵极有必要，真在生产环境遇到时至少不会手忙脚乱。
6. 磁盘要调整：resizepart和GPT分区的边界操作
6.1 扩展分区的正确顺序
磁盘空间不够时，需要把某分区扩大。很多人上来就直接执行 resizepart 命令让分区变大，但如果没有同步扩展文件系统，系统只会看到分区边界变了，文件系统内部并不知道，空间可能无法直接使用。
正确的扩充分区顺序是：
- 先扩展分区大小。
- 再让内核重新读取分区大小。
- 最后扩展文件系统。
以 xfs 文件系统为例。假设 /dev/sdb1 在 /data 下挂载，要从 1TB 扩到 1.5TB。先看空闲空间从哪开始：
bash复制parted /dev/sdb print free
确认第二个分区紧跟第一个分区，且空闲空间在后面。然后执行：
bash复制parted /dev/sdb resizepart 1 1.5TiB
如果分区正在使用中，parted 会提示分区忙，需要先卸载或者使用离线方式处理。执行完 partprobe 后，用 xfs 的在线扩展命令扩充文件系统：
bash复制xfs_growfs /data
xfs_growfs 以挂载点为参数，不是以设备为参数，这点容易记错。扩展完成后 df -hT /data 就能看到文件系统容量已经涨到新大小。
ext4 文件系统则使用 resize2fs /dev/sdb1。前提同样是分区已经扩大，然后执行 resize2fs 才能让文件系统用满分区空间。
6.2 xfs 能大不能小，这是硬约束
这里必须给想缩容 xfs 的同学泼一盆冷水：xfs 文件系统不支持在线缩小，甚至离线缩小也非常困难。理论上可以通过备份全量数据、重新分区、重新格式化、恢复数据的方式实现缩小，但实际上没有哪个正经文档建议这么干。
如果你需要的是一个既可以扩容又可以缩容的文件系统，一开始就不要用 xfs，btrfs 或者 ext4 的缩容支持相对更好。xfs 在大容量顺序读写上有优势，但灵活性不如 ext4。做方案的时候就要想清楚未来是否有缩容需求，而不是等分区分好了才后悔。
我个人的建议是：在用 parted 做规划时，就把分区分得足够满足未来 1~2 年的增长预期，不然后期扩容牵扯在线操作，即使 xfs 支持在线 grow，仍然需要计划停机窗口。
6.3 顺手备份 GPT 分区表
GPT 分区表在磁盘开头和结尾都有副本，相对 MBR 更健壮，但依然可能被误操作或意外写入破坏。parted 本身没有直接提供完整的备份分区表功能，但可以使用 gdisk 工具组里的 sgdisk 来做：
bash复制sgdisk --backup=/root/gpt-backup-sdb /dev/sdb
恢复的时候：
bash复制sgdisk --load-backup=/root/gpt-backup-sdb /dev/sdb
这条经验可能有点超过 parted 的范围，但实际生产中我非常建议在完成磁盘分区后顺手备份一份分区表。分区本身才几个 KB，备份成本极低，真到要恢复的时候你会感谢这个习惯。
7. 我在实战中遇到过的报错与排查
7.1 The resulting partition is not properly aligned
这个报错我在 SSD 上遇到过几次，大部分原因是用了奇怪的起始位置。解决办法也很简单：删除分区，用 1MiB 或 0% 重新建。
需要特别注意的是，某些老型号的 4K 扇区机械盘或者 SSD，即使从 1MiB 开始，也可能要求更高阶的对齐方式。这时候可以先查磁盘的物理扇区大小：
bash复制cat /sys/block/sdb/queue/physical_block_size
如果结果是 4096，说明物理扇区是 4K，按 1MiB 边界对齐通常没有问题。如果结果还是 512，但磁盘是 Advanced Format 老盘，那就得看具体型号。总的来说，从 1MiB 开始已经能规避绝大多数对齐问题。
7.2 Partition(s) on /dev/sdb are being used
在删除或者修改已经被挂载的分区时，parted 会明确拒绝，输出类似 Partition(s) on /dev/sdb are being used。这是因为内核仍然在使用它的文件系统。
处理方法是先卸载挂载点：
bash复制umount /data/backup
如果卸载时报 target is busy，说明有进程占用，用 lsof +f -- /data/backup 或 fuser -mv /data/backup 找出占用进程并结束后再卸载。
有一个场景容易被忽略：即使分区没有显式挂载，swap 空间或者 LVM 物理卷也可能占用分区。此时 parted 同样会拒绝。解决办法是先 swapoff /dev/sdb1 或从 LVM 卷组中移除该 PV。
7.3 unrecognised disk label 和数字格式警告
新盘没有任何分区表时，运行 parted /dev/sdb print 会提示 unrecognised disk label。这不算报错，只是在告诉你这块盘还没有可识别的分区表。直接 mklabel gpt 即可。
还有一种情况比较隐蔽：mkpart 时输入的数字后带了多余空格，或使用 1GB、1G 之类的非标准单位，parted 会报 unexpected input。我建议始终使用 MiB、GiB、TiB 这种带 i 的单位，这是 parted 官方推荐写法，用的时候把计算机二进制单位和 SI 十进制单位分清楚。
7.4 mkpart 结束系统不识别新分区
前面提过，这多半是内核没刷新分区表。在新建或删除分区后执行：
bash复制partprobe /dev/sdb
如果执行后 lsblk 仍然看不到新分区，先确认分区创建时没有报任何 error。排除后可以试试：
bash复制partprobe
不带参数会重新探测所有磁盘。极少情况下需要重启，但那是最后的办法，不要一遇到问题就按重启键。
我在几台系统上还发现，某些老内核 + 新硬件组合下，partprobe 只刷新了存在分区表的设备，如果整盘从无分区表变为有分区表，个别版本可能不太灵敏，多执行一次基本都能解决。
7.5 分区删不掉，提示无法读取分区表末端
GPT 要求磁盘末尾还有一个备份分区表。某些磁盘如果之前被某些工具截断过尾部空间，会出现 GPT 备份缺失，导致 parted 在操作时报错。这类问题建议用 gdisk 的 x 高级菜单里的 w 写回功能重建备份 GPT，或者用 sgdisk -e 移动备份表到磁盘末尾。
bash复制sgdisk -e /dev/sdb
这是我后加的一个小技巧，平时不常用，真碰到尾部空间被占的辣手问题时会非常管用。分区表这类元数据一旦出问题，稳定复现的概率很高，别怕，按照报错信息一步步检查就能定位到原因。
总得来说，parted 配合 GPT 分区表是处理大磁盘的成熟方案，也是 Linux 运维的基础功。写这篇时把这两年实际踩过的坑都复盘了一遍，希望能帮你少走弯路。如果你刚开始接触，建议先拿虚拟机挂一块虚拟磁盘练手，把 mklabel、mkpart、partprobe、mkfs、mount、fstab 这一串流程走通，再上真实环境操作，心里会踏实很多。