PV イメージを読み取り専用ループデバイスとしてマウントします (これも以前は機能していました)

2024-6-11 • tag-icon

lvm loop-device

PV イメージを読み取り専用ループデバイスとしてマウントします (これも以前は機能していました)

数年前、私はネットブックを大容量のハードドライブにアップグレードしました。古いハードドライブからまだ取り出したいものがあった場合に備えて、その内容を保持しておきたかったのです。

そこで、古いハードドライブの内容を新しいハードドライブのファイルにコピーしました。

dd if=/dev/sdd5 of=~/fw-disk-image/fw-sdd5-linux-lvm-partition.raw

そして、そのパーティション上の LVM を読み取り専用ファイルシステムとしてマウントするためのスクリプトを作成/コピーしました。

losetup -r /dev/loop1 ~/fw-disk-image/fw-sdd5-linux-lvm-partition.raw

pvscan
vgscan
vgchange -a y fw

cd /mnt/fw
for i in root tmp usr var home
  do
    mount -o ro /dev/fw/$i $i
  done

これは長い間機能していましたが、突然次のvgchange -a y fwコマンドで失敗します:

# vgchange -a y fw
  Error writing device /dev/loop1 at 4096 length 512.
  bcache_invalidate: block (4, 0) still dirty
  Failed to write mda header to /dev/loop1 fd -1
  Failed to update old PV extension headers in VG fw.
  Volume group "fw" not found
  Cannot process volume group fw

読み取り専用のループバックデバイスを作成したので、vgchange はそれに書き込めないことに不満を抱いているのではないかと思います。ディスクが最後に使用されたときにファイルシステムがダーティだったと思いますが、それを無視したいと思います。

現在実行中のシステムは次のとおりです:

Linux fw 4.19.0-8-686-pae #1 SMP Debian 4.19.98-1 (2020-01-26) i686 GNU/Linux

$ vgchange --version
vgchange --version
  LVM version:     2.03.02(2) (2018-12-18)
  Library version: 1.02.155 (2018-12-18)
  Driver version:  4.39.0
  Configuration:   ./configure --build=i686-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir=${prefix}/lib/i386-linux-gnu --libexecdir=${prefix}/lib/i386-linux-gnu --runstatedir=/run --disable-maintainer-mode --disable-dependency-tracking --exec-prefix= --bindir=/bin --libdir=/lib/i386-linux-gnu --sbindir=/sbin --with-usrlibdir=/usr/lib/i386-linux-gnu --with-optimisation=-O2 --with-cache=internal --with-device-uid=0 --with-device-gid=6 --with-device-mode=0660 --with-default-pid-dir=/run --with-default-run-dir=/run/lvm --with-default-locking-dir=/run/lock/lvm --with-thin=internal --with-thin-check=/usr/sbin/thin_check --with-thin-dump=/usr/sbin/thin_dump --with-thin-repair=/usr/sbin/thin_repair --enable-applib --enable-blkid_wiping --enable-cmdlib --enable-dmeventd --enable-dbus-service --enable-lvmlockd-dlm --enable-lvmlockd-sanlock --enable-lvmpolld --enable-notify-dbus --enable-pkgconfig --enable-readline --enable-udev_rules --enable-udev_sync

厳密に読み取り専用のまま、このパーティションに LV を (再度) マウントする方法はありますか?

答え1

回避策は以下のとおりです。LVMが読み書き可能なブロックデバイスを必要とする場合、読み取り専用ブロックデバイスに基づいてオーバーレイブロックデバイスを作成します（この他の質問を参照してください）。

ルートとして:

読み取り専用ブロックデバイスと同じサイズのスパースファイルを作成する
```
truncate -s`blockdev --getsize64 /dev/loop1` '/tmp/overlay.bin'
```
（現在のファイルシステムよりも大きい場合でも）

オーバーレイブロックデバイスを作成する

loop=`losetup -f --show -- '/tmp/overlay.bin'`
size=`blockdev --getsz /dev/loop1`
printf '%s\n' "0 $size snapshot /dev/loop1 $loop P 8" | dmsetup create 'overlayloop1'

LVMが同じUUIDを持つ重複したPVについて警告するのを避けるには、/etc/lvm/lvm.confを編集して元の/dev/loop1を除外しますdevices { scan = [ "/dev/mapper" ] }。devices { filter = [ "r|/dev/loop1|" ] }LVM wikiのこのFAQ）
動作するようになりましvgchange -a y fwた。

使用中は、ファイル /tmp/overlay.bin を監視する必要がありますが、特に LV のファイルシステムが読み取り専用でマウントされている場合は、このファイルが増加しないはずです。

ループデバイスを閉じるには:

vgchange -a n fw
dmsetup remove /dev/mapper/overlayloop1
rm /tmp/overlay.bin
losetup -d /dev/loop1

答え2

ファイルシステムが汚れていたわけではありません (汚れていた可能性もありますが、それはここでの問題ではありません)。LVM bcache 構造が汚れていました。何らかのデフォルト設定が変更されたため、動作しなくなったのだと思います。

提案:

ループデバイスを rw モードで一度セットアップします。これで問題は解決するはずです。成功したら、vgchangeループデバイスを破棄して、ファイルシステムをマウントせずに ro で再度セットアップできます。
loopdev を rw にしなくても問題が解決するかどうか試すこともできます。100M のファイルで別の loopdev を作成し、スナップショットを作成できます。残念ながら、これを手動で行う必要がありますdmsetup。その後、LVM ツールでスナップショットをスキャンできます。すべての変更がスナップショットに書き込まれます。
試すvgchange -a y --readonly fw

関連情報