Eu tenho um sistema com 3 dispositivos SSD ( ,, /dev/sda) que contêm um único volume lógico LVM que abrange todos os dispositivos. Eu tenho uma única partição ext4 no volume lógico./dev/sdb/dev/sdc
Acho que um dos dispositivos SSD ( /dev/sdb)poderapresentar algum defeito e ter desempenho reduzido em comparação com outros dispositivos.
Existe um comando para obter a lista de arquivos suportados por esse dispositivo?
Eu sei que posso obter uma lista de segmentos lógicos sudo pvdisplay -me a saída é semelhante a esta:
--- 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
Então eu sei que as extensões lógicas 476932 a 1430792 são a área potencialmente problemática. Como mapear esse intervalo de segmentos lógicos para arquivos reais no sistema de arquivos (ext4) no topo do LVM?
Basicamente, estou tentando descobrir se o dispositivo está realmente com defeito ou se o padrão de uso desses arquivos pode ser tão azarado que estou atingindo um padrão de uso problemático para o hardware e o desempenho é pior do que o esperado. Nenhum dispositivo apresenta erros e todos os dados parecem bons, mas o desempenho deste único dispositivo parece ser pior do que o esperado.
O sistema está em uso, então prefiro diagnosticar isso on-line sem substituir nenhum dado. Eu sei que se eu pudesse simplesmente colocar off-line o dispositivo de armazenamento potencialmente problemático e sobrescrever seu conteúdo, eu poderia usá- fiolo para compará-lo para ver se ele está funcionando abaixo das especificações ou não.
$ 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
Basicamente, estou perguntando como obter uma lista de arquivos suportados por um único dispositivo de armazenamento quando o sistema de arquivos abrange vários dispositivos de armazenamento.
Ou se você puder fornecer instruções sobre como descobrir onde um determinadoarquivoestá realmente armazenado, isso também seria bom. Eu então executaria essa rotina para cada arquivo para descobrir quais arquivos são suportados pelo dispositivo no qual estou interessado. Estou ciente de que pode ser que um único arquivo grande seja suportado por todos os dispositivos se o arquivo estiver fragmentado em um grande variedade de segmentos locais, então a resposta pode ser que um único arquivo é suportado por todos os dispositivos, mas atualmente também não tenho ideia de como fazer isso.
$ 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
Responder1
Primeiro de tudo, use filefrago utilitário para encontrar a lista de todas as extensões de arquivo:
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_offsetlhe dará uma visão geral de ondeno sistema de arquivosas extensões do arquivo estão localizadas. Observe que esses números sãoem termos de blocos do sistema de arquivos, que são 4k neste caso.
Por exemplo, as segundas extensões deste arquivo começam no byte 11140071424 do início do sistema de arquivos.
A seguir, explore seu layout LVM. Execute sudo lvm vgcfgbackup -v, ele irá despejar um layout de cada VG /etc/lvm/backup/<vgname>em formato textual (e -vswitch fará com que ele informe esses nomes, se você for preguiçoso). É importante usar umrecém-criadodump de backup, para que os nomes dos dispositivos de "dica" sejam realmente usados no momento (um dump antigo se referirá ao estado do VG quando você fez alterações nele pela última vez, o que pode ter acontecido algumas reinicializações atrás, então o os nomes reais dos dispositivos podem ter sido alterados desde então).
Leia o dump do VG correspondente. É bastante detalhado, mas fácil de entender. Em primeiro lugar, lista diversas informações comuns sobre o VG, das quais o tamanho do PE é importante. Em seguida, ele lista os PVs e anota em qual PV você está interessado.
E abaixo estão listados todos os LVs, conforme o conjunto de segmentos. Para cada segmento indica onde está mapeado, PV e localização, em termos de extensão do LVM.
Veja o exemplo (retirei partes não relacionadas):
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
]
}
}
}
}
Este é o LV onde o sistema de arquivos acima está localizado. Vemos que ele está totalmente localizado no pv0, e a extensão do arquivo acima começa no byte 11140071424 + 15744 * 4MiB = 77175193600 do dispositivo sda4. Se o sistema de arquivos abrangesse vários segmentos, eu teria que subtrair seu tamanho (em bytes) da localização dos bytes da extensão do arquivo (11140071424), até terminar no meio de um determinado segmento.
Responder2
Vocêpodervocê poderá ter uma ideia geral de onde o arquivo está localizado usando debugfs, mas isso dependerá muito de como seus LVs foram criados. Se eles estiverem usando o tipo distribuído, os dados não serão gravados sequencialmente nas unidades (primeiro unidade 1, depois unidade 2, etc.), portanto as extensões seriam divididas.
Lembre-se de que a camada do sistema de arquivos (ext4) não conhece nem se preocupa com o dispositivo de bloco subjacente. Ele apenas o vê como um grande pedaço de espaço que pode usar para criar arquivos. Da mesma forma, o LV não conhece nem se preocupa com o sistema de arquivos sobreposto, pois sua função é apenas gerenciar seus próprios dispositivos físicos subjacentes.
Por causa disso, o que o LV chama de extensão 476932 a 1430792 não é necessariamente o que o sistema de arquivos chama de extensões. No entanto, como é uma gama tão grande de extensões, você poderá pelo menos chegar ao limite.
Um exemplo de uso debugfsem/dev/xvda2, que é minha partição raiz (/):
# 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
Você pode ver que este arquivo está localizado nas extensões 4145465-4145467. Se o LV subjacente foi criado como um LV linear, é possível que essas extensões sejam iguais ou muito semelhantes.