這是關於邏輯磁碟區上的 ext4 檔案系統，該系統磁碟區由硬體 RAID 上的 LUKS 加密上的 LVM 進行管理。作業系統是通用的 Ubuntu 22.04 LTS。
不幸的是，RAID 最近失敗了，檔案系統當時被重新映射為唯讀。停止所有應用程式寫入該檔案系統後，如果運氣好的話，RAID 可以完全恢復。而且，更幸運的是，檔案系統仍然可以完全讀取復原的資料！而且e2fsck連錯誤都沒有發現。
那麼一切都好嗎？不幸的是，沒有。不幸的是，有相當多（數百兆位元組）的未寫入資料仍然殘留在記憶體中，我不知道如何將其取出到磁碟。這就是為什麼我還沒有重新啟動，這也是我不想重新啟動的原因，因為修復所有丟失資料的資料庫檔案將是一項艱鉅的工作。未寫入資料的存在可以透過以下方式輕鬆驗證：
sync ; grep Dirty /proc/meminfo
通常只產生幾千字節，但在我的情況下產生數百兆位元組。不幸的是，我不知道資料掛在各種核心驅動程式的哪個層級：實體磁碟快取、磁碟區組之一或實際檔案系統。
目前已嘗試修復
我的第一次嘗試是透過以下方式將仍然只讀的檔案系統重新掛載為讀寫：
mount -o remount /dev/mapper/vg1-data
不幸的是，這會產生錯誤訊息：
mount: /data: cannot remount /dev/mapper/vg1-data read-write, is write-protected.
然而，實際卷是可讀寫的，可以透過以下方式驗證：
cat /sys/block/dm-*/ro
0它給出了設備映射器控制下的所有內容的結果，包括 RAID 頂部的捲。實際設備本身也是如此sd。另外：
dmsetup info vg1-data
將卷的狀態報告為ACTIVE。ACTIVE (READ-ONLY)如果狀態是唯讀的，它會將狀態報告為。同樣，lvs顯示 的正常屬性-wi-ao----。
一條大線索，檔案系統的讀寫能力實際上不是問題的根源，可以透過 獲得tune2fs -l。除許多其他統計資料外，這還會列印有關已安裝檔案系統上最後一個錯誤的資訊：
Last error time: Wed Jan 17 18:47:43 2024
Last error function: ext4_remount
Last error line #: 5822
Last error err: EBUSY
發生該錯誤時，系統日誌中寫入了以下神秘行：
EXT4-fs error (device dm-N): ext4_remount:5822: comm mount: Abort forced by user
當我透過以下方式明確強製卷進入只讀模式時：
dmsetup table vg1-data | dmsetup reload -r vg1-data
dmsetup resume vg1-data
dmsetup info vg1-data
然後進一步的重新mount嘗試不再更新「上次錯誤時間」時間戳，但會產生相同的（現在顯然是正確的）錯誤訊息。當我dmsetup再次使用該磁碟區進行讀寫後，進一步的重mount試將再次更新最後一個錯誤的時間戳，並再次寫入系統日誌。
在另一個伺服器故障貼文中，我發現將磁碟映射器磁碟區設定為唯讀然後傳回讀寫的提示，但這也沒有達到目的：Linux 軟體 RAID 1 - 根檔案系統在一個磁碟故障後變成唯讀
cryptsetup reload也一無所獲。