當 SLES Btrfs 檔案系統變成唯讀時:重新掛載前請先診斷

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

終端機指令檢查 /data Btrfs 檔案系統是否以唯讀方式掛載,並列出其設備
此範例檢查掛載選項並識別支援 /data 的 Btrfs 裝置。

1. 如何區分有意設定的唯讀掛載和檔案系統錯誤

替換/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

請勿將此命令用作已啟動的唯讀快照或因錯誤導致的唯讀檔案系統的復原命令。成功重新掛載僅確認檔案系統可寫入性,而非檔案系統完整性。

2. 檢查空間壓力是否是真正的問題所在

終端範例比較普通可用空間與 Btrfs 已分配和未分配空間
將檔案系統可用空間與 Btrfs 分配詳情進行比較;範例值僅供參考。

即使基本的磁碟視圖看起來一切正常,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 錯誤。請勿執行平衡操作來強制將唯讀檔案系統轉換為可寫入檔案系統;此操作會移動數據,其目的是解決已診斷出的健康可寫檔案系統上的分配問題。

3. 選擇修復方案前,請先閱讀內核日誌。

終端機範例,顯示內核日誌中 Btrfs 和區塊設備 I/O 錯誤訊息
核心訊息可以區分空格壓力與讀取錯誤、校驗和錯誤或設備錯誤;所示行是範例。

要查找第一個 Btrfs、區塊設備、控制器或傳輸錯誤,而不僅僅是檔案系統變成唯讀的最終訊息:

sudo journalctl -k -b --no-pager | grep -Ei 'btrfs|I/O error|nvme|ata|scsi'

出現讀取失敗、校驗和不符、裝置遺失或 I/O 錯誤等訊息,說明問題並非簡單的ro掛載選項所致。請檢查報告的磁碟、控制器、RAID/HBA、SAN 或虛擬磁碟層以及供應商的健康狀況資訊。首先修復不穩定的硬體或連線問題。如果資料至關重要,請盡量減少寫入操作,並在嘗試修復檔案系統之前,請與管理員一起建立備份或區塊級映像。

4. 選擇符合證據且風險最小的恢復方案

你發現的下一步行動權衡
ro已配置或掛載點被有意設定為唯讀;無相關內核錯誤如果掛載配置並非預期,請修正配置;或在確認設備正常後,重新掛載一個正常的可寫子磁碟區。速度很快,但重新掛載無法清除因錯誤導致的唯讀狀態,也無法使唯讀快照變成可寫入狀態。
可啟動的根快照可以正常運作,該問題是在系統變更後出現的。啟動並測試快照,然後運行sudo snapper rollback並重新啟動到預設條目。將根子卷還原到快照狀態。排除在外或單獨的子卷中的資料不會被回滾。 SLES 15 SP7 僅在其預設根子磁碟區佈局和單一裝置根檔案系統下支援此回溯操作。
核心日誌包含儲存 I/O 錯誤或 Btrfs 結構錯誤穩定儲存並保存資料;使用救援環境並升級以進行檔案系統特定的復原。速度較慢,但避免了透過可寫入重新掛載來掩蓋未解決的硬體問題。
僅報告空間耗盡;未報告儲存錯誤。檢查 Snapper 保留策略和允許的快照或資料釋放,然後重新檢查 Btrfs 使用情況。以犧牲選定的復原點或檔案為代價來釋放容量。
啟動選單範例,其中可啟動快照清單中的較舊項目已反白顯示
選擇故障發生之前的快照,驗證只讀測試啟動,如果問題解決,則執行 Snapper 回滾。

在 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 或裝置錯誤。僅憑讀寫標誌並不能判斷系統是否健康:如果錯誤再次出現,請停止寫入操作並返回儲存診斷頁面。

留下評論

當 SLES Btrfs 檔案系統變成唯讀時:重新掛載前請先診斷

當 SLES Btrfs 檔案系統變成唯讀時:重新掛載前請先診斷

確定 Btrfs 是否故意設定為唯讀、空間不足或在發生錯誤後保護數據,然後選擇適合該原因的恢復路徑。

在離線網路中使用 SUSE Manager 註冊 SLES 15

在離線網路中使用 SUSE Manager 註冊 SLES 15

準備鏡像通道,建立啟動金鑰,並在沒有直接網路存取的情況下引導 SLES 15 用戶端,同時保持管理員簽到所需的連線。

讓 YaST 的 X11 轉送透過 SSH 正常運作

讓 YaST 的 X11 轉送透過 SSH 正常運作

修復 YaST 透過 SSH 啟動 XIO 時出現的錯誤,驗證 X11 轉送和 xauth,並在不需要遠端視窗時切換到 ncurses 介面。

使用 Snapper 安全地回滾失敗的 SLES 更新

使用 Snapper 安全地回滾失敗的 SLES 更新

找到更新前的 Btrfs 快照,以唯讀方式測試它,並使用 Snapper 實現永久恢復,同時了解哪些資料保留在根回滾之外。

Secure SLES Syslog Forwarding with rsyslog and Mutual TLS

Secure SLES Syslog Forwarding with rsyslog and Mutual TLS

Send SLES system logs to a remote rsyslog collector over authenticated TLS, with certificate checks, outage buffering, and delivery tests.

在重試之前追蹤 SLES 升級記憶體錯誤

在重試之前追蹤 SLES 升級記憶體錯誤

使用 RAM、交換空間、核心和 Zypper 日誌來識別真實的記憶體壓力,保護軟體包狀態,並選擇更安全的 SLES 升級重試。

在無頭伺服器上保持 Debian 12 安全更新運行

在無頭伺服器上保持 Debian 12 安全更新運行

啟用 Debian 透過 SSH 進行的無人值守安全性更新,保留預設軟體套件來源,並透過 systemd 和 APT 日誌驗證計畫運作。

使用 smartd 透過電子郵件取得 Ubuntu SMART 磁碟警告

使用 smartd 透過電子郵件取得 Ubuntu SMART 磁碟警告

比較郵件投遞選項,在 Ubuntu 上配置 smartd,並驗證磁碟健康警告是否到達您的收件匣。

Debian 12 DNS 查詢失敗:修正 systemd-resolved

Debian 12 DNS 查詢失敗:修正 systemd-resolved

透過檢查 systemd-resolved、在需要時修復 resolv.conf 以及驗證上游 DNS 和應用程式解析,恢復 Debian 12 上的 DNS 查找。

Ubuntu 24.04 無法顯示 HDMI 音訊?恢復輸出

Ubuntu 24.04 無法顯示 HDMI 音訊?恢復輸出

讓 Ubuntu 偵測到你的顯示器或電視作為音訊輸出設備,在聲音設定中選擇它,如果缺少 HDMI,請檢查連接或 PipeWire 設備清單。