我有一个 512GB 的镜像卷，该卷上有一个相同大小的快照：
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.03.08：
--- 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 分钟）。重启后，我注意到镜像卷上的数据不是最新的，而是一个月前的数据。具体来说，我注意到数据库中的最后记录是 2020 年 3 月 28 日添加的记录。除了以下情况外，我没有在日志中发现任何有关该问题的具体迹象：
[ 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
镜像所基于的磁盘是旧磁盘。但同一磁盘上有另一个跨区卷，而该卷没有问题。镜像可能出现什么问题？有没有什么方法可以防止这种情况发生？我说的不是恢复丢失的数据 - 这很令人不快，但并不重要。
答案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”表示卷已打开。man lvs 没有进一步解释“打开”一词。但从情况来看，显然打开的卷是已安装的卷。
确实，我的快照卷而不是原始卷被安装到同一个安装点，因此我看到的是旧卷状态而不是当前卷状态。
还有一个问题，为什么快照状态不是其创建日期（14.03）而是 2 周后（28.03）的状态，以及为什么快照被挂载而不是原始状态，甚至在随后的重启之后也是如此。但目前我不想再花更多时间在这上面。