當 SLES Btrfs 檔案系統變成唯讀時:重新掛載前請先診斷
確定 Btrfs 是否故意設定為唯讀、空間不足或在發生錯誤後保護數據,然後選擇適合該原因的恢復路徑。
如果 SUSE Linux Enterprise Btrfs 檔案系統報告“只讀檔案系統”,首先要確定它是故意以唯讀方式掛載的,還是在發生錯誤後切換到唯讀模式。在嘗試重新掛載之前,請檢查掛載選項、可用空間和核心日誌。使用 Snapper 回滾工具建立可啟動的系統快照;如果 Btrfs 記錄了 I/O 或元資料錯誤,請在再次寫入檔案系統之前保護資料並診斷儲存路徑。

替換/data為受影響的掛載點,或/替換為 root 掛載點。
findmnt -T /data -o SOURCE,FSTYPE,OPTIONS
sudo btrfs filesystem show /data
在第一個指令中,尋找選項中的 `--read-snapper`ro或 ` --read-snapper`。 Snapper 快照的唯讀模式預期會拒絕寫入操作。使用 `--read- snapper`配置的掛載點也可能是故意的。 Btrfs 在發生嚴重的交易、元資料或裝置錯誤後也可能切換到唯讀模式。在這種情況下,重複執行 `--read-snapper` 指令並不能修復問題,反而可能立即失敗。rwro/etc/fstabmount -o remount,rw
如果檔案系統被故意掛載為唯讀,其裝置運作正常,且核心日誌中沒有 Btrfs 或 I/O 錯誤,則可以將正常資料掛載重新掛載為讀寫:
sudo mount -o remount,rw /data
findmnt -T /data -o TARGET,OPTIONS
請勿將此命令用作已啟動的唯讀快照或因錯誤導致的唯讀檔案系統的復原命令。成功重新掛載僅確認檔案系統可寫入性,而非檔案系統完整性。

即使基本的磁碟視圖看起來一切正常,Btrfs 也可能出現可分配空間不足的情況,因為資料和元資料的分配是分開追蹤的。請同時檢查普通可用空間和 Btrfs 使用情況:
df -hT /data
sudo btrfs filesystem usage -T /data
如果系統報告故障No space left on device,但核心日誌未顯示裝置故障或結構錯誤,請在移除任何內容之前檢查 Snapper 的使用情況:
sudo snapper list
僅刪除保留策略允許遺失的快照,並sudo snapper delete SNAPSHOT_ID針對每個選取的 ID 執行對應操作。如果需要回滾選項,請保留一個已知良好的更新前快照;刪除快照會釋放空間,但會移除復原點。清理操作可能不會立即釋放空間,快照也無法修復 I/O 錯誤。請勿執行平衡操作來強制將唯讀檔案系統轉換為可寫入檔案系統;此操作會移動數據,其目的是解決已診斷出的健康可寫檔案系統上的分配問題。

要查找第一個 Btrfs、區塊設備、控制器或傳輸錯誤,而不僅僅是檔案系統變成唯讀的最終訊息:
sudo journalctl -k -b --no-pager | grep -Ei 'btrfs|I/O error|nvme|ata|scsi'
出現讀取失敗、校驗和不符、裝置遺失或 I/O 錯誤等訊息,說明問題並非簡單的ro掛載選項所致。請檢查報告的磁碟、控制器、RAID/HBA、SAN 或虛擬磁碟層以及供應商的健康狀況資訊。首先修復不穩定的硬體或連線問題。如果資料至關重要,請盡量減少寫入操作,並在嘗試修復檔案系統之前,請與管理員一起建立備份或區塊級映像。
| 你發現的 | 下一步行動 | 權衡 |
|---|---|---|
ro已配置或掛載點被有意設定為唯讀;無相關內核錯誤 | 如果掛載配置並非預期,請修正配置;或在確認設備正常後,重新掛載一個正常的可寫子磁碟區。 | 速度很快,但重新掛載無法清除因錯誤導致的唯讀狀態,也無法使唯讀快照變成可寫入狀態。 |
| 可啟動的根快照可以正常運作,該問題是在系統變更後出現的。 | 啟動並測試快照,然後運行sudo snapper rollback並重新啟動到預設條目。 | 將根子卷還原到快照狀態。排除在外或單獨的子卷中的資料不會被回滾。 SLES 15 SP7 僅在其預設根子磁碟區佈局和單一裝置根檔案系統下支援此回溯操作。 |
| 核心日誌包含儲存 I/O 錯誤或 Btrfs 結構錯誤 | 穩定儲存並保存資料;使用救援環境並升級以進行檔案系統特定的復原。 | 速度較慢,但避免了透過可寫入重新掛載來掩蓋未解決的硬體問題。 |
| 僅報告空間耗盡;未報告儲存錯誤。 | 檢查 Snapper 保留策略和允許的快照或資料釋放,然後重新檢查 Btrfs 使用情況。 | 以犧牲選定的復原點或檔案為代價來釋放容量。 |

在 SLES 系統中,可引導快照使用預設的 Snapper 根配置。根分割區必須在一個裝置上使用 Btrfs 檔案系統,引導程式必須支援該檔案系統,並且只有根子磁碟區會被回滾。提交之前請先驗證候選分區;如果不合適,請重新啟動至目前系統或復原環境。請參閱SLES 15 SP7 Snapper 回滾過程。
如果檔案系統無法掛載或核心訊息提示結構損壞,請啟動 SLES 救援系統或其他合適的復原環境,找到正確的設備,並確保在執行預設的唯讀檢查之前將其卸載:
sudo btrfs check /dev/DEVICE
請使用實際的 Btrfs 區塊設備,而不是掛載點佔位符。檢查過程可能需要時間和內存,並會報告結構性問題;但檢查結果並不能保證修復成功。請勿將其--repair作為常規的後續步驟。 Btrfs 文件警告稱,修復操作可能會使情況變得更糟,因此只有在接受資料風險並諮詢專家後才能進行。如果檢查報告錯誤或裝置有 I/O 故障,請諮詢 SUSE 支援或 Btrfs 專家。
儲存穩定且檔案系統以讀寫模式掛載後,sudo btrfs scrub start -B /data即可驗證校驗和。 Scrub 並非結構檢查器,它只能從已知良好的冗餘副本中修復損壞;在單一副本佈局中,它能偵測錯誤,但無法重建遺失的資料。請閱讀Btrfs scrub 文件。另請參閱SUSE 的 SLES 15 SP7 檔案系統指南、SUSE 的 Btrfs 復原文章以及Btrfs 檢查手冊。
選擇復原方式後,檢查掛載點是否具有預期的選項,並且可以執行安全寫入操作:
findmnt -T /data -o TARGET,SOURCE,FSTYPE,OPTIONS
sudo touch /data/.rw-check && sudo rm /data/.rw-check
若要回滾根快照,請先重新啟動系統並確認預設系統正常啟動。然後查看新的核心日誌,確認是否有重複出現的 Btrfs 或裝置錯誤。僅憑讀寫標誌並不能判斷系統是否健康:如果錯誤再次出現,請停止寫入操作並返回儲存診斷頁面。
確定 Btrfs 是否故意設定為唯讀、空間不足或在發生錯誤後保護數據,然後選擇適合該原因的恢復路徑。
準備鏡像通道,建立啟動金鑰,並在沒有直接網路存取的情況下引導 SLES 15 用戶端,同時保持管理員簽到所需的連線。
修復 YaST 透過 SSH 啟動 XIO 時出現的錯誤,驗證 X11 轉送和 xauth,並在不需要遠端視窗時切換到 ncurses 介面。
找到更新前的 Btrfs 快照,以唯讀方式測試它,並使用 Snapper 實現永久恢復,同時了解哪些資料保留在根回滾之外。
Send SLES system logs to a remote rsyslog collector over authenticated TLS, with certificate checks, outage buffering, and delivery tests.
使用 RAM、交換空間、核心和 Zypper 日誌來識別真實的記憶體壓力,保護軟體包狀態,並選擇更安全的 SLES 升級重試。
啟用 Debian 透過 SSH 進行的無人值守安全性更新,保留預設軟體套件來源,並透過 systemd 和 APT 日誌驗證計畫運作。
比較郵件投遞選項,在 Ubuntu 上配置 smartd,並驗證磁碟健康警告是否到達您的收件匣。
透過檢查 systemd-resolved、在需要時修復 resolv.conf 以及驗證上游 DNS 和應用程式解析,恢復 Debian 12 上的 DNS 查找。
讓 Ubuntu 偵測到你的顯示器或電視作為音訊輸出設備,在聲音設定中選擇它,如果缺少 HDMI,請檢查連接或 PipeWire 設備清單。