主页 / server / 问题 / 1151862
Accepted
Mikko Rantalainen
Asked: 2024-01-19 21:58:16 +0800 CST

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

  • 772

我的系统有 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
performance

2 个回答

  1. 您也许可以使用 来大致了解文件所在的位置debugfs，但这在很大程度上取决于您的 LV 的创建方式。如果它们使用条带类型，则数据不会按顺序写入驱动器（首先是驱动器 1，然后是驱动器 2，等等），因此范围将被划分。

    请记住，文件系统层 (ext4) 不知道也不关心底层块设备。它只是将其视为可用于创建文件的一大块空间。同样，LV 不知道也不关心覆盖的文件系统，因为它的工作只是管理它自己的底层物理设备。

    因此，LV 所称的范围 476932 到 1430792 不一定是文件系统所称的这些范围。然而，由于范围如此之大，您至少可以大致了解一下。

    在/dev/xvda2debugfs上使用的示例，这是我的根 (/) 分区：

    # 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，则这些范围可能相同或非常相似。

    • 1
  2. Best Answer

    首先，使用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 的布局转储/etc/lvm/backup/<vgname>为文本形式（-v如果你懒的话， switch 会让它告诉你这些名称）。使用新创建的备份转储非常重要，因为其中的“提示”设备名称是当前实际使用的设备（旧转储将引用您上次对其进行更改时的 VG 状态，这可能已经发生几次重新启动前，因此实际的设备名称可能已从那时起更改）。

    读取相应 VG 的转储。它相当冗长，但很容易理解。首先列出了VG的各种常见信息，其中PE大小很重要。然后它会列出 PV 并记下您感兴趣的 PV。

    下面列出了所有 LV，作为段的集合。对于每个段，它以 LVM 范围的形式说明其映射位置、PV 和位置。

    看例子（我去掉了不相关的部分）：

    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）中减去它们的大小（以字节为单位），直到我最终到达某个段的中间。

    • 1

相关问题