修復 SUSE Linux Enterprise 上的 Btrfs 唯讀檔案系統錯誤

當您嘗試在 SUSE Linux Enterprise Server (SLES) 上儲存檔案或更新服務時，Linux 會傳回「只讀檔案系統」的錯誤訊息。此資訊可能意味著掛載點被故意設定為唯讀、您啟動到了一個唯讀的 Snapper 快照，或者 Btrfs 偵測到問題並停止接受寫入操作以保護磁碟區。這些原因需要不同的處理方法。首先，確定涉及哪個檔案系統和掛載點；在檢查核心日誌並保護重要資料之前，請勿強制重新掛載或執行修復命令。

錯誤的意義

Btrfs 是一種寫入時複製 (copy-on-write) 的 Linux 檔案系統，在許多標準安裝中，它預設用作 SLES 的根檔案系統。 Btrfs子磁碟區是檔案系統中可獨立掛載的部分；快照則是子磁碟區在特定時間點的副本，它保留了未變更的資料區塊。 Snapper 和 SLES 啟動選單可以使用快照來從系統變更中復原。啟動快照會將包含的部分以唯讀模式掛載。此外，Btrfs 可以在偵測到某些結構錯誤後切換到唯讀模式，以避免進一步寫入。 SUSE 在其SLES 15 SP7 Snapper 指南中記錄了快照的行為；Btrfs 專案在其 tree-checker 文件中解釋了檔案系統結構檢查可以將磁碟區切換到唯讀模式，以防止進一步損壞。您的特定選單標籤和可用的復原選項可能會因 SLES 服務包和儲存佈局而異。

權限問題有所不同。「權限被拒絕」通常指向所有權或存取控制問題；「只讀檔案系統」（通常顯示為EROFS）指向檔案系統或子磁碟區的狀態。使用更改檔案權限chmod並不會將唯讀掛載點變為可寫入。

在你改變任何事之前

如果這是生產伺服器、資料庫磁碟區或重要資料的唯一副本，請在嘗試復原之前聯絡系統管理員並確認備份。在系統仍可讀的情況下，如果可以避免對故障設備造成壓力，請將最重要的檔案複製到單獨的、健康的儲存媒體上。發生嚴重錯誤後，Btrfs 檔案系統可能僅在記憶體中保留了最近的元資料變更；卸載或重新啟動可能會遺失這些未提交的變更。如果日誌中提及 I/O 錯誤、裝置消失或重複重置，請優先考慮儲存健康和資料保護，而不是恢復寫入作業。

不要將此btrfs check --repair作為常規的第一步操作。 Btrfs 專案警告說，修復模式可能會造成損壞，並且無法修復所有類型的損壞。也不要反覆強制執行讀寫重掛：如果核心出於某種原因保護了檔案系統，則此操作可能會立即失敗。

步驟 1：確定受影響的安裝點

使用寫入失敗的路徑。例如，如果某個服務無法寫入某個路徑/srv/app，請檢查該路徑，而不是假設根檔案系統有問題：

findmnt -T /srv/app -o TARGET,SOURCE,FSTYPE,OPTIONS

替換/srv/app為受影響的檔案或目錄。檢查輸出中的 Btrfs 來源、掛載目標以及 `--no-mount`或ro` --mount` 選項rw。目標可以是/單獨的資料掛載點或子磁碟區。在繼續操作之前，請記錄來源和目標。如果指令報告了其他檔案系統類型，則 Btrfs 特有的步驟不適用於該路徑。

檢查目前啟動過程中的核心訊息，找出檔案系統變成唯讀的原因：

sudo journalctl -k -b --no-pager | grep -iE 'btrfs|I/O error|read-only|readonly'

尋找 Btrfs 錯誤或「強制唯讀」訊息、校驗和或樹錯誤、裝置 I/O 故障以及裝置斷開連線。日誌行只能提供線索，不能提供完整的診斷結果。重啟前請保存相關訊息和時間戳，因為日誌對儲存或硬體支援團隊可能很有用。

步驟 2：檢查是否有有意建立的唯讀快照

如果伺服器是從 GRUB 中的可開機快照啟動的，則該快照中包含的檔案預設是唯讀的。這是一個用於檢查先前系統狀態的恢復環境；它並非自動恢復的永久系統。請與管理員確認啟動項，然後重新啟動並選擇正常的預設 SLES 啟動項（如果快照啟動是意外的）。 SUSE 文件指出，從快照啟動會將其包含的檔案系統部分以唯讀方式掛載，並在其SLES 15 SP7 Snapper 復原指南中描述了單獨的回溯過程。

即使父檔案系統以讀寫模式掛載，某個快照也可能是唯讀的。如果您有意使用快照，請在不進行任何更改的情況下對其進行檢查：

sudo btrfs property get -t subvol /path/to/subvolume ro

將路徑替換為子磁碟區的掛載路徑。結果會ro=true確認子卷屬性為唯讀；Btrfs 屬性參考文件中對此標誌有詳細說明。不要簡單地將 Snapper 管理或接收的備份快照切換為讀寫模式：只讀狀態可能是回滾或增量備份假設的一部分。如果需要執行唯讀操作，請使用受支援的 Snapper 工作流程或建立單獨的可寫子磁碟區。

步驟 3：檢查掛載設定和儲存狀態

如果findmnt報告ro和日誌中未顯示 Btrfs 或 I/O 錯誤，請檢查 `<path>` 中對應的掛載條目/etc/fstab。掛載點可能已被故意配置為唯讀，用於復原、裝置映像或資料保護策略。僅在與服務擁有者確認預期狀態後，才能變更配置。此外，請檢查系統是否使用事務性或唯讀根部署：SLES 在其事務性更新指南中記錄了此類配置及其維護工作流程。如果該條目明確設定為可寫，設備運作正常，且路徑不是唯讀快照，則管理員可以嘗試臨時重新掛載：

sudo mount -o remount,rw /mountpoint

請替換/mountpoint為指定的確切目標findmnt。此操作不會診斷或修復資料損壞。如果操作失敗、傳回錯誤或核心日誌顯示儲存問題，請停止操作並進入復原排程階段，而不是嘗試使用更多選項重試。

如果可能有容量問題，請檢查 Btrfs 檔案系統指派和裝置狀態：

sudo btrfs filesystem usage /mountpoint
sudo btrfs filesystem show /mountpoint

SUSE 指出，在 Btrfs 檔案系統上，普通的磁碟空間不足摘要資訊可能具有誤導性，因為資料和元資料是分開分配的。 Snapper 快照也可能佔用大量空間。但是，「裝置上沒有剩餘空間」並不等於 Btrfs 只讀錯誤；請確定應用程式實際收到的是哪一則訊息。不要為了驗證某個假設而刪除快照。請先確認快照的內容，並遵循對應的保留策略。請參閱SLES 15 SP7 檔案系統故障排除指南。

步驟 4：確定檔案系統是否需要恢復

如果核心日誌中出現 Btrfs 錯誤、裝置遺失或重新掛載被拒絕，請保留日誌並在修復工作之前安排經過驗證的備份或儲存層級快照。對於非根資料卷，請規劃維護視窗並在離線檢查之前將其卸載。對於根檔案系統，請使用 SUSE 安裝或救援介質，並按照適用於特定 SLES 版本和錯誤特徵的步驟進行操作。切勿猜測設備名稱：Btrfs 檔案系統可以跨越多個設備，因此請先確定所有成員以及正確的掛載點或設備識別碼。

SUSE 的 SLES 15 SP7 管理指南中有一個專門章節討論無法掛載的根 Btrfs 分區，並探討了該啟動失敗的恢復選項。但這些說明並不意味著每個已掛載的唯讀檔案系統都應該清除其日誌。上游的btrfs-rescue 手冊解釋說，清除btrfs rescue zero-log日誌僅用於掛載期間的某些日誌重播失敗，並且可能會丟棄自上次提交交易以來的所有變更。只有當記錄的錯誤與文件中所述的情況相符，且復原計畫考慮到了可能的資料遺失時，才應使用此方法。

btrfs check預設情況下，btrfs-check 在未掛載的檔案系統上以唯讀方式運作。在初步評估時，請保持此狀態，並將輸出結果分享給 SUSE 支援團隊或 Btrfs 專家。上游btrfs-check 手冊明確警告，切勿在沒有經驗豐富的使用者或開發人員指導的情況下使用--repair此工具。切勿在已掛載且正在變更的檔案系統上執行離線檢查程序。

步驟 5：驗證恢復狀況

問題解決後，僅當恢復計劃需要時才重新啟動。然後findmnt -T /path -o TARGET,SOURCE,FSTYPE,OPTIONS再次使用並確認目標掛載點具有讀寫權限。檢查核心日誌中是否有新的 Btrfs 或 I/O 錯誤。最後，驗證受影響的服務或應用程式是否可以正常運行，並確認備份仍然可用。僅憑重新掛載成功並不能證明儲存設備已恢復正常。

如果檔案系統還原到唯讀模式、裝置中斷連線或錯誤持續發生，請停止寫入操作，並記錄日誌、findmnt輸出、Btrfs 裝置清單、SLES 服務包等級和儲存控制器詳細資訊，以便及時上報問題。這些資訊有助於區分有意建立的快照或掛載選項與媒體、連接、驅動程式或檔案系統損壞，並避免將保護性的唯讀狀態演變成更大的復原問題。