☰

如何在 ext4 上、LVM 上、多个底层存储设备上找到文件的底层设备？

tag-icon • tag-icon performance lvm ext4 block-device
如何在 ext4 上、LVM 上、多个底层存储设备上找到文件的底层设备？

我有一套包含 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，则这些扩展区可能相同或非常相似。

相关内容