問題描述

Linux系統運行過程中可能突然進入文件系統只讀狀態，用戶執行寫入操作時終端提示"Read-only file system"，表現為無法創建、修改或刪除文件，甚至部分系統命令因無法寫入臨時文件而報錯。此類問題通常伴隨系統響應緩慢或服務異常，嚴重影響服務器穩定性，需及時定位并修復。

問題原因分析

導致Linux系統文件系統只讀狀態的核心原因是文件系統完整性受損，常見誘因包括：

1. 非正常關機：如突然斷電、系統崩潰或強制重啟，導致文件系統元數據（如inode、塊位圖等）未正確更新；

2. 硬件故障：磁盤壞道、控制器錯誤或存儲設備連接異常，引發文件系統讀寫錯誤；

3. 日志損壞：ext4等文件系統的journal日志文件因I/O異常損壞，系統自動切換為只讀模式以避免進一步數據損壞；

4. 配置錯誤：`/etc/fstab`中文件系統掛載參數誤設為`ro`（只讀），導致系統啟動時以只讀模式掛載分區。

修復前置說明

文件系統修復過程中可能存在數據丟失風險，尤其是當文件系統損壞較為嚴重時。操作前務必通過`rsync`、`tar`等工具對重要數據進行完整備份，并對關鍵分區創建快照（若存儲設備支持）。對于生產環境服務器，建議在低峰期執行修復操作，并提前制定回滾方案。

修復步驟詳解

一、定位只讀掛載點

通過`mount`命令查看當前系統掛載狀態，重點關注文件系統類型為`ext4`、`xfs`等，且掛載選項中包含`ro`（只讀）的分區。例如：

```bash

mount | grep "ro,"

```

輸出示例可能包含：`/dev/vdb1 on /home type ext4 (ro,relatime,data=ordered)`，其中`/dev/vdb1`即為異常只讀分區。同時，需檢查`/etc/fstab`中對應分區的掛載參數，確認是否誤配置為`ro`，避免修復后因配置錯誤再次出現只讀狀態。

二、安全卸載目標分區

執行`umount`命令卸載只讀分區：

```bash

umount /dev/vdb1

```

若提示"device is busy"，表明有進程正在占用該分區。可通過以下方式定位并終止占用進程：

- 使用`fuser -m /home`查看占用分區的進程PID列表（`/home`為掛載點）；

- 使用`fuser -mk /home`強制終止占用進程（`-k`參數發送SIGKILL信號）；

- 或通過`lsof | grep /home`查看具體打開的文件，針對性停止相關服務（如`systemctl stop nginx`）。

三、執行文件系統修復

使用`fsck`（File System Consistency Check）工具對異常分區進行強制修復。根據文件系統類型選擇對應參數：

- 對于ext4文件系統：

```bash

fsck -fvy /dev/vdb1

```

參數說明：`-f`強制檢查（即使分區已掛載且無錯誤）、`-v`顯示詳細修復過程、`-y`自動修復所有問題（避免交互式確認）。

- 對于xfs文件系統：需使用`xfs_repair`命令：

```bash

xfs_repair -L /dev/vdb1

```

修復過程中需密切關注終端輸出，若提示"inode corrupt"或"block bad"等嚴重錯誤，建議先備份數據后再繼續修復。

四、重新掛載并驗證

修復完成后，重新掛載分區為讀寫模式：

```bash

mount -o remount,rw /home

```

或通過`mount -a`重新掛載`/etc/fstab`中所有未掛載的分區。隨后通過`mount | grep /home`確認掛載選項已變為`rw`（讀寫），并測試文件寫入功能（如`touch /home/test.txt`）。若之前停止了相關服務，需重新啟動（如`systemctl start httpd`），并觀察系統日志確認服務正常運行。

五、后續監控與預防

修復后建議使用`dmesg`或`journalctl`查看系統日志，確認無磁盤I/O錯誤持續報出。對于頻繁出現文件系統問題的服務器，需檢查磁盤健康狀態（如`smartctl -a /dev/sdb`），必要時更換故障磁盤。同時，通過`systemctl enable --now fstrim`啟用trim工具（SSD環境）或定期執行`fsck -t ext4 -M /dev/vdb1`（定期檢查），降低文件系統損壞風險。