커널이 ext4 파티션의 로그에 액세스하는 것을 방지하는 방법은 무엇입니까?

중복되는 질문이 아니길 바랍니다. 몇 가지 유사한 질문을 보았으며 이에 대한 대답은 해당 장치 또는 파티션을 블랙리스트에 추가하는 것입니다. 하지만 내 경우에는 그렇게 할 수 없습니다(아래 참조). 라고 한:

Debian Buster x64 호스트에서 QEMU 기반의 가상 머신을 만들었습니다. 가상 머신이 블록 장치 파티션에서 실행되고 있다고 가정합니다 /dev/sdc1. 기본적으로 다음과 같이 이 파티션에 데비안 시스템을 설치했습니다(일부 단계는 생략됨):

#> 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.

이것은 의미한다주인커널은 이 파티션/파일 시스템의 로그에 액세스합니다. 가상 머신을 시작하면,손님커널도 확실히 이 작업을 수행합니다. 파일 시스템(특히 로그)에 동시에 액세스하는 두 개의 코어로 인해 파일 시스템이 손상되는 것이 거의 확실합니다.

이 문제를 어떻게 해결할 수 있나요?

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명령은 오류를 보고하지 않습니다.