Linux磁盘管理核心：blkid与UUID挂载实战指南

破案了！别再被"UID"骗了，Linux磁盘管理的核心是blkid

很多刚接触 Linux 运维的同学，第一次看到blkid这个命令时都会懵一下：它和lsblk、fdisk、df这些常见的磁盘管理命令到底有什么区别？更让人困惑的是，很多文章喜欢把blkid的结果直接说成"查看磁盘的 UID 号"，这个说法对不对？

先说结论：blkid 确实是 Linux 下查看和管理磁盘身份标识的核心命令，它输出的 UUID（Universally Unique Identifier，全局唯一标识符）就是磁盘的"身份证号"，但"UID"这个说法容易造成误导。在 Linux 系统里，UID 通常指"用户 ID"（User Identifier），而 blkid 输出的是文件系统的 UUID 或 PARTUUID，两者完全是不同层面的东西。

更准确地说，blkid这个命令的真正价值不在于"查看某一个号"，而在于：它把块设备的类型、文件系统、UUID、PARTUUID、卷标等信息一次性呈现出来，是我们在做磁盘分区、格式化、挂载、配置 /etc/fstab、修复启动故障时必须依赖的底层工具。

这篇文章会从实际运维和开发场景出发，系统讲清楚：

• blkid到底是什么，它输出每一列的含义是什么；
• UUID、PARTUUID、UID 三者之间有什么区别，为什么不能混用；
• 在新装系统、多磁盘服务器、云服务器扩容等场景下，怎么用blkid结合lsblk、fdisk、/etc/fstab完成从识别磁盘到稳定挂载的完整流程；
• 日常运维中最容易踩的 5 个坑，以及背后的排查思路；
• 生产环境下的最佳实践。

无论你是正在准备 Linux 面试，还是刚接手一台真机服务器，这篇文章都值得先收藏再细看。里面所有命令都可以直接复制运行，我会尽量把每条命令的执行逻辑和预期结果写清楚。

1. 这篇文章真正要解决的问题

1.1 为什么 blkid 值得你花十分钟搞懂

先看一个真实场景。

假设你手头有一台新到手的 Linux 服务器，插了两块数据盘。你打算把其中一块格式化为 ext4 用来放数据库备份，另一块格式化为 xfs 用来放日志。你执行了lsblk看到了sda和sdb，也执行了fdisk -l看到了分区信息，一切看起来都很正常。

但问题来了：你重启系统之后，发现某个挂载点没挂上，数据库备份盘变成了一块"未知设备"。你再一看，原来系统启动时/etc/fstab里写的是/dev/sdb1，而重启后由于内核枚举顺序变化，/dev/sdb1已经变成另一块盘了。

这种混乱在真实环境中太常见了。无论是物理机、虚拟机还是云服务器，Linux 内核在每次启动时都可能按照不同的顺序枚举 SCSI/SATA/NVMe 设备。设备名/dev/sda、/dev/sdb并不是永久固定的，一旦拓扑变化、驱动加载顺序变化、或者你插拔了磁盘，原来的名字就可能对不上号。

这时，用 UUID 来挂载磁盘就成为了唯一稳妥的方案。而blkid正是获取 UUID 的最直接工具。换句话说：

如果lsblk是让你看到"磁盘长什么样"的工具，那么blkid就是让你看到"磁盘身份证号"的工具。

1.2 什么人最该读这篇文章

下面三类读者，这篇文章对你一定有帮助：

1. Linux 运维和 DevOps 工程师：日常需要管理服务器磁盘分区、扩容、挂载、迁移，必须掌握 UUID 挂载和/etc/fstab配置。
2. 准备 Linux 面试的求职者："如何用 UUID 持久化挂载磁盘""blkid 输出的是什么""/etc/fstab 里为什么要用 UUID 而不是设备名"，这些问题经常出现在 Linux 面试题和运维笔试题里。
3. 使用云服务器或虚拟机做开发的同学：扩容数据盘、挂载数据盘、修复启动失败时，blkid都是排障链路里的第一环。

1.3 读完本文你能获得什么

读完本文，你会清楚：

• 一条命令看清所有块设备的 UUID、PARTUUID、文件系统类型和卷标；
• 正确区分 UUID、PARTUUID、UID 的概念边界；
• 写出经得起重启验证的/etc/fstab挂载配置；
• 在磁盘识别异常、挂载失败、启动进入紧急模式时，用blkid快速缩小排查范围。

2. blkid 基础概念与核心原理

2.1 blkid 是什么

blkid是 Linux 系统中的一个命令行工具，全称可以理解为 "block device ID"，即"块设备标识"。它用于定位和显示块设备（如硬盘分区、文件系统、交换分区、LVM 卷、RAID 阵列等）的属性信息，核心功能包括：

• 显示文件系统类型（如 ext4、xfs、vfat、ntfs、swap 等）；
• 显示文件系统的 UUID；
• 显示分区的 PARTUUID；
• 显示卷标（LABEL）；
• 显示分区的 PARTLABEL。

在大多数 Linux 发行版中，blkid由util-linux软件包提供。CentOS、RHEL、Ubuntu、Debian 等主流发行版默认都会安装。

2.2 从一条真实输出读懂每一列

我在 CentOS 7 虚拟机里执行blkid，得到的典型输出如下：

[root@localhost ~]# blkid /dev/sda1: UUID="6c8f5d4e-2f3a-4f9b-9a0e-2ab1c3d4e5f6" TYPE="xfs" /dev/sda2: UUID="e7b4af2e-8f5d-4f9c-bca1-6f2a1c3d4e7a" TYPE="swap" /dev/sdb1: UUID="a1b2c3d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d" TYPE="ext4" PARTUUID="0f9a8b7c-6d5e-4f3a-9b2a-1c3d4e5f6a7b"

逐列拆解一下：

需要注意：/dev/sda1这种设备节点名只是系统层面的"门牌号"，它可能随着启动顺序、驱动加载顺序、总线扫描顺序而变化。UUID才是文件系统级的"身份证号"，在没有人为重新格式化的情况下，它几乎不会改变。

2.3 blkid 和 lsblk、fdisk、df 的区别

新手经常把blkid、lsblk、fdisk、df混在一起，这里用一个表格把它们的职责边界理清：

一句话总结：

• 你要"看磁盘有几块、大小多少、挂在哪"，用lsblk；
• 你要"看磁盘文件系统格式、UUID、能不能用 UUID 挂载"，用blkid；
• 你要"新建分区、删除分区、改分区表"，用fdisk或parted；
• 你要"看某块盘空间快满了"，用df -h。

2.4 UUID、PARTUUID、UID 三者之间的区别

这一节是全文最容易混淆的部分，单独拎出来讲。

UUID（Universally Unique Identifier，全局唯一标识符）

这是文件系统在格式化时生成的唯一标识，例如mkfs.ext4 /dev/sdb1时就会生成一个 UUID。它的核心特征是：

• 由文件系统格式化工具生成，写入文件系统超级块中；
• 同一文件系统的 UUID 在整个 Linux 系统中唯一；
• 重新格式化后，UUID 会改变；
• 挂载、/etc/fstab配置、日志定位时，优先使用这个。

PARTUUID（Partition UUID，分区表条目唯一标识）

这是分区表条目自身的标识，不是文件系统的标识。在 GPT 分区表下，每个分区条目都会有一个 PARTUUID；在 MBR 分割表下，blkid不一定显示 PARTUUID。它的典型用途是：

• 在 UEFI/GPT 启动环境中，通过root=PARTUUID=...指定根分区；
• 在systemd环境下标识分区；
• 在同一个磁盘上，即使文件系统被重新格式化，PARTUUID 通常也不会变化。

UID（User Identifier，用户 ID）

在 Linux 中，UID的默认含义是"用户 ID"，用于标识系统用户。/etc/passwd里每一行第三个字段就是用户的 UID。id root会输出uid=0(root)，这里的 UID 和磁盘没有任何关系。

所以，如果有人跟你说"blkid 查看磁盘的 UID 号"，你心里要清楚：他说的其实是 UUID，不是用户 ID。这种说法虽然无伤大雅，但在面试或技术讨论中，如果能准确区分，会显得你基础更扎实。

这里也顺便提一句，网上搜索时经常看到"uid转手机号""b站uid查成分"这类内容，那和 Linux 里的 UID 完全是另一码事，不要混淆。

3. 环境准备与前置条件

3.1 操作系统与权限要求

blkid命令在绝大多数 Linux 发行版上都可以直接运行，不需要额外安装软件包（除非你的系统被裁剪得非常精简）。本文示例基于以下环境，但整体思路在所有主流发行版上通用：

• 操作系统：CentOS 7 / CentOS 8 / Ubuntu 20.04 / Ubuntu 22.04 均可；
• Shell：bash；
• 权限：普通用户可以执行blkid查看部分信息，但为了获取完整输出和后续挂载操作，建议使用root用户或具备sudo权限的用户。

查看权限的简单方式：

id

如果输出中能看到uid=0(root)，说明当前就是 root 用户。如果显示的是普通用户，后续涉及挂载、格式化操作的命令需要加sudo。

3.2 确认 blkid 可用

先执行下面的命令确认blkid是否存在：

which blkid blkid -V

预期输出示例：

/usr/sbin/blkid blkid from util-linux 2.23.2 (libblkid 2.23.0, 22-LTS)

如果你的系统提示command not found，可以通过包管理器安装util-linux：

CentOS / RHEL：

sudo yum install -y util-linux

Ubuntu / Debian：

sudo apt update && sudo apt install -y util-linux

3.3 准备一块测试磁盘（强烈建议在虚拟机里操作）

本文后续涉及格式化、分区、挂载等操作，这些操作在生产环境中有较高风险。强烈建议先在虚拟机里新建一块干净的虚拟磁盘进行练习。

以 VMware Workstation 或 VirtualBox 为例，给虚拟机增加一块 10G 的虚拟磁盘，系统会自动识别为/dev/sdb（如果原来只有一块系统盘/dev/sda）。

添加完成后，先验证系统是否识别到新盘：

lsblk

预期输出中会出现一个没有挂载点、大小约 10G 的新设备，例如：

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 20G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 19G 0 part / sdb 8:16 0 10G 0 disk

到这里，环境就准备好了。下面进入核心操作环节。

4. 核心流程拆解：从识别磁盘到持久化挂载

这一节会完整走一遍"识别新磁盘 -> 查看 blkid 信息 -> 分区 -> 格式化 -> 用 UUID 挂载 -> 写入 /etc/fstab -> 验证重启可用"的全流程。

4.1 第一步：用 blkid 查看当前所有块设备属性

先直接运行：

blkid

如果你是普通用户，可能只看到部分内容，可以使用sudo blkid。另外我们增加一个更易读的显示方式：

blkid | column -t

column -t会让输出按列对齐，终端展示更整齐。

执行后，你会看到类似下面的输出：

/dev/sda1: UUID="6c8f5d4e-..." TYPE="xfs" /dev/sda2: UUID="e7b4af2e-..." TYPE="swap"

注意，此时新加的/dev/sdb还没有文件系统，所以blkid不会显示它的 UUID 和 TYPE。这是正常的。

4.2 第二步：用 fdisk 创建分区

对/dev/sdb进行分区操作。这里使用fdisk工具。注意：这块盘现在是测试盘，生产环境操作前一定确认设备名，防止误操作系统盘。

sudo fdisk /dev/sdb

进入交互界面后，按以下顺序操作：

• 输入n新建分区；
• 分区类型直接回车选择默认（p 主分区）；
• 分区号默认 1，直接回车；
• 起始扇区默认，直接回车；
• 结束扇区如果想用整块盘，直接回车；如果想分成两个区，可以输入+5G表示第一个分区 5G；
• 输入w保存并退出。

如果只创建一个分区占用整块盘，交互过程大致如下：

Command (m for help): n Partition type: p primary (0 primary, 0 extended, 4 free) e extended Select (default p): p Partition number (1-4, default 1): 1 First sector (2048-20971519, default 2048): Using default value 2048 Last sector, +sectors or +size{K,M,G} (2048-20971519, default 20971519): Using default value 20971519 Partition 1 of type Linux and of size 10 GiB is set Command (m for help): w The partition table has been altered!

退出后，让内核重新读取分区表：

sudo partprobe /dev/sdb

也可以用lsblk验证新分区是否出现：

lsblk /dev/sdb

预期输出：

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 10G 0 disk └─sdb1 8:17 0 10G 0 part

4.3 第三步：格式化并生成 UUID

分区建好后，还没有文件系统，blkid自然不会显示 UUID。我们把它格式化为 ext4：

sudo mkfs.ext4 /dev/sdb1

格式化完成后，再次执行blkid：

sudo blkid /dev/sdb1

此时输出应该变成：

/dev/sdb1: UUID="a1b2c3d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d" TYPE="ext4" PARTUUID="0f9a8b7c-6d5e-4f3a-9b2a-1c3d4e5f6a7b"

到这里，新分区拥有了自己的 UUID。这个 UUID 是唯一的，也是我们后续挂载的关键依据。

4.4 第四步：用 UUID 挂载

先创建挂载点，例如/data：

sudo mkdir -p /data

然后使用 UUID 手动挂载：

sudo mount UUID="a1b2c3d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d" /data

执行后用df -h验证：

df -h /data

预期输出：

Filesystem Size Used Avail Use% Mounted on /dev/sdb1 10G 45M 9.8G 1% /data

4.5 第五步：写入 /etc/fstab 实现开机自动挂载

手动挂载在重启后会失效。要持久化挂载，需要把配置写入/etc/fstab。

这一步是全流程中风险最高的操作，写错可能导致系统无法正常启动。

先备份现有的/etc/fstab：

sudo cp /etc/fstab /etc/fstab.bak

然后用blkid获取/dev/sdb1的 UUID：

sudo blkid /dev/sdb1

编辑/etc/fstab，在文件末尾追加一行：

sudo vim /etc/fstab

追加内容：

UUID="a1b2c3d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d" /data ext4 defaults 0 2

各字段说明：

特别提醒：如果你编辑的是系统根分区或 /boot 分区对应的行，务必格外小心。修改任何非测试分区之前，建议先用man fstab查看完整字段说明。

验证/etc/fstab配置是否正确的命令：

sudo mount -a

mount -a会按/etc/fstab的内容重新挂载所有条目。如果没有任何报错，说明配置语法基本正确。但这里有一个常见误区：mount -a通过不代表重启后一定顺利，因为启动时还会涉及systemd的设备等待和 fsck 检查。更稳妥的验证方式是重启系统，或者执行sudo umount /data后再次sudo mount -a，确认能自动重新挂载上。

4.6 第六步：重启验证

sudo reboot

重启完成后，执行：

blkid df -h /data

如果一切正常，/data应该自动挂载成功，并且显示的是/dev/sdb1对应的文件系统。这一步通过，说明你的 UUID 挂载配置经受住了真正的重启考验。

5. 完整示例与代码实现

下面把这套流程封装成一个可以在测试虚拟机上直接执行的完整脚本。强烈建议先跑脚本，再手动操作一遍，理解每一步的意义。

#!/bin/bash # 文件路径：/tmp/blkid_demo.sh # 功能：演示 Linux 磁盘管理中使用 blkid 查看 UUID 并持久化挂载的完整流程 # 警告：该脚本会把 /dev/sdb 整盘格式化为一个 ext4 分区，仅限测试环境使用！ set -e DISK="/dev/sdb" PART="${DISK}1" MOUNT_POINT="/data" echo "===== 1. 查看当前块设备 =====" lsblk echo "" echo "===== 2. 查看当前 blkid 输出（此时新盘无 UUID）=====" sudo blkid || true echo "" echo "===== 3. 对 ${DISK} 创建分区 =====" # 使用 fdisk 以非交互方式创建一个占满整盘的分区 echo -e "n\np\n1\n\n\nw" | sudo fdisk ${DISK} sleep 2 echo "===== 4. 让内核重新读取分区表 =====" sudo partprobe ${DISK} sleep 2 echo "===== 5. 格式化分区为 ext4 =====" sudo mkfs.ext4 ${PART} echo "===== 6. 使用 blkid 查看新分区 UUID =====" sudo blkid ${PART} echo "===== 7. 创建挂载点并挂载 =====" sudo mkdir -p ${MOUNT_POINT} DEV_UUID=$(sudo blkid -s UUID -o value ${PART}) echo "捕获到 UUID=${DEV_UUID}" # 注意：生产环境不要直接修改 /etc/fstab，建议先备份 sudo cp /etc/fstab /etc/fstab.bak echo "===== 8. 写入 /etc/fstab =====" echo "UUID=\"${DEV_UUID}\" ${MOUNT_POINT} ext4 defaults 0 2" | sudo tee -a /etc/fstab echo "===== 9. 执行 mount -a 验证 =====" sudo mount -a echo "===== 10. 最终验证 =====" df -h ${MOUNT_POINT}

运行方式：

chmod +x /tmp/blkid_demo.sh sudo /tmp/blkid_demo.sh

脚本中有一个很重要的写法：

DEV_UUID=$(sudo blkid -s UUID -o value ${PART})

这行命令的含义是：只输出指定分区的 UUID 字段，并且只要值，不要UUID=前缀。执行效果如下：

a1b2c3d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d

在 shell 脚本里自动捕获 UUID 时，这种写法非常实用。

另外，这里也给出几个常用的blkid参数速查：

# 查看所有块设备完整信息 sudo blkid # 只查看指定设备 sudo blkid /dev/sdb1 # 只输出 UUID 值 sudo blkid -s UUID -o value /dev/sdb1 # 只输出文件系统类型 sudo blkid -s TYPE -o value /dev/sdb1 # 输出为 key=value 格式 sudo blkid -o export /dev/sdb1

-o export的输出示例如下：

DEVNAME=/dev/sdb1 UUID=a1b2c3d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d TYPE=ext4 PARTUUID=0f9a8b7c-6d5e-4f3a-9b2a-1c3d4e5f6a7b

6. 运行结果与效果验证

6.1 如何判断每一步成功

这套流程中，每一步都有一个明确的"成功标志"：

6.2 如果失败，先看哪里

新手最容易在下面几个环节失败：

失败点 1：fdisk分区后看不到sdb1

执行sudo partprobe /dev/sdb让内核重新读取分区表。如果还是不出现，可以尝试重启虚拟机。有时候云服务器环境对分区表变更的感知会有延迟。

失败点 2：mount -a报错 "wrong fs type"

/etc/fstab里的文件系统类型和实际不符。用sudo blkid /dev/sdb1看 TYPE 字段，确保 fstab 里写的是ext4、xfs或vfat等实际类型。

失败点 3：mount -a报错 "UUID=... does not exist"

fstab 中写的 UUID 和blkid输出的 UUID 不一致。通常是复制时漏了字符或多了空格。彻底检查一遍，确认没有全角字符。

失败点 4：重启后进入 emergency mode

这通常意味着/etc/fstab有严重错误。在紧急模式下执行：

mount -o remount,rw / cat /etc/fstab blkid

找到错误行，先注释掉或修正，然后重启。这也是为什么前面强调要先备份/etc/fstab。

6.3 实际排障时的三条命令组合拳

排查磁盘挂载问题时，下面三组命令缺一不可：

lsblk blkid df -h

• lsblk看设备拓扑和挂载点；
• blkid看 UUID 和文件系统类型；
• df -h看已挂载文件系统的空间使用情况。

我把这称为"磁盘排障三角"，几乎所有磁盘相关问题的初步定位都可以通过它们完成。

7. 常见问题与排查思路

下面总结 5 个高频问题，这些都是我在实际运维和技术交流中看到的最容易踩坑的地方。

7.1 为什么重启后 /dev/sdb 会变成 /dev/sdc

现象：服务器重启后，原来挂载的某个分区找不到了，df -h里少了一个挂载点。

原因：Linux 内核在启动时枚举块设备的顺序并不总是固定的。插拔硬盘、升级内核、变更 BIOS/UEFI 启动顺序、新增 NVMe 磁盘，都可能导致/dev/sdX设备名变动。

解决：不要通过/dev/sdb1挂载，统一改用 UUID。出现问题时先用blkid确认实际 UUID，再检查/etc/fstab是否匹配。

7.2 为什么 blkid 看不到某个分区的 UUID

现象：执行blkid后，某个分区没有输出。

7.3 为什么 /etc/fstab 里用了 UUID 还是挂载失败

这可能是四个原因：

一是/etc/fstab里的 UUID 写错了，建议用blkid复制而不是手打。

二是文件系统类型写错了。例如blkid显示TYPE="xfs"，fstab 里却写了ext4。

三是 fstab 行的选项写错了，比如同时写了defaults和ro，或者包含不存在的选项。

四是挂载点目录不存在。fstab 不会自动创建挂载点目录，需要提前mkdir -p。

7.4 blkid 显示 UUID 相同怎么办

现象：两块盘执行blkid后 UUID 一样。

原因：最常见的是使用dd或Clonezilla做过整盘克隆，克隆盘会继承源盘的 UUID，或者手动修改过文件系统超级块。

解决：给克隆盘生成新 UUID。不同文件系统命令不同：

# ext2/ext3/ext4 重新生成 UUID sudo tune2fs -U random /dev/sdb1

# XFS 重新生成 UUID sudo xfs_admin -U generate /dev/sdb1

执行后再次用blkid确认。

注意：XFS 生成新 UUID 的操作在某些版本上要求文件系统处于未挂载状态，操作前做好数据备份。

7.5 UEFI 启动时 root 分区应该用 UUID 还是 PARTUUID

在 GRUB 启动配置中，你可能会看到root=UUID=...或root=PARTUUID=...。对于根文件系统，两种写法在多数发行版上都能工作，但如果你在 UEFI/GPT 环境中调试启动问题，建议根据 bootloader 的规范选择对应方式。如果引导程序通过 GPT 分区表定位，通常用PARTUUID；如果已经挂载了文件系统再交给内核，用UUID。

8. 最佳实践与工程建议

8.1 永远不要用 /dev/sdX 写死挂载关系

这是整个磁盘管理中最重要的一条纪律。

生产服务器的/etc/fstab里，不要出现/dev/sda1、/dev/sdb1这种写法。设备名不稳定，一旦变化就会导致挂载失败或挂载到错误位置。

正确的优先级是：

1. 优先使用UUID=...；
2. 文件系统支持且你熟悉卷标管理，可以使用LABEL=...；
3. 极少数特殊场景（例如云厂商脚本动态生成），才考虑设备名。

8.2 修改 /etc/fstab 前必备的"三板斧"

修改/etc/fstab这种关键配置，生产环境必须有安全保护措施：

# 1. 备份 sudo cp /etc/fstab /etc/fstab.bak.$(date +%Y%m%d%H%M%S) # 2. 校验挂载 sudo mount -a # 3. 确认无误后再持久化

如果改错了导致系统启动进入紧急模式，也不要慌。在紧急模式的维护 shell 中：

mount -o remount,rw / vi /etc/fstab

注释掉错误行或者修正它，保存后重启即可。

8.3 格式化前一定要确认设备名

很多磁盘事故都发生在一个环节：把/dev/sdb看成/dev/sda，然后执行了mkfs.ext4 /dev/sda，系统盘被格式化。

在生产环境执行格式化之前，至少做三件事：

# 1. 查看设备树，确认目标盘的挂载点和大小 lsblk # 2. 确认目标盘上没有数据分区 sudo blkid /dev/sdb # 3. 再次确认设备名 ls -l /dev/disk/by-id/ | grep sdb

另外，在/dev/disk/by-id/目录下，系统为每个磁盘建立了基于厂商和序列号的稳定链接，这也是我们确认物理磁盘身份的重要手段：

ls -l /dev/disk/by-id/

在多盘服务器上，通过序列号确认磁盘身份，比仅凭sda和sdb更可靠。

8.4 把 blkid 纳入日常巡检脚本

对于长期运行的服务器，建议把blkid纳入定期巡检脚本。下面是一个简单的巡检思路：

#!/bin/bash # 巡检：列出所有块设备的 UUID 和文件系统类型，对比是否发生异常变化 sudo blkid -o export > /tmp/blkid_$(date +%Y%m%d).txt

把每次输出的结果归档，一旦某次输出和上次不一致，就说明系统里发生了磁盘变更（新盘加入、磁盘格式化、克隆盘冲突等）。

8.5 关于云服务器的特殊建议

使用云服务器（阿里云、腾讯云、华为云等）时，磁盘管理有一些额外注意点：

• 云平台提供的"数据盘"在操作系统内看到的设备名一般是/dev/vdb、/dev/vdc或者/dev/nvme0n1，重启后设备名相对稳定，但依然建议使用 UUID 挂载；
• 初始化云盘后，最后用blkid确认文件系统；
• 云平台的"自动挂载"脚本有时会使用 block device 名，这时可以在脚本里加入blkid输出日志，方便排查；
• 扩容云盘后，如果lsblk看到磁盘容量已增加，但分区容量没变，需要用growpart扩容分区，再用resize2fs或xfs_growfs扩展文件系统。操作前务必读云厂商文档，不同厂商流程略有区别。

8.6 swap 分区的 UUID 管理

blkid也能查看 swap 分区的 UUID：

sudo blkid /dev/sda2 # /dev/sda2: UUID="e7b4af2e-8f5d-4f9c-bca1-6f2a1c3d4e7a" TYPE="swap"

对应的/etc/fstab写法：

UUID="e7b4af2e-8f5d-4f9c-bca1-6f2a1c3d4e7a" swap swap defaults 0 0

很多生产事故是因为迁移系统后 swap 的 UUID 没有同步更新，导致开机时 swap 挂不上。排查时可以blkid和/etc/fstab对照检查。

8.7 做好变更记录

磁盘分区、格式化、挂载都属于高风险变更。建议每次操作后，把下面的信息记录到运维文档或工单里：

• 操作时间；
• 操作的设备名和 UUID；
• 文件系统类型和分区布局；
• /etc/fstab的改动内容；
• 验证结果（df -h、blkid输出截图或文本）。

这看起来是文档工作，但在半年后排查问题时，它会帮你节省大量时间。

9. 总结与后续学习方向

本文从一条命令入手，把 Linux 磁盘管理中最容易被忽略、也最容易被误解的部分讲清楚了。核心收获可以归纳为四点：

第一，blkid是查看块设备 UUID、PARTUUID、文件系统类型和卷标的底层工具，它的输出是配置/etc/fstab、排查启动故障、确认磁盘身份的第一手依据。

第二，不要把设备名/dev/sda1当成稳定标识。Linux 系统的设备枚举顺序可能变化，真正稳定的是文件系统 UUID。多盘环境下，用 UUID 挂载才是正确的工程做法。

第三，UUID、PARTUUID、UID 三者概念不同。你平常说的"磁盘 UID"，在 Linux 语境下实际指 UUID；UID 默认是用户 ID，PARTUUID 则是 GPT 分区表条目标识。

第四，高风险操作（分区、格式化、改 fstab）都必须有风险控制手段：备份配置文件、测试环境先验证、生产环境确认设备名、操作完用blkid+df -h验证结果。

如果你准备继续深入学习，建议按下面顺序实践：

1. 在虚拟机里反复练习"新增硬盘 -> fdisk/parted 分区 -> mkfs 格式化 -> blkid 查看 UUID -> fstab 挂载 -> reboot 验证"这个闭环；
2. 学习 LVM（逻辑卷管理）的基本概念，理解 PV、VG、LV 和 UUID 的关系；
3. 练习磁盘故障修复，例如模拟/etc/fstab写错后进入 emergency mode 的恢复过程；
4. 了解systemd的.mount单元和/etc/fstab生成器之间的协作机制。

对于任何在真实服务器上进行的磁盘操作，最后再强调一次：先备份，再操作；先测试环境验证，再上生产；先用lsblk和blkid确认设备身份，再执行格式化或挂载。这套习惯比任何命令技巧都重要。