我希望这不是一个重复的问题。我见过几个类似的问题，答案是将相应的设备或分区列入黑名单。但就我而言，我不能这样做（见下文）。话虽如此：
在 debian buster x64 主机上，我创建了一个虚拟机（基于 QEMU）。假设虚拟机在块设备分区上运行/dev/sdc1。我已经在该分区上安装了 debian 系统，基本上是这样的（省略了一些步骤）：
#> mkfs.ext4 -j /dev/sdc1
#> mount /dev/sdc1 /mnt/target
#> debootstrap ... bullseye /mnt/target
然后我绑定安装了必要的目录（/dev等/sys），chroot 到/mnt/target，完成了来宾操作系统安装并启动了虚拟机。
虚拟机首次启动时没有出现任何问题。但是，随着每次虚拟机重新启动，虚拟机都会遇到更多问题，我正在按GRUB和initramfs提示进行修复，直到无法再进行修复，因为显然ext4文件系统已损坏。
因为我原本以为我做错了什么，例如ext4在启动虚拟机之前忘记卸载分区，所以我多次从头开始重复整个安装。每种情况的结果都是一样的：重新启动几次后，ext4文件系统损坏严重，无法修复。
无意中找到了原因，但不知道如何解决。我注意到e2fsck拒绝对该分区进行操作，声称该分区正在使用，尽管它尚未安装且虚拟机未运行。进一步调查发现，存在内核线程jbd2/sdc。
这意味着主持人内核访问该分区/文件系统上的日志。当我启动虚拟机时，客人内核当然也是这样做的。我几乎可以肯定文件系统的损坏是由于两个内核同时访问文件系统（尤其是日志）造成的。
我该如何解决这个问题？
我无法将主机上的相应磁盘或相应分区列入黑名单，因为我需要将它们安装在那里以准备或完成 chroot 中的来宾操作系统安装。另一方面，似乎不可能告诉主机内核在虚拟机启动后立即释放日志。
在过去的几年里，我已经以完全相同的方式安装了很多虚拟机，但在创建ext4文件系统时没有打开日志。因此，我对这些虚拟机没有遇到这个问题。
编辑1
如果相关的话，在安装分区并chroot到其中以完成来宾操作系统安装时，我使用以下命令：
cd /mnt
mkdir target
mount /dev/sdc1 target
mount --rbind /dev target/dev
mount --make-rslave target/dev
mount --rbind /proc target/proc
mount --make-rslave target/proc
mount --rbind /sys target/sys
mount --make-rslave target/sys
LANG=C.UTF-8 chroot target /bin/bash --login
卸载时，我只是这样做
umount -R target
该umount命令不会报告任何错误。
答案1
通过传递-o norecoveryto mount，您可以挂载文件系统而不使用日志。
手册页山, ext3 部分：
无恢复/无负载
安装时不要加载轴颈。请注意，如果文件系统未完全卸载，则跳过日志重播将导致文件系统包含不一致的情况，从而导致许多问题。