CentOS 服务器在启动过程中或运行阶段遇到文件系统无法挂载时，最常见的表现是系统卡在启动进度条、进入 emergency mode，或者手动执行 mount 命令后返回 wrong fs type、bad superblock、cannot find UUID 等提示。这类问题不一定代表磁盘已经损坏，很多时候只是设备名称漂移、挂载点目录不存在、fstab 配置失效或内核模块未加载。因此修复前应先建立清晰的排查顺序，避免直接对数据盘执行强制修复造成二次损坏。
一、先定位设备与配置层问题，避免盲目修复文件系统
挂载失败的第一层原因通常出现在设备识别和基础配置上。例如服务器更换了 PCIe 插槽或磁盘控制器后，原来的 /dev/sdb 可能变成 /dev/sdc，而 /etc/fstab 仍然引用旧的设备名，导致启动时无法挂载。此时执行 lsblk -f 可以查看当前内核识别到的块设备、分区结构以及文件系统类型，执行 blkid 可以获取每个分区的 UUID 和文件系统标识。两者结合能够快速判断是设备名称变化还是分区丢失。
另一个常见问题是挂载点目录不存在。如果 /etc/fstab 中配置了 /data 挂载点，但根目录下并没有创建 /data 目录，mount 命令就会直接失败。可以通过 ls -ld /data 检查目录是否存在，若不存在则用 mkdir -p /data 创建。还要注意根文件系统是否被挂载为只读状态，这会影响挂载点目录的创建和后续修复操作。执行 mount | grep root 可以查看根分区的挂载选项，如果出现 ro 则需要先重新挂载为读写，通常使用 mount -o remount,rw / 完成。
在确认设备名称和挂载点无误后，还需要查看内核日志中是否有更详细的 I/O 错误。执行 dmesg | tail -n 100 或查看 /var/log/messages，可以看到类似 XFS corruption、EXT4-fs error、I/O error on device 等底层信息。这些信息能够帮助判断故障是在文件系统层还是硬件层。如果日志中出现大量 I/O error，则应当先检查磁盘连线、RAID 卡状态和 SMART 数据，否则即使修复了文件系统，硬件问题仍然会导致后续损坏。
二、ext4 与 xfs 的修复命令及注意事项
CentOS 6 及更早版本默认使用 ext4 文件系统，CentOS 7 及之后的版本默认使用 xfs。两种文件系统的修复工具完全不同，混用会直接破坏元数据。对于 ext4，必须在卸载状态下执行 fsck -y /dev/sdb1，其中 -y 表示对发现的问题自动回答 yes。如果文件系统遭到较为严重的损坏，还可以加入 -f 参数强制检查，例如 fsck -yf /dev/sdb1。修复完成后再次手动挂载，观察是否能够正常读写。
对于 xfs 文件系统，普通检查与修复使用 xfs_repair /dev/sdb1。该命令会尝试在不破坏日志的情况下修复元数据，适用于大多数轻度损坏。若执行时提示日志已经损坏或无法挂载，可以加上 -L 参数重建日志，即 xfs_repair -L /dev/sdb1。需要注意 -L 会丢弃最近一段时间未被写入磁盘的日志条目，存在少量数据丢失风险，因此只有在普通 xfs_repair 无法完成时才建议使用。执行修复前同样要确保目标分区处于卸载状态，否则修复工具会拒绝运行或造成更严重的损坏。
实际工作中还可以先只做检查而不修复，例如使用 xfs_repair -n /dev/sdb1 查看损坏范围。这个只读检查不会修改数据，能够帮助评估风险。若检查结果显示大量 inode 或目录项损坏，且该盘数据并不重要，可以直接重新格式化；若数据重要，则应先使用 dd 或专业工具对磁盘做整盘镜像，再在镜像文件上进行修复操作，防止修复过程进一步破坏原始数据。
三、修复 /etc/fstab 与根文件系统挂载失败
如果根文件系统之外的普通分区无法挂载，多数时候通过上述步骤就能解决。但如果是根文件系统本身挂载失败，系统会进入 emergency mode，或者直接报 Kernel panic。此时需要启动 CentOS 安装 ISO 进入救援模式，在救援环境中挂载原系统的根分区，然后检查 /etc/fstab 文件。常见问题是根分区的 UUID 被错误修改，或者 /etc/fstab 中某一行配置写错，导致系统在启动时反复尝试挂载并失败。
进入救援模式后，先执行 blkid 获取正确 UUID，再挂载根分区到 /mnt/sysimage，编辑 /mnt/sysimage/etc/fstab。对于非关键数据盘，建议在挂载选项中添加 nofail，这样即使该盘暂时无法识别，系统也能正常启动而不进入紧急模式。示例配置如下：
UUID=8a2c4f1e-2d3b-4e5f-9a8b-7c6d5e4f3a2b /data xfs defaults,nofail 0 2
修改完成后不要立即重启，先执行 mount -a 验证所有 fstab 条目是否能够正确挂载。如果 mount -a 没有输出错误，再执行 systemctl daemon-reload 重新加载系统服务配置。这样做可以提前发现配置错误，避免重启后再次进入 emergency mode。对于使用 systemd 自动挂载的场景，还可以使用 systemd.mount 单元文件替代传统 fstab，但生产环境中 fstab 仍然是更直观和通用的方式。
四、NFS 与网络文件系统挂载失败排查
除了本地磁盘，CentOS 服务器还经常挂载 NFS 网络文件系统。NFS 挂载失败的排查路径与本地磁盘有较大差异。首先应确认网络连通性，使用 ping 或 nc -zv 服务器IP 2049 测试 NFS 端口是否可达。然后检查 rpcbind 和 nfs 服务是否正常，在客户端执行 showmount -e 服务器IP 可以查看服务器导出的共享目录列表。如果该命令超时或返回权限错误，说明问题不在客户端文件系统，而在网络或 NFS 服务器端配置。
挂载 NFS 时还要注意版本协商问题。较新的 CentOS 默认尝试 NFSv4，而旧服务器可能只支持 NFSv3，此时需要在 mount 命令中明确指定版本，例如 mount -t nfs -o vers=3 服务器IP:/share /mnt/nfs。对于需要开机自动挂载的 NFS 共享，建议在 fstab 中加入 _netdev 和 nofail 选项，防止网络未就绪时挂载失败阻塞启动流程。示例写法为 服务器IP:/share /mnt/nfs nfs defaults,_netdev,nofail 0 0。
完成挂载修复后，建议对系统进行一次完整的重启测试，观察启动过程中是否还会卡在挂载步骤。重启前确认所有文件系统已经卸载干净，或者使用 sync 刷写缓存。如果修复后仍然出现随机性挂载失败，可以进一步检查 /etc/mtab 与 /proc/mounts 的信息是否一致、内核模块是否加载完整，以及是否受到 SELinux 安全上下文影响。对于 ext4 和 xfs 文件系统，SELinux 标签异常一般不会阻止挂载，但会影响挂载后的文件访问，因此必要时可执行 restorecon -Rv /data 恢复默认安全上下文。