我有一套包含 3 个 SSD 设备的系统（/dev/sda、/dev/sdb、/dev/sdc），其中包含一个跨所有设备的 LVM 逻辑卷。我在逻辑卷上有一个 ext4 分区。
我认为其中一个 SSD 设备 ( /dev/sdb)可能与其他设备相比存在一些缺陷并且性能有所下降。
是否有命令可以获取该设备支持的文件列表？
我知道我可以获得逻辑段列表，sudo pvdisplay -m输出如下所示：
--- Physical volume ---
PV Name /dev/sda
VG Name storage
PV Size <1,82 TiB / not usable <1,09 MiB
Allocatable yes (but full)
PE Size 4,00 MiB
Total PE 476932
Free PE 0
Allocated PE 476932
PV UUID h3x3O1-1KWj-3pY6-kZ24-MVV4-54UE-ltEdfA
--- Physical Segments ---
Physical extent 0 to 476931:
Logical volume /dev/storage/vm
Logical extents 0 to 476931
--- Physical volume ---
PV Name /dev/sdb
VG Name storage
PV Size <3,64 TiB / not usable <3,84 MiB
Allocatable yes (but full)
PE Size 4,00 MiB
Total PE 953861
Free PE 0
Allocated PE 953861
PV UUID MsNlhh-W2It-CbX4-IxJn-lXJN-hlcd-EpBh9Q
--- Physical Segments ---
Physical extent 0 to 953860:
Logical volume /dev/storage/vm
Logical extents 476932 to 1430792
--- Physical volume ---
PV Name /dev/sdc
VG Name storage
PV Size <3,64 TiB / not usable <3,84 MiB
Allocatable yes (but full)
PE Size 4,00 MiB
Total PE 953861
Free PE 0
Allocated PE 953861
PV UUID sklK6w-XZd6-DqIp-ZT1g-O9rj-1ufw-UaC0z4
--- Physical Segments ---
Physical extent 0 to 953860:
Logical volume /dev/storage/vm
Logical extents 1430793 to 2384653
所以我知道逻辑扩展 476932 到 1430792 是潜在的问题区域。如何将此逻辑段范围映射到 LVM 上的文件系统 (ext4) 上的实际文件？
基本上，我想弄清楚设备是否真的有故障，或者这些文件的使用模式是否不幸，以至于我遇到了对硬件有问题的使用模式，并且性能比预期的要差。没有设备显示任何错误，所有数据看起来都很好，但这台设备的性能似乎比预期的要差。
系统正在使用中，所以我更愿意在线诊断而不覆盖任何数据。我知道，如果我可以简单地将可能有问题的存储设备脱机并覆盖其内容，我就可以用fio它来进行基准测试，看看它是否低于规格。
$ lsblk -s
...
storage-vm 253:0 0 9,1T 0 lvm /mnt/storage
├─sda 8:0 0 1,8T 0 disk
├─sdb 8:16 0 3,7T 0 disk
└─sdc 8:32 0 3,7T 0 disk
我基本上想问的是，当文件系统跨越多个存储设备时，如何获取单个存储设备支持的文件列表。
或者如果你能提供说明如何确定给定的文件实际存储了，那也很好。然后我会对每个文件运行该例程，以找出我感兴趣的设备支持哪些文件。我知道如果文件分散在大量本地段上，那么单个大文件可能由所有设备支持，因此答案可能是单个文件由所有设备支持，但我目前也不知道如何做到这一点。
$ sudo vgdisplay
--- Volume group ---
VG Name storage
System ID
Format lvm2
Metadata Areas 3
Metadata Sequence No 6
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 3
Act PV 3
VG Size <9,10 TiB
PE Size 4,00 MiB
Total PE 2384654
Alloc PE / Size 2384654 / <9,10 TiB
Free PE / Size 0 / 0
VG UUID MOrTMY-5Dly-48uQ-9Fa8-JNvf-tont-9in7ol
$ sudo lvdisplay
--- Logical volume ---
LV Path /dev/storage/vm
LV Name vm
VG Name storage
LV UUID RDkaLH-mh6C-cXxT-6ojc-DxkB-o4jD-3CMHdl
LV Write Access read/write
LV Creation host, time staging, 2021-01-21 09:57:06 +0200
LV Status available
# open 1
LV Size <9,10 TiB
Current LE 2384654
Segments 3
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:0
答案1
首先，使用filefrag实用程序查找所有文件范围的列表：
merlin@uc-s4m75657:~$ sudo filefrag /mnt/spool/merlin/VMs/slax-64bit-11.4.0-merlin.iso -e
Filesystem type is: ef53
File size of /mnt/spool/merlin/VMs/slax-64bit-11.4.0-merlin.iso is 322979840 (78853 blocks of 4096 bytes)
ext: logical_offset: physical_offset: length: expected: flags:
0: 0.. 8191: 2703360.. 2711551: 8192:
1: 8192.. 14335: 2719744.. 2725887: 6144: 2711552:
2: 14336.. 57343: 2732032.. 2775039: 43008: 2725888:
3: 57344.. 65535: 2783232.. 2791423: 8192: 2775040:
4: 65536.. 71679: 2797568.. 2803711: 6144: 2791424:
5: 71680.. 78852: 2811904.. 2819076: 7173: 2803712: last,eof
/mnt/spool/merlin/VMs/slax-64bit-11.4.0-merlin.iso: 6 extents found
physical_offset将为你提供概述在文件系统中文件的范围位于。注意这些数字是就文件系统块而言，在本例中为 4k。
例如，该文件的第二个范围从文件系统起始处的第 11140071424 字节开始。
接下来，探索您的 LVM 布局。运行，它将以文本形式sudo lvm vgcfgbackup -v转储每个 VG 的布局（如果您懒惰， switch 会让它告诉您这些名称）。重要的是使用/etc/lvm/backup/<vgname>-v刚刚创建备份转储，其中的“提示”设备名称是当前实际使用的设备（旧转储将引用您上次对其进行更改时的 VG 状态，这可能发生在几次重启之前，因此实际的设备名称可能已经发生了更改）。
阅读相应 VG 的转储。它非常冗长，但很容易理解。首先，它列出了有关 VG 的各种常见信息，其中 PE 大小很重要。然后它列出 PV 并记下您感兴趣的 PV。
下面列出了所有 LV，作为段的集合。对于每个段，它都说明了其映射位置、PV 和位置（以 LVM 区为单位）。
看一下示例（我删除了不相关的部分）：
system {
#...
extent_size = 8192 # 4 Megabytes
#...
physical_volumes {
pv0 {
#...
device = "/dev/sda4" # Hint only
#...
pe_start = 2048
pe_count = 57105 # 223,066 Gigabytes
}
}
logical_volumes {
#...
spool {
#...
segment_count = 1
segment1 {
start_extent = 0
extent_count = 41361 # 161,566 Gigabytes
#...
stripes = [
"pv0", 15744
]
}
}
}
}
这是上面的文件系统所在的 LV。我们看到它完全位于 pv0 上，并且文件的上述范围从设备的字节 11140071424 + 15744 * 4MiB = 77175193600 开始sda4。如果文件系统跨越多个段，我必须从文件范围字节位置 (11140071424) 中减去它们的大小（以字节为单位），直到我最终位于某个段的中间。
答案2
你可能可以使用 大致了解文件的位置debugfs，但这在很大程度上取决于 LV 的创建方式。如果使用条带类型，则数据不会按顺序写入驱动器（首先是驱动器 1，然后是驱动器 2，等等），因此范围将被分割。
请记住，文件系统层 (ext4) 不知道也不关心底层块设备。它只是将其视为可用于创建文件的一大块空间。同样，LV 不知道也不关心覆盖文件系统，因为它的工作只是管理自己的底层物理设备。
因此，LV 所称的范围 476932 到 1430792 不一定是文件系统所称的范围。但是，由于范围范围如此之大，您至少可以大致了解一下。
debugfs使用示例/dev/xvda2，这是我的根 (/) 分区：
# debugfs /dev/xvda2
debugfs 1.46.5 (30-Dec-2021)
debugfs: ls /root
262146 (12) . 2 (12) .. 268932 (12) .ssh
268409 (16) .bashrc 268410 (16) .profile 276186 (16) .cache
268256 (16) .ansible 268318 (24) .vim
268408 (24) .bash_completion
267590 (16) .vimrc 262167 (24) .bash_history
debugfs: stat /root/.bashrc
Inode: 268409 Type: regular Mode: 0644 Flags: 0x80000
Generation: 4101506038 Version: 0x00000000:00000001
User: 0 Group: 0 Project: 0 Size: 10137
File ACL: 0
Links: 1 Blockcount: 24
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x64c7f06b:37648614 -- Mon Jul 31 12:33:31 2023
atime: 0x660f7b2c:32146cc8 -- Thu Apr 4 23:16:44 2024
mtime: 0x64c7ef9d:00000000 -- Mon Jul 31 12:30:05 2023
crtime: 0x641493b2:49f692b4 -- Fri Mar 17 11:22:10 2023
Size of extra inode fields: 32
Inode checksum: 0x8cc75e77
EXTENTS:
(0-2):4145465-4145467
您可以看到该文件位于扩展区 4145465-4145467。如果底层 LV 创建为线性 LV，则这些扩展区可能相同或非常相似。