1. 课程导入与RHEL存储体系概览
在企业级 Linux 运维中，存储问题往往是最容易“牵一发而动全身”的部分：一块磁盘的命名变化可能导致挂载失败，一个文件系统的参数选择可能影响数据库吞吐，一次 LVM 扩容操作可能决定业务能否在线继续。本课程围绕 RHEL（Red Hat Enterprise Linux）的存储与文件系统展开，目标不是记住零散命令，而是建立一条从物理设备到应用可访问目录的完整认知链路，并能在真实环境中完成规划、配置、验证与排障。
学习目标
完成本课程后，你应当能够：识别 RHEL 中块设备的不同命名方式及其稳定性差异；理解分区表、LVM、文件系统、挂载点之间的层次关系；使用 lsblk、blkid、df、findmnt 等工具定位存储对象；根据业务需求选择 XFS 或 ext4；完成磁盘分区、PV/VG/LV 创建、文件系统格式化与持久化挂载；并在容量不足、设备识别异常、挂载失败等场景下按证据链排查。这些目标贯穿后续章节，本节先建立整体地图。
RHEL 存储栈的层次结构
RHEL 的存储栈可以自上而下理解为若干层，每一层向上提供服务，向下依赖更底层的对象。最上层是应用看到的目录，例如 /data、/var/lib/mysql；应用通过路径访问文件，而路径背后是已挂载的文件系统。文件系统之下是逻辑卷或分区，再往下是物理卷、磁盘或 SAN/iSCSI 提供的块设备。内核块层负责 I/O 调度、设备映射和多路径，最终落到物理介质或远端存储。
这个层次关系决定了排障顺序：应用报“磁盘满”，先看 df -h 确认文件系统使用率；若文件系统未满但写入失败，再看 lvs 确认 LV 是否已满；若 LV 未满，继续看 vgs、pvs 确认 VG 剩余空间和 PV 状态；最后才检查底层磁盘、多路径或 SAN 链路。反过来，如果底层磁盘掉线，上层文件系统可能进入只读或报 I/O 错误，因此不能只盯着应用日志。
块设备与文件系统：不是一回事
初学者最容易混淆的一点，是把“磁盘”和“文件系统”当成同一个东西。块设备是内核提供的按块读写的对象，例如 /dev/sdb、/dev/nvme0n1、/dev/mapper/vg_data-lv_data。它本身没有目录、没有文件名，只有扇区或块。文件系统则是在块设备之上建立的一套组织结构，负责管理 inode、目录项、空闲块和日志。只有执行 mkfs.xfs 或 mkfs.ext4 之后，块设备才具备“可挂载”的文件系统结构。
因此，一块新磁盘接入后，典型路径是：识别设备 → 创建分区或加入 LVM → 格式化为文件系统 → 创建挂载点 → 挂载 → 写入 /etc/fstab 实现开机自动挂载。每一步都有对应的验证命令，不能跳步。例如，未格式化的 /dev/sdb1 直接挂载会报“wrong fs type”或“bad superblock”；已格式化但未创建挂载点，mount 会提示目标目录不存在。
课程实验环境搭建
为了让后续实验可复现，建议准备一台 RHEL 9 虚拟机或云主机，配置至少 2 vCPU、4 GB 内存、40 GB 系统盘，并额外挂载 2～3 块 10～20 GB 的空数据盘。数据盘不需要预格式化，保留为裸设备，用于练习分区、LVM 和文件系统创建。若使用虚拟机，可在 VMware、KVM 或 VirtualBox 中添加虚拟磁盘；若使用云主机，可购买并挂载云硬盘。实验前请确认系统已注册或已配置本地仓库，以便安装 lvm2、xfsprogs、e2fsprogs 等工具。
# 查看系统版本与已识别磁盘
cat /etc/redhat-release
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT
# 确认 LVM 与文件系统工具可用
rpm -q lvm2 xfsprogs e2fsprogs
# 示例：查看某块数据盘是否已有文件系统
blkid /dev/sdb
建议在实验前对每块数据盘做一次“身份确认”：记录设备名、容量、是否已有分区或文件系统。若磁盘来自其他环境，可能残留旧分区表或旧文件系统，需要先清理。清理会破坏数据，因此只对确认无用的实验盘执行。常用做法是用 wipefs -a /dev/sdb 清除签名，再用 parted 或 fdisk 重新分区。生产环境务必先确认设备路径与业务影响，不能凭经验直接操作。
/dev/nvme1n1 而非 /dev/sdb，应以 lsblk 实际输出为准。