镜像卷上的更改已丢失。

Question

我有一个512 of镜像卷，它在相同大小的卷上有一个快照：

  LV          VG  Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  mirror      vg1 owi-a-r-r- 512,00g                                    100,00
  mirror-snap vg1 swi-aos--- 512,00g      mirror 3,98
  storage     vg1 -wi-ao----  <2,14t

镜像是在2020年08.03.2020创建的：

  --- Logical volume ---
  LV Path                /dev/vg1/mirror
  LV Name                mirror
  VG Name                vg1
  LV UUID                v9x643-ZVZR-3QnQ-Zjud-HR3t-zVeU-XXZNTz
  LV Write Access        read/write
  LV Creation host, time sandlet, 2020-03-08 18:23:00 +0100
  LV snapshot status     source of
                         mirror-snap [active]
  LV Status              available
  # open                 0
  LV Size                512,00 GiB
  Current LE             131072
  Mirrored volumes       2
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:8

创建了快照。

  --- Logical volume ---
  LV Path                /dev/vg1/mirror-snap
  LV Name                mirror-snap
  VG Name                vg1
  LV UUID                CkdK28-4gN4-zvg7-cTHm-fEBk-p2oX-Hb7Hi6
  LV Write Access        read/write
  LV Creation host, time sandlet, 2020-03-14 18:24:14 +0100
  LV snapshot status     active destination for mirror
  LV Status              available
  # open                 1
  LV Size                512,00 GiB
  Current LE             131072
  COW-table size         512,00 GiB
  COW-table LE           131073
  Allocated to snapshot  3,98%
  Snapshot chunk size    4,00 KiB
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:10

昨天我重新启动了电脑。重新启动花费了相当长的时间(大约10分钟)。在重新启动它之后，我注意到镜像卷上的数据不是当前的，而是超过一个月的。具体来说，我注意到数据库中最后的记录是那些在28.03.2020中添加的记录。我没有注意到日志中有任何关于这个问题的具体指示，但可能是这样的：

[    2.225665] device-mapper: raid: Loading target version 1.14.0 [   
2.229924] random: lvm: uninitialized urandom read (2 bytes read) [    2.252783] device-mapper: raid: Failed to read superblock of device at position 0 [    2.281819] md: personality for level 1 is not loaded! [
2.281839] device-mapper: table: 253:6: raid: Failed to run raid array [    2.281841] device-mapper: ioctl: error adding target to table [   
2.288362] device-mapper: raid: Failed to read superblock of device at position 0 [    2.289252] md: personality for level 1 is not loaded! [
2.289260] device-mapper: table: 253:6: raid: Failed to run raid array [    2.289261] device-mapper: ioctl: error adding target to table ... [    3.964926] device-mapper: raid: Failed to read superblock of device at position 0 [    3.976202] md/raid1:mdX: active with 1 out of 2 mirrors

文件系统安装的时间很长：

[    4.713429] EXT4-fs (dm-6): mounted filesystem with ordered data mode. Opts: errors=remount-ro
[  208.170013] logitech-hidpp-device 0003:046D:404D.0004: HID++ 4.1 device connected.
[  282.781954] EXT4-fs (dm-10): mounted filesystem without journal. Opts: errors=remount-ro

另外，这个条目看起来很奇怪，但我不确定它是否相关：

[  289.392877] rfkill: input handler disabled
[20462.471539] perf: interrupt took too long (2502 > 2500), lowering kernel.perf_event_max_sample_rate to 79750
[21821.858690] logitech-hidpp-device 0003:046D:4057.0005: HID++ 4.5 device connected.
[21985.454154] rfkill: input handler enabled
[21997.746672] rfkill: input handler disabled
[22263.335187] perf: interrupt took too long (3144 > 3127), lowering kernel.perf_event_max_sample_rate to 63500
[23750.728687] perf: interrupt took too long (3934 > 3930), lowering kernel.perf_event_max_sample_rate to 50750
[44992.958039] perf: interrupt took too long (4918 > 4917), lowering kernel.perf_event_max_sample_rate to 40500

建立镜像的磁盘是旧的。但是相同的磁盘有另一个跨卷，并且没有问题。镜子会发生什么，有什么办法可以防止这种情况发生呢？我不是说恢复丢失的数据--这是令人不愉快的，但并不重要。

Answer 1

原来，我对LVM缺乏了解，从一开始就没有让我看到原因：

  LV          VG  Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  mirror      vg1 owi-a-r-r- 512,00g                                    100,00
  mirror-snap vg1 swi-aos--- 512,00g      mirror 3,98

属性中的第6个符号"o“表示卷是打开的。男士lvs对“开放”一词的解释没有进一步。但从实际情况来看，很明显，它是一个开放的体积，它是安装的。

实际上，我的快照卷已经被挂载，而不是原来的，而是安装到相同的挂载点，因此我看到了旧的卷状态而不是当前的卷状态。

还有一个问题:为什么快照状态不是创建日期(14.03)，而是2周后(28.03)，以及为什么快照被挂载而不是原始状态，甚至在相应的重新启动之后。但现在我不想再花时间在这上面了。