当服务器出现磁盘无法写入、文件创建失败、日志无法记录、应用报错或系统挂载只读等问题时，通常意味着 EXT4 文件系统已经检测到异常并主动保护数据，进入只读模式以防止进一步损坏。这类问题在生产环境中非常棘手，因为它可能导致数据库写入失败、网站服务中断、缓存无法更新，严重影响业务连续性。
EXT4 文件系统错误主要来源于两类原因：硬件层与软件层。硬件层包括磁盘老化、坏块、SSD 寿命耗尽、RAID 控制器异常、存储阵列故障或突然断电导致缓存未写入；软件层则包括系统异常关机、未正确卸载挂载设备、内核 panic 或中断导致的 journal 日志未完成提交、应用或脚本错误导致元数据异常等。无论原因如何，当 EXT4 发现 inode、块位图、超级块或日志不一致时，会自动将文件系统挂载为只读模式以保护数据，这意味着任何写入操作都会失败。
排查此类问题的第一步是确认文件系统是否已经进入只读模式。可以使用以下命令检测挂载状态：
mount | grep "on / "如果输出显示 ro(read-only)，说明根分区或对应挂载点已被强制只读。同时，可以尝试在挂载点创建文件验证：
touch /tmp/testfile若返回 “Read-only file system”，则文件系统确实无法写入。接下来需要查看内核日志，确认 EXT4 报错信息：
dmesg | grep -i ext4常见报错包括 “EXT4-fs error”，"journal has aborted"，"inode checksum invalid"，"metadata corruption detected" 等。通过这些日志，可以判断是元数据损坏、日志异常，还是硬件出现 I/O 错误。
在确认文件系统错误后，核心修复工具是 fsck(文件系统检查与修复工具)，它能够扫描 EXT4 的 inode、块位图、目录结构、超级块及日志元数据，并尝试修复异常。在使用 fsck 前，必须确保文件系统未被挂载或已挂载为只读，否则可能造成进一步破坏。如果是根分区，需要进入救援模式或 LiveCD 环境。非根分区可先卸载：
umount /dev/sda1如果提示设备正忙，可以通过 lsof 或 fuser 查看占用进程：
lsof | grep /dev/sda1或强制卸载：
umount -l /dev/sda1完成卸载后，即可执行 fsck 进行修复：
fsck -f /dev/sda1其中 -f 表示强制检查，即使文件系统标记为干净也会执行完整扫描。在修复过程中，fsck 会逐步检查 inode、目录、块位图、引用计数和组摘要信息，并在发现错误时提示修复。如果希望自动修复所有可修复问题，可以使用：
fsck -y /dev/sda1在扫描中，最常见的修复类型包括 orphan inode(孤儿 inode)，这是文件删除时 journal 未同步导致的孤立元数据，fsck 会自动移动这些 inode 到 lost+found 目录；超级块损坏，EXT4 会提供多个备用超级块，fsck 可以使用备用超级块进行修复；块位图错误或 inode 校验和不一致，fsck 会根据日志信息尝试恢复正确状态。
如果 fsck 修复过程中出现严重错误，如无法找到物理卷或设备 I/O 错误，可能意味着硬盘存在物理问题。这时需要结合硬件检测工具进行进一步排查，例如使用 SMART 检测硬盘健康状态：
smartctl -a /dev/sda关注指标如 Reallocated_Sector_Ct、Pending_Sector_Ct、Offline_Uncorrectable 等，如果指标异常，应尽快备份数据并更换硬盘。对于云服务器，可联系服务商迁移数据或更换存储卷。
在硬件确认正常的情况下，如果 fsck 完成修复，文件系统通常可以恢复写入功能，但仍建议检查日志是否仍有残留报错：
dmesg | grep -i ext4若日志清晰无报错，即可重新挂载文件系统：
mount /dev/sda1 /mnt挂载后，可以在挂载点创建文件进行验证，并将原先只读状态更改为读写挂载：
mount -o remount,rw /mnt对于根分区修复完成后，应重启服务器，确保系统在正常读写模式下运行，并观察启动日志是否仍存在 EXT4 错误。
此外，为防止未来再次发生写入失败，运维人员需要从根本上排查问题原因，包括硬件健康状态、断电保护、应用写入行为、定期 fsck 检查计划等。对数据库、日志、缓存等频繁写入的目录，应定期监控磁盘使用情况，并设置报警阈值。对于生产环境中重要数据，必须保持定期备份，避免因文件系统错误导致业务数据丢失。
在某些特殊情况下，如果文件系统反复出现只读或 fsck 修复不彻底的问题，可以考虑重建 EXT4 文件系统并恢复数据。操作流程通常是：备份数据 → 格式化分区 → 创建新文件系统 → 恢复数据。虽然这种方法风险较高，但在严重元数据损坏、块设备老化或频繁错误的情况下，是确保系统长期稳定运行的有效手段。
