修改 /etc/fstab 时，一定要逐行手动检查和处理，修改完成后立即执行 mount -a 进行验证；只要配置写错，系统在启动阶段就很可能直接卡死。更稳妥的操作方式是先使用 blkid 核对 UUID，提前创建对应挂载点，同时加入 nofail 选项，避免因挂载失败拖慢甚至阻塞系统启动。较为推荐的挂载参数组合是 defaults,noatime,errors=remount-ro,nofail 0 2。
修改 /etc/fstab 中的挂载配置项
CentOS 7 默认的磁盘挂载行为由 /etc/fstab 文件统一控制，所谓修改默认挂载配置，本质上就是调整其中某一行的内容：包括设备标识、挂载目录、文件系统类型、挂载参数、dump 值以及 fsck 检查顺序。虽然直接编辑该文件即可生效，但如果填写有误，往往会导致系统开机卡住、分区挂载失败等问题。
常见报错和异常现象包括：mount: special device UUID=xxx does not exist（通常是 UUID 写错或目标设备不存在）、failed to mount /data（多半是挂载点目录未提前创建）、系统启动停在 “A start job is running for dev-disk-by…”（一般是未配置 nofail，且磁盘当前不可用）。
- 必须通过
blkid重新获取并确认 UUID，不能直接沿用旧记录 —— 尤其在系统重装、磁盘迁移后，设备名可能发生变化，原来的/dev/vdb1很可能变成/dev/sdb1 - 挂载点目录（例如
/data）必须先执行mkdir -p创建，否则运行mount -a时会直接报错 - 生产环境建议务必加上
nofail选项，避免数据盘异常时影响整个 CentOS 7 系统的启动流程 0 2是更常见也更推荐的组合：第一个0表示不参与 dump 备份；第二个2表示这是非根文件系统，开机执行 fsck 时优先级低于根分区/（根分区通常为1）
为什么不能直接替换 /etc/fstab 里的路径字符串
直接使用 sed -i "s//old//new/g" /etc/fstab 这类全局替换方式，看起来效率很高，但在实际运维中风险并不低。举个典型场景：如果你想把 /home/app 改成 /www/app，而 /etc/fstab 中同时还存在 /home/app-backup，那么它也可能被一并替换成 /www/app-backup。最终结果就是，本来无需变更的挂载配置也被改掉，导致生成无效的挂载项。
更危险的情况是：如果原挂载路径是 /var，而你执行 sed -i "s/var/www/g"，就可能把其他包含 var 字符串的内容也一起替换掉。虽然像 relatime 这类参数不受影响，但某些自定义挂载选项中一旦包含相同字符串，就可能造成配置语法错误，影响系统正常挂载。
- 更安全的做法是逐行确认：先通过
df -h查看当前挂载设备，再使用cat /etc/fstab | grep "old_mount_point"精确定位唯一目标行，然后手动编辑 - 修改前一定先备份配置文件：
cp /etc/fstab /etc/fstab.bak - 修改后必须执行
mount -a测试，正常情况下不会有任何输出；如果出现报错，应立即使用restorecon -v /etc/fstab检查 SELinux 上下文是否正确（尤其是从其他 Linux 系统复制过来的 fstab 文件）
挂载选项 defaults 不够用，哪些参数值得加
defaults 实际展开后对应的是 rw,suid,dev,exec,auto,nouser,async，但对于很多数据盘或业务盘来说，这组默认参数并不一定最合适。比如 Web 服务常用的 /www 目录，通常更适合禁用 suid 和 dev 以降低提权风险；而日志盘、数据盘则建议增加 noatime，从而减少额外写入，提高磁盘 IO 性能。
noatime：关闭访问时间更新，可有效减少磁盘写放大，提升 IO 表现，适用于大多数数据盘和业务盘nobarrier：仅建议在带电池保护的 RAID 卡或 NVMe SSD 场景下启用，普通 SATA 硬盘不建议使用，否则存在数据丢失风险errors=remount-ro：当文件系统发生错误时自动以只读方式重新挂载，相比直接 panic 更安全、也更稳妥x-systemd.device-timeout=30：与 systemd 配合使用，设备挂载超时 30 秒后自动放弃，通常需要和nofail一起使用
完整示例：UUID=a1b2c3d4- /www ext4 defaults,noatime,errors=remount-ro,nofail 0 2
修改后测试不通过？重点检查这三处
很多人在修改完 /etc/fstab 后直接执行 reboot，结果导致系统无法正常进入。实际上，使用 mount -a 基本可以提前发现 95% 以上的问题，但仍有三个比较隐蔽的检查点经常被忽略：
lsblk -f输出里目标设备的FSTYPE为空？这通常说明分区尚未格式化，或者mkfs执行失败；例如mkfs.ext4 /dev/vdb1必须成功完成且不能出现 warningfindmnt -t ext4查不到新挂载点？需要确认当前是否由systemd接管挂载流程（CentOS 7 默认就是如此），此时往往需要执行systemctl daemon-reload && systemctl restart local-fs.target才能真正让配置生效- 挂载完成后执行
ls -ld /www，如果权限显示为dr-xr-xr-x，这通常是 ext4 挂载后的默认表现；此时可显式执行chmod 755 /www，或者在 fstab 中添加umask=022（通常不推荐，权限控制更适合由应用层处理）
最容易被忽视的一点是：即使修改 fstab 后 mount -a 测试通过，也不代表系统在下一次基于 systemd 的启动过程中一定能成功挂载 —— 因为 systemd 会并行处理所有挂载任务，若依赖关系未明确声明，仍可能因为时序问题而失败。若想进一步提高稳定性，更建议采用 UUID + nofail + systemd.automount 的组合方案（属于高级用法，这里不展开）。
