Linux磁盘分区与挂载实战：从fdisk到扩容排障一次讲透-代码聚汇网

Linux磁盘分区与挂载实战：从fdisk到扩容排障一次讲透

徐小疼·2026-09-01·阅读 25 GEO检测（免费）

Linux分区fdiskparted

|难度：普通|阅读约 40 分钟

一块新磁盘接入服务器，从“能被系统看到”到“能被业务使用”，中间隔着分区、格式化、挂载三座山。很多人在这一步踩坑：fdisk 进去一顿操作，退出后发现系统根本没识别；/etc/fstab 写错一个字段，重启直接进不了系统；磁盘明明扩容了，df -h 看到的容量却纹丝不动。这篇文章我就把 Linux 分区管理这条链路上的常用命令和真实排障经验完整过一遍，从查看磁盘现状到创建分区、格式化、挂载、扩容，再到那些文档里不会写的细节，一次讲透。

1. 动手分区前，先把磁盘现状“看明白”

1.1 lsblk：一眼看清磁盘拓扑的利器

lsblk（list block devices）是我在 Linux 上最常用的磁盘查看命令，没有之一。它把磁盘、分区、挂载点的树形关系直接列出来，比 fdisk -l 那种纯文本输出直观太多。

bash复制[root@localhost ~]# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0   40G  0 disk
├─sda1   8:1    0    1G  0 part /boot
└─sda2   8:2    0   39G  0 part
  ├─centos-root 253:0    0   37G  0 part /
  └─centos-swap 253:1    0    2G  0 part [SWAP]
sdb      8:16   0  500G  0 disk

输出里最值得关注的是 TYPE 列：disk 表示物理磁盘，part 是磁盘上的分区。MAJ:MIN 是主设备号和次设备号，排查硬件问题时偶尔会用到。RM 为 1 表示可移动设备，比如 U 盘。MOUNTPOINT 直接告诉你分区挂到哪里，[SWAP] 表示交换分区。

加上 -f 参数能看到更关键的信息——文件系统类型和 UUID：

bash复制[root@localhost ~]# lsblk -f
NAME   FSTYPE  LABEL  UUID                                 MOUNTPOINT
sda
├─sda1 xfs            2e7d2a6c-...                         /boot
└─sda2 LVM2_member    p9XzTw-...                          
  ├─centos-root xfs   4f3e8f2a-...                         /
  └─centos-swap swap  5d9b1e11-...                         [SWAP]

这个输出对后续写 /etc/fstab 太重要了——fstab 里推荐用 UUID 而不是设备名（比如 /dev/sda1），因为设备名在系统重启、换盘、内核版本升级后可能变化，UUID 才是稳定的标识。

1.2 fdisk -l 与 blkid：查看底细的补充手段

fdisk -l 是按磁盘逐个显示分区信息的传统命令，适合看容量、起始扇区、扇区大小这些底层参数：

bash复制[root@localhost ~]# fdisk -l /dev/sdb
Disk /dev/sdb: 500 GiB, 536870912000 bytes, 1048576000 sectors
Disk model: Virtual Disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 8B5B9C8A-3C15-4A23-8F5A-3D7D3B4A6F21

Disklabel type 告诉你是 gpt 还是 dos（MBR），这个信息在判断磁盘容量和引导兼容性时很关键。超过 2TB 的磁盘必须用 GPT，老旧的 MBR 分区表最大只支持 2TB 寻址，强行使用会浪费空间。

blkid 则是个“指纹识别器”，专门查分区的 UUID、文件系统类型和 LABEL。它在脚本里特别好用，比如写一断自动化脚本时先 blkid /dev/sdb1 确认一下格式化结果：

bash复制[root@localhost ~]# blkid /dev/sdb1
/dev/sdb1: UUID="3b3c7c71-3f7c-4c9f-8b6e-1a2d4f5e6a7b" TYPE="xfs" PARTLABEL="data" PARTUUID="9f1c2e8d-..."

1.3 df -h：文件系统视角的容量统计

df -h 是另一个视角——它不关心物理磁盘长什么样，只看已经挂载的文件系统用了多少空间。它和 lsblk 是互补关系：lsblk 回答“有什么”（设备拓扑），df 回答“用得怎么样”（使用率）。

bash复制[root@localhost ~]# df -h
Filesystem             Size  Used Avail Use% Mounted on
/dev/mapper/centos-root   37G   30G  7.4G  81% /
devtmpfs               3.8G     0  3.8G   0% /dev
tmpfs                  3.8G     0  3.8G   0% /dev/shm
/dev/sda1              1014M  174M  841M  18% /boot

注意 df 显示的是文件系统容量，而不是裸分区容量。同一种分区，ext4 和 xfs 格式化后的实际可用空间略有差异，因为元数据本身占用了少量空间。

1.4 为什么宁可多看一眼也不要直接开工

我见过太多次翻车，都是因为没看现状直接操作。有一次同事收到一批新服务器，fdisk -l 显示 /dev/sdb 是 500G，他直接 fdisk /dev/sdb 创建分区、写表、格式化、挂载，一气呵成。结果第二天监控报警，磁盘 IO 异常。后来检查发现这些盘根本不是新盘，而是厂商预装系统时留下的“残留盘”，里面有旧分区表和 RAID 元数据。他一顿操作把旧分区信息覆盖了，但磁盘上的 RAID 残留没清干净，后续跑起来各种怪异。

正确的做法是：新盘接入后先 lsblk 看整体拓扑，再 fdisk -l 看目标盘的分区表类型，blkid 看是否已有分区。确认是完完全全的裸盘再动手。多花一分钟看现状，能省下后面好几小时的排障时间。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 分区创建实操：fdisk 与 parted 的完整操作路径

2.1 fdisk：MBR 时代的经典工具，今天依然够用

fdisk 是大多数 Linux 管理员第一个接触的分区工具。虽然它诞生于 MBR 时代，但新版 util-linux 里的 fdisk 已经支持 GPT 分区表，日常使用完全够了。它的交互式界面虽然不够“现代化”，但在交互式环境中反而直观：

bash复制[root@localhost ~]# fdisk /dev/sdb
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0x...

交互命令的关键就几个：

m：显示帮助
n：新建分区
d：删除分区
p：打印分区表（查看当前操作结果，注意此时还只是预览，未写入磁盘）
w：保存并退出（真正写入磁盘）
q：不保存退出（放弃所有操作）
t：修改分区类型（比如改 82 为 Linux swap，改 8e 为 Linux LVM）

典型的新建分区流程：

bash复制Command (m for help): n
Partition number (1-128, default 1): 1
First sector (2048-...): 2048
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-...): +100G

Command (m for help): p   # 先预览一下

Command (m for help): w   # 确认无误再保存
The partition table has been altered!
Syncing disks.

这里必须强调：w 之前的 n 操作只存在内存里，按 q 退出则全部作废。按 w 后系统会真正写入分区表并同步磁盘。如果你不确定自己的操作是否正确，先按 p 看效果，不要急着 w。

2.2 parted/gdisk：大容量磁盘与 GPT 分区的正确姿势

虽然新版 fdisk 支持 GPT，但遇到以下场景我更推荐用 parted 或 gdisk：

磁盘超过 2TB，必须用 GPT 分区表
需要脚本化批量创建分区
需要非常精确地控制分区起始和结束位置

parted 支持命令行模式，可以避免交互式脚本难以自动化的痛点：

bash复制[root@localhost ~]# parted /dev/sdb mklabel gpt
[root@localhost ~]# parted /dev/sdb mkpart data ext4 1MiB 100%
[root@localhost ~]# parted /dev/sdb print

第一行将磁盘分区表初始化为 GPT；第二行创建一个从 1MiB 开始、到磁盘末尾结束的主分区，label 设为 data；第三行打印分区表确认结果。mkpart 后面的 ext4 只是设置分区类型标签，跟实际文件系统格式没有关系，真正的格式化要靠后面的 mkfs 命令。

gdisk 则交互式操作更顺手，且不会像 fdisk 那样误存 MBR 引导代码。gdisk 的命令和 fdisk 基本一致，n 新建、w 写入退出。它还会默认设置合理的对齐参数，避免 SSD 和 4K 扇区磁盘出现性能问题。

这里必须说清楚磁盘对齐的问题。现代硬盘（尤其是 SSD 和 4K 扇区 HDD）物理扇区是 4096 字节，但逻辑扇区可能还是 512 字节。如果分区的起始扇区刚好是 4K 的整数倍（通常是 2048 扇区，即 1MiB 处），IO 性能和寿命都会明显更好。老工具默认从 63 扇区开始，是在对齐上的“地雷”。parted 里明确写 1MiB 就是为了保证从 1MiB 边界开始，绝不错位。

2.3 分区后内核未刷新：partprobe 到底有什么用

分区创建完成后，你可能会遇到这种情况：

bash复制[root@localhost ~]# fdisk /dev/sdb   # 创建了分区
[root@localhost ~]# lsblk
sdb      8:16   0  500G  0 disk
# 这里看不到 sdb1，因为内核分区表还没刷新

新分区没有立即出现在 /dev 目录下，原因是内核的分区表缓存尚未更新。这时候执行：

bash复制[root@localhost ~]# partprobe /dev/sdb

partprobe 会通知内核重新读取分区表。如果它提示 “Re-reading partition table failed”，别慌，先确认没有分区正在被使用（比如 df -h 里没有需要解绑的挂载），再执行一次。极少数情况需要重启才能让内核全量识别，这通常发生在根分区正在被使用且无法完全卸载的场景。

实际上在新版本内核中，创建分区后 lsblk 往往会自动刷新，但在某些发行版或者虚拟化场景下仍可能滞后。所以养成习惯：分区后随手 partprobe，消除不确定性。

3. 文件系统格式化：mkfs.xfs 与 mkfs.ext4 之间的取舍

3.1 文件系统选择的核心依据不是喜好，而是场景

分区表创建完成后，下一步是格式化，也就是在分区上创建文件系统。Linux 下常见的文件系统有 xfs、ext4、btrfs、zfs 等，但最常用的是 xfs 和 ext4。两者的取舍我直接列成表：

维度	ext4	xfs
擅长场景	大量小文件、通用业务	大文件、高吞吐、流媒体
最大单文件	16TB（取决于块大小）	500TB+
在线扩容	支持（resize2fs）	支持（xfs_growfs）
在线收缩	支持	不支持
元数据崩溃恢复	e2fsck	xfs_repair
断电源恢复速度	较慢	较快
成熟度	极成熟	极成熟

简单说：如果这块盘要放数据库（大量小文件、随机读写），ext4 更稳妥；如果放视频、备份、容器镜像层（大文件、顺序读写），xfs 更合适。CentOS/RHEL 默认用 xfs，Ubuntu 默认用 ext4，两家发行版的默认选择本身就有参考价值。

3.2 mkfs 命令的实操细节

格式化的基本命令：

bash复制[root@localhost ~]# mkfs.xfs /dev/sdb1
[root@localhost ~]# mkfs.ext4 /dev/sdb1

mkfs 本身是个前端工具，根据文件系统类型调用对应的 mkfs.xfs、mkfs.ext4。注意 mkfs.ext4 底层是 mke2fs 的封装，部分发行版可能需要额外安装 e2fsprogs。

格式化前必须确认设备名。这是最容易造成不可逆事故的地方。我曾经见过有人想格式化 /dev/sdb1，结果因为之前做过硬件 RAID 顺序调整，设备名整体偏移，/dev/sdb1 已经变成了系统分区 /boot，一个回车下去，引导分区里的内核和 grub 全没了。所以格式化前必做三件事：

lsblk 确认设备树，看清楚 /dev/sdb1 到底对应哪块盘
blkid /dev/sdb1 确认是否是目标分区、是否已有数据文件系统
对照磁盘容量和分区编号，核实无误再执行 mkfs

如果磁盘上有需要保留的数据，或者你只是想重装文件系统，mkfs 没有撤销机制。它只是重建文件系统元数据，不直接清除数据块，但文件系统索引已经没了，普通工具基本无法恢复。

3.3 交换分区格式化：mkswap 的特殊性

交换分区（swap）和普通数据分区不同，它不需要创建文件系统，而是直接用 mkswap 初始化：

bash复制[root@localhost ~]# mkswap /dev/sdb2
Setting up swapspace version 1, size = 4 GiB
[root@localhost ~]# swapon /dev/sdb2
[root@localhost ~]# swapon --show
NAME      TYPE SIZE USED PRIO
/dev/sdb2 partition 4G   0B   -2

mkswap 会在分区上写入 swap signature，swapon 激活它，swapoff 停用它。如果你用 mkfs.xfs 去格式化一个准备做 swap 的分区，那就要重头再来：先 wipefs -a /dev/sdb2 清掉 xfs 元数据，再 mkswap。关于 swap 有个现代建议：如果服务器内存充足且业务对延迟敏感，swap 优先级可以调低甚至不开；但如果业务有突刺型内存需求，还是留一点 swap 作为兜底更安全。这是取舍，不是必须。

4. 挂载与自动挂载：mount、/etc/fstab 与常见踩坑

4.1 mount 命令的基本用法与挂载点设计

格式化完成后，要让文件系统能被访问，必须挂载：

bash复制[root@localhost ~]# mkdir -p /data
[root@localhost ~]# mount /dev/sdb1 /data
[root@localhost ~]# df -h /data
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       100G  5.4M  100G   1% /data

挂载点设计是个容易被忽视的细节。我强烈建议为独立的数据分区创建独立挂载点，而不是挂到 /mnt 或 /media 这种通用目录下。原因有两点：第一，挂在 /mnt 下如果不注意，多个分区可能会互相覆盖；第二，如果你把 /dev/sdb1 挂载到 /opt 下已有的目录（比如 /opt/app），它会把原有目录中的文件“遮蔽”，从内核视角看，原目录内容并没有丢，但你在挂载期间看不到、也访问不到，非常容易造成误删误改。

还有一个细节：挂载点目录的权限。如果挂载点目录的 owner 不是当前用户，写入时会报 permission denied。这时候可以先 chown 挂载点，或者挂载时指定 uid/gid 选项，具体取决于文件系统。

4.2 /etc/fstab 的字段解析

mount 是临时挂载，重启后失效。要让分区每次开机自动挂载，必须写入 /etc/fstab。这个文件的每一行都有六列：

text复制UUID=3b3c7c71-...  /data  xfs  defaults  0 0
设备/UUID           挂载点  类型  选项      dump fsck

第一列：设备标识。推荐用 UUID，而不是 /dev/sdb1。原因前面说了，设备名可能漂移。
第二列：挂载点，必须存在且为空目录。
第三列：文件系统类型，如 xfs、ext4、swap。
第四列：挂载选项。defaults 是最常用的，实际包含 rw, suid, dev, exec, auto, nouser, async。如果不需要执行文件，可以写 noexec，安全加固时很常见。
第五列：是否用 dump 备份。一般写 0。
第六列：fsck 检查顺序。根文件系统写 1，其他写 0 或 2。写错可能导致开机异常。

swap 的 fstab 写法略有不同：

text复制UUID=5d9b1e11-...  swap  swap  defaults  0 0

写入 fstab 后，建议先执行一次：

bash复制[root@localhost ~]# mount -a

这条命令会读取 /etc/fstab 并挂载所有未挂载的条目，相当于“预演”。如果语法有误，会立即报错，而不会等到重启才暴露。这是测试 fstab 正确性的关键一步。

4.3 fstab 写错进不去系统的急救经验

fstab 写错是最常见的翻车场景之一。我见过最典型的情况是：blkid 里复制 UUID 时多复制了一个空格，或者 UUID 少了一位，重启后系统进入 emergency mode，提示类似：

text复制Welcome to emergency mode! After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" to boot into default mode.
Give root password for maintenance

这时候千万别慌。emergency mode 下系统会挂载只读的根文件系统，输入 root 密码登录后：

bash复制mount -o remount,rw /
vim /etc/fstab

把错误的 UUID 修正。如果你不确定正确的 UUID，用：

bash复制blkid

对照实际输出修正。修正后执行 mount -a 检查所有条目，没问题再 reboot。注意在 emergency mode 下，/etc/fstab 是只读的，必须先 remount,rw，否则 vim 保存会失败。

另一个常见错误是第六列写错：比如把非根分区写成了 1，开机时 fsck 会对该分区做完整检查，如果分区数据量大，启动极慢；更严重的是如果文件系统本身有异常，fsck 可能直接停在交互式修复界面，导致系统无法正常进入。

5. 扩容与在线调整：从 resize2fs 到 xfs_growfs

5.1 什么时候需要扩容，什么时候需要收缩

磁盘空间不够是运维中最常见的扩容场景。扩容分两个层面：分区扩容和文件系统扩容。在虚拟化/云环境里，通常是“底层先把虚拟磁盘调大”，但系统里的分区和文件系统不会自动跟着变大——这正是很多新手卡住的地方。

先说结论的普适逻辑：分区别在物理层，文件系统别在逻辑层。扩容时必须这两层都做，顺序是“先扩展分区，再扩展文件系统”。收缩则相反，必须先收缩文件系统，再收缩分区（ext4 支持，xfs 不支持）。下面分别展开。

这里提醒一下：如果是云盘（阿里云、腾讯云、AWS 等），通常控制台里扩容后，还要在系统里执行 growpart 或 fdisk 扩展分区，再用 resize2fs 或 xfs_growfs 扩展文件系统。不同云厂商有时会自动处理分区层，但文件系统层几乎都要手动做。

5.2 ext4 在线扩容完整流程

假设 /dev/sda 是 40G，/dev/sda1 是 39G 分区，底层把磁盘扩到了 80G。此时系统里：

bash复制[root@localhost ~]# lsblk
sda      8:0    0   80G  0 disk
└─sda1   8:1    0   39G  0 part /

分区还是 39G，需要把分区扩展到整块磁盘。首选工具是 growpart：

bash复制[root@localhost ~]# growpart /dev/sda 1
CHANGED: partition=1 start=2048 old: size=... end=... new: size=... end=...

growpart /dev/sda 1 是“把 sda 的第 1 个分区扩展到最后”。执行后 lsblk 能看到分区变大了。接下来扩展文件系统：

bash复制[root@localhost ~]# resize2fs /dev/sda1

resize2fs 会自动检测当前文件系统大小并扩展到分区大小。执行完毕后 df -h 就是新容量了。整个过程不需要卸载，是真正的在线扩容。

5.3 xfs 在线扩容：命令不同，逻辑相似

xfs 文件系统的扩容命令是 xfs_growfs，但它有个和 resize2fs 不一样的地方：xfs_growfs 接收的可以是挂载点，也可以是块设备：

bash复制[root@localhost ~]# growpart /dev/sda 1
[root@localhost ~]# xfs_growfs /data

或者：

bash复制[root@localhost ~]# xfs_growfs /dev/sda1

我习惯用挂载点写法，因为 xfs_growfs /data 更直观，而且它本身会检查挂载状态。执行后 df -h 确认新容量。

xfs 的硬限制是：不支持收缩。如果你误建了过大的 xfs 分区，想缩小是做不到的。这也是为什么在选型时，如果未来有缩容可能（比如临时测试盘、数据库文件），建议选 ext4 而不是 xfs。

5.4 交换分区的扩容与释放

swap 的扩容路径和普通分区不同。一个典型场景：swap 分区从 2G 扩到 4G。流程是：

bash复制[root@localhost ~]# swapoff /dev/sda2
[root@localhost ~]# fdisk /dev/sda   # 删除 /dev/sda2，重建相同起始扇区、更大大小的分区
[root@localhost ~]# partprobe
[root@localhost ~]# mkswap /dev/sda2
[root@localhost ~]# swapon /dev/sda2

这里有两个坑。第一个坑：swapoff 时必须保证系统内存有足够余量容纳正在使用的交换空间里的数据，否则 swapoff 会卡住或者触发 OOM。可以先看 free -h 里 swap 使用量，如果太高，先关闭部分大内存应用再操作。第二个坑：用 fdisk 删除并重建分区时，起始扇区必须和原来一致。如果起始扇区变了，分区上的数据全部作废。保险的方法是先 fdisk -l 把原起始扇区记下来，重建时手动指定。

新版 fdisk 在删除分区时会记住旧分区起始扇区，重建时默认值会自动匹配，但跨工具（比如用 parted）就不一定了。所以在操作前务必把原始分区信息打印出来存档。

6. 真实运维中那些让人头疼的分区细节

6.1 四块数据盘怎么规划：LVM 还是裸分区？

在实际部署中，如果服务器有多块数据盘，我建议先想清楚文件布局再决定用不用 LVM。LVM（Logical Volume Manager）的核心理念是把多个物理分区/磁盘聚合成一个卷组，再从卷组里切割逻辑卷。好处是逻辑卷可以在卷组内灵活扩容缩容，不需要把业务停下来。

LVM 带来的额外抽象层也伴随着复杂性。如果你的业务是固定的四块盘四块分区一一对应，而且未来扩容预期不频繁，直接用裸分区 + 挂载点更省心。如果你预计将来要“把五块盘合成一个大存储池”、“在线扩缩容”，那 LVM 是正解。

LVM 创建的基础命令链：

bash复制pvcreate /dev/sdb1 /dev/sdc1
vgcreate vg_data /dev/sdb1 /dev/sdc1
lvcreate -L 300G -n lv_data vg_data
mkfs.xfs /dev/vg_data/lv_data
mount /dev/vg_data/lv_data /data

xfs 文件系统直接挂在 LVM 逻辑卷上时，扩容顺序是：先 lvextend 扩展逻辑卷，再 xfs_growfs /data 扩展文件系统。注意顺序不能反。

6.2 分区表类型不对导致系统无法识别

我曾经遇到过一台老服务器，从旧机器拆下两块 4TB 硬盘，插到新机器上怎么都识别不了。后来发现这两块盘的 disklabel 是 MBR，而 4TB 磁盘在 MBR 下只能识别到前 2TB 空间。使用 parted 查看：

bash复制[root@localhost ~]# parted /dev/sdc print
Error: /dev/sdc: unrecognised disk label
Model: ATA WDC WD4003FZEX (scsi)
Disk /dev/sdc: 4001GB
Sector size (logical/physical): 512/4096B
Partition Table: unknown

显示 “unrecognised disk label” 或类似的未知标签时，说明磁盘的分区表已经无法被系统解析。这种情况多数是因为磁盘原本是另一个 RAID 控制器的产物，分区表里记录的是阵列时代的布局。解决办法是重建磁盘标签：

bash复制[root@localhost ~]# parted /dev/sdc mklabel gpt

这会丢掉所有分区信息。所以在做这个动作前，先想清楚：磁盘里有没有需要保留的数据？实在不确定，用 testdisk 尝试恢复分区表。

6.3 误删分区的后悔药：testdisk 的恢复思路

误删分区是每个管理员都可能遭遇的噩梦。我曾经有一次在 fdisk 里按 d 删错了一个分区，虽然没有按 w 保存，但当时的操作停留在内存里，一旦直接 w 就会毁掉分区表。事后补救的唯一可行路径是用 testdisk 恢复。

testdisk 的恢复核心思路：分区表只是记录分区起始位置和大小，格式化后的文件系统元数据中还存有超级块（superblock）等备份信息。只要这些元数据没有被动过，testdisk 就能扫描到并重建分区表。

用法大致是：

bash复制testdisk /dev/sdb

然后按界面选择 [Analyse] → [Quick Search]，它会扫描整个磁盘寻找可能存在的分区标识。找到后按 P 预览文件列表，确认无误后回车，选择 [Write] 写回分区表。写回后立刻执行 partprobe，然后 mount 验证。

恢复的成功率取决于一个关键因素：误删后是否对磁盘做了写入操作。如果在误删后马上 mkfs 或者把其他分区数据写进同一块盘，那恢复成功率直线下降。所以不小心误删分区后，第一件事是立刻卸载所有相关挂载，停止对该盘的一切写入，再考虑恢复工具。

6.4 这些命令在主流发行版上的细微差异

命令在 CentOS/RHEL 系和 Ubuntu/Debian 系上基本通用，但仍有几个差异值得留意。

NVMe 磁盘设备名是 /dev/nvme0n1，分区别是 /dev/nvme0n1p1，而不是 /dev/sda1。注意 growpart 扩展 NVMe 分区时写法差不多：growpart /dev/nvme0n1 1。
parted 和 fdisk 在 util-linux 版本差异下，输出格式略有不同，但功能一致。
/etc/fstab 语法在两大系完全一致，但 Ubuntu 默认启用 systemd，写错了 fstab 后 systemd 的报错方式和 RHEL 略有差异，核心救治流程相同。
有些发行版默认不装 growpart，CentOS 需要 yum install cloud-utils-growpart，Ubuntu 通常自带。需要提前确认。

另外对于嵌入式 Linux（很多热词里也提到嵌入式 Linux），fdisk、mkfs 等工具可能不在 busybox 里完整提供，但核心命令链路是一致的，只是可用的参数会少一些。这类环境我建议分区和格式化在宿主机上用完整工具链完成，再把做好文件系统的存储介质挂到设备上。

这些细节看起来琐碎，但在真实运维中往往就是“压死骆驼的最后一根稻草”。遇到问题时，先确认发行版和工具版本，再套用上面的流程，能少走很多弯路。

最后再分享一个我个人的操作习惯：每次分区扩容前，先把 lsblk -f、fdisk -l、df -h 的输出存到文件里，命名为 disk_before_YYYYMMDD.txt。出问题时有“现场记录”可查，没出问题时也能对比前后变化。这招帮我在不少紧急排障里省下了大把时间，建议你也试试。