У меня есть система с 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 являются потенциально проблемной областью. Как сопоставить этот логический диапазон сегментов с реальными файлами в файловой системе (ext4) поверх LVM?
В основном я пытаюсь выяснить, действительно ли устройство неисправно или же шаблон использования этих файлов может быть настолько неудачным, что я натыкаюсь на шаблон использования, который является проблемным для оборудования, и производительность хуже, чем ожидалось. Ни одно устройство не показывает никаких ошибок, и все данные выглядят хорошо, но производительность этого одного устройства, похоже, хуже, чем ожидалось.
Система используется, поэтому я бы предпочел провести диагностику онлайн, не перезаписывая никаких данных. Я знаю, что если бы я мог просто перевести потенциально проблемное устройство хранения в автономный режим и перезаписать его содержимое, я мог бы использовать 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 /etc/lvm/backup/<vgname>в текстовой форме (и -vswitch заставит его сообщать вам эти имена, если вам лень). Важно использоватьсвежесозданрезервный дамп, чтобы «подсказанные» имена устройств в нем были фактически используемыми устройствами в данный момент (старый дамп будет ссылаться на состояние 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. Если они используют тип striped, данные не записываются последовательно на диски (сначала drive1, затем drive 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, возможно, эти экстенты одинаковы или очень похожи.