カーネルがext4パーティションのログにアクセスするのを防ぐ方法は?

カーネルがext4パーティションのログにアクセスするのを防ぐ方法は?

重複する質問ではないことを願っています。いくつかの同様の質問がありましたが、その答えは、そのデバイスまたはパーティションをブラックリストに追加することです。しかし、私の場合はそうすることはできません(下記参照)。と言った:

Debian Buster x64ホストでQEMUベースの仮想マシンを作成しました。仮想マシンがブロックデバイスパーティションで実行されているとします/dev/sdc1。デフォルトでは、次のようにこのパーティションにDebianシステムをインストールしました(一部の手順は省略されています)。

#> mkfs.ext4 -j /dev/sdc1
#> mount /dev/sdc1 /mnt/target
#> debootstrap ... bullseye /mnt/target

/devその後、必要なディレクトリ(など/sys)をバインドマウントしてルートを変更し、/mnt/targetゲストOSのインストールを完了してVMを起動しました。

問題なく仮想マシンが初めて起動しました。ただし、VMを再起動するたびにVMに問題が発生し、ファイルシステムが破損しているため、問題を解決できなくなるまで問題を解決するようにGRUB求められます。initramfsext4

ext4最初からインストール全体を何度も繰り返しました。最初は、仮想マシンを起動する前にパーティションをアンマウントするのを忘れてしまうなど、何かが間違っていると思ったからです。各ケースの結果は同じです。数回再起動すると、ext4ファイルシステムが回復できないほど深刻に破損します。

偶然原因を見つけましたが、解決策がわかりません。e2fsckパーティションがマウントされておらず、仮想マシンが実行されていないにもかかわらず、パーティションが使用中であると主張し、パーティションの操作が拒否されたことを確認しました。さらなる調査はカーネルスレッドが存在することを示しましたjbd2/sdc

これは意味する所有者カーネルはこのパーティション/ファイルシステムのログにアクセスします。仮想マシンを起動すると、ゲストカーネルも確実にこれを行います。ファイルシステム(特にログ)に同時にアクセスする2つのコアがあるため、ファイルシステムが破損することはほぼ確実です。

この問題をどのように解決できますか?

chrootでゲストOSのインストールを準備または完了するには、ホストにそのディスクまたはパーティションをマウントする必要があるため、ホストのディスクまたはパーティションをブラックリストに追加することはできません。一方、仮想マシンが起動した直後にログを解放するようにホストカーネルに指示することは不可能です。

私は過去数年間で同じ方法で多くの仮想マシンをインストールしましたが、ext4ファイルシステムを作成するときにログをアクティブにしませんでした。したがって、これらのVMにはこの問題はありません。

編集1

該当する場合は、パーティションをマウントし、パーティションにルートを指定してゲストOSのインストールを完了するときに、次のコマンドを使用します。

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 norecoveryに渡すと、mountジャーナリングを使用せずにファイルシステムをマウントできます。

マニュアルページ、ext3部分:

回復なし/ロードなし

インストール時にジャーナルをロードしないでください。ファイルシステムが完全にマウント解除されていない場合、ログの再生をスキップすると、ファイルシステムに不整合が含まれ、多くの問題が発生する可能性があります。

関連情報