すべてのデバイスにまたがる単一の LVM 論理ボリュームを含む3 つの SSD デバイス ( /dev/sda、/dev/sdb、 )を備えたシステムがあります。論理ボリュームには単一の ext4 パーティションがあります。/dev/sdc
SSDデバイスの1つ（/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
基本的に、ファイルシステムが複数のストレージ デバイスにまたがっている場合に、単一のストレージ デバイスによってバックアップされているファイルのリストを取得する方法を尋ねています。
または、与えられた場所をどのように計算するかの指示を提供していただければファイル実際に保存されているのであれば、それも問題ありません。次に、すべてのファイルに対してそのルーチンを実行して、関心のあるデバイスによってバックアップされているファイルを特定します。ファイルが広範囲のローカル セグメントに断片化されている場合、1 つの大きなファイルがすべてのデバイスによってバックアップされる可能性があることはわかっています。したがって、1 つのファイルがすべてのデバイスによってバックアップされているという答えになるかもしれませんが、現時点では、これを行う方法もわかりません。
$ 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 です。
たとえば、このファイルの 2 番目のエクステントは、ファイルシステムの開始からバイト 11140071424 から始まります。
次に、LVMレイアウトを調べます。 を実行するとsudo lvm vgcfgbackup -v、各VGのレイアウトが/etc/lvm/backup/<vgname>テキスト形式でダンプされます（-v面倒な場合は、スイッチでこれらの名前を教えてくれます）。新しく作られたバックアップ ダンプ。その中の「ヒント」デバイス名は、現時点で実際に使用されているデバイスです (古いダンプは、最後に変更を加えたときの 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) からそれらのサイズ (バイト単位) を減算する必要があります。
答え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 として作成された場合、これらのエクステントは同じか非常に類似している可能性があります。