这是关于在硬件 RAID 上使用 LVM 管理的逻辑卷上的 ext4 文件系统，该逻辑卷使用 LUKS 加密。操作系统是通用的 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试将再次更新上次错误的时间戳，并再次写入系统日志。
在另一个 serverfault 帖子中，我发现了将磁盘映射器卷设置为只读然后再设置回读写的提示，但这也没有起到作用：Linux 软件 RAID 1 - 一个磁盘发生故障后，根文件系统变为只读
cryptsetup reload也一无所获。