これは、ハードウェア RAID 上の LUKS 暗号化で LVM によって管理される論理ボリューム上の ext4 ファイルシステムに関するものです。オペレーティング システムは汎用の Ubuntu 22.04 LTS です。
残念ながら、最近 RAID に障害が発生し、その時点でファイルシステムが読み取り専用に再マップされました。そのファイルシステムへの書き込みアプリケーションをすべて停止した後、運が良ければ RAID を完全に復元できました。さらに運が良ければ、復元されたデータでファイルシステムを完全に読み取り可能になります。e2fsckエラーも見つかりませんでした。
それで、すべては大丈夫でしょうか? 残念ながら、そうではありません。残念ながら、かなりの量 (数百メガバイト) の未書き込みデータがまだメモリ内に残っており、それをディスクに取り出す方法がわかりません。これが、まだ再起動していない理由であり、また、失われたデータを含むすべてのデータベース ファイルを修復するのは大作業になるため、再起動したくない理由でもあります。未書き込みデータの存在は、次の方法で簡単に確認できます。
sync ; grep Dirty /proc/meminfo
通常は数キロバイトしか得られませんが、私の場合は数百メガバイトになります。残念ながら、さまざまなカーネル ドライバーのどのレベルにデータが残っているかはわかりません。物理ディスク キャッシュ、ボリューム グループの 1 つ、または実際のファイル システムです。
これまでに試みられた修理
私の最初の試みは、まだ読み取り専用のファイルシステムを、次のようにして読み取り/書き込みとして再マウントすることでした。
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
これは、RAID 上のボリュームを含む、デバイス マッパーの制御下にあるすべてのものの結果を示します0。実際のデバイス自体についても同様です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
そのエラーが発生した時点で、次の不可解な行が syslog に書き込まれます。
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試行すると、最後のエラーのタイムスタンプが再度更新され、syslog にも再度書き込まれます。
別の serverfault の投稿で、ディスク マッパー ボリュームを読み取り専用に設定してから読み取り/書き込みに戻すというヒントを見つけましたが、それでもうまくいきませんでした。Linux ソフトウェア RAID 1 - 1 つのディスクに障害が発生するとルート ファイルシステムが読み取り専用になる
cryptsetup reload何も達成できませんでした。