Tengo un sistema con 3 dispositivos SSD ( /dev/sda,, /dev/sdb) /dev/sdcque contienen un único volumen lógico LVM que abarca todos los dispositivos. Tengo una única partición ext4 en el volumen lógico.
Creo que uno de los dispositivos SSD ( /dev/sdb)podríaser algo defectuosos y tener un rendimiento reducido respecto a otros dispositivos.
¿Existe algún comando para obtener la lista de archivos respaldados por ese dispositivo?
Sé que puedo obtener una lista de segmentos lógicos sudo pvdisplay -my el resultado es el siguiente:
--- 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
Entonces sé que las extensiones lógicas 476932 a 1430792 son el área potencialmente problemática. ¿Cómo asignar este rango de segmentos lógicos a archivos reales en el sistema de archivos (ext4) encima del LVM?
Básicamente, estoy tratando de averiguar si el dispositivo está realmente defectuoso o si el patrón de uso de estos archivos puede ser tan desafortunado que me encuentro con un patrón de uso que es problemático para el hardware y el rendimiento es peor de lo esperado. Ningún dispositivo muestra errores y todos los datos parecen buenos, pero el rendimiento de este único dispositivo parece ser peor de lo esperado.
El sistema está en uso, por lo que preferiría diagnosticarlo en línea sin sobrescribir ningún dato. Sé que si pudiera simplemente desconectar el dispositivo de almacenamiento potencialmente problemático y sobrescribir su contenido, podría usarlo fiopara compararlo y ver si funciona por debajo de las especificaciones o no.
$ 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
Básicamente estoy preguntando cómo obtener una lista de archivos respaldados por un único dispositivo de almacenamiento cuando el sistema de archivos abarca varios dispositivos de almacenamiento.
O si puede proporcionar instrucciones sobre cómo calcular dónde se encuentra un determinadoarchivoestá realmente almacenado, eso también estaría bien. Luego ejecutaría esa rutina para cada archivo para determinar qué archivos están respaldados por el dispositivo que me interesa. Soy consciente de que podría ser que un solo archivo grande esté respaldado por todos los dispositivos si el archivo está fragmentado en un gran variedad de segmentos locales, por lo que la respuesta podría ser que todos los dispositivos respaldan un solo archivo, pero actualmente tampoco tengo idea de cómo hacerlo.
$ 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
Respuesta1
En primer lugar, utilice filefragla utilidad para encontrar la lista de todas las extensiones de archivos:
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_offsetle dará una visión general dondeen el sistema de archivosse ubican las extensiones del archivo. Observe que estos números sonen términos de bloques del sistema de archivos, que en este caso son 4k.
Por ejemplo, la segunda extensión de este archivo comienza en el byte 11140071424 desde el inicio del sistema de archivos.
A continuación, explore su diseño LVM. Ejecutar sudo lvm vgcfgbackup -v, volcará un diseño de cada VG /etc/lvm/backup/<vgname>en forma de texto (y -vel interruptor hará que le diga estos nombres, si es perezoso). Es importante utilizar unrecién creadovolcado de copia de seguridad, para que los nombres de los dispositivos "pistas" que contiene sean dispositivos realmente utilizados en ese momento (un volcado antiguo se referirá al estado de VG la última vez que realizó cambios en él, lo que puede haber ocurrido hace algunos reinicios, por lo que el Es posible que los nombres reales de los dispositivos hayan cambiado desde entonces).
Lea el volcado del VG correspondiente. Es bastante detallado, pero fácil de entender. En primer lugar, enumera información común sobre el VG, de la cual el tamaño del PE es importante. Luego enumera los PV y toma nota de cuál PV le interesa.
Y debajo, se enumeran todos los LV, como el conjunto de segmentos. Para cada segmento, indica dónde está mapeado, PV y ubicación, en términos de extensión LVM.
Mire el ejemplo (eliminé partes no 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 es el LV donde se encuentra el sistema de archivos de arriba. Vemos que está completamente ubicado en pv0, y la extensión anterior del archivo comienza en el byte 11140071424 + 15744 * 4MiB = 77175193600 del dispositivo sda4. Si el sistema de archivos abarcara varios segmentos, tendría que restar su tamaño (en bytes) de la ubicación de bytes de extensión del archivo (11140071424), hasta terminar en el medio de un determinado segmento.
Respuesta2
TúpodríaPodrás tener una idea general de dónde se encuentra el archivo usando debugfs, pero dependerá en gran medida de cómo se crearon tus LV. Si utilizan el tipo seccionado, los datos no se escriben secuencialmente en las unidades (primero la unidad 1, luego la unidad 2, etc.), por lo que las extensiones se dividirían.
Recuerde que la capa del sistema de archivos (ext4) no conoce ni se preocupa por el dispositivo de bloque subyacente. Simplemente lo ve como una gran cantidad de espacio que puede utilizar para crear archivos. Del mismo modo, el LV no conoce ni se preocupa por el sistema de archivos superpuesto, ya que su trabajo es simplemente administrar sus propios dispositivos físicos subyacentes.
Debido a esto, lo que LV llama extensión 476932 a 1430792 no es necesariamente lo que el sistema de archivos llama esas extensiones. Sin embargo, dado que es una gama tan grande de extensiones, es posible que al menos puedas llegar al estadio.
Un ejemplo de uso debugfsen/dev/xvda2, que es mi partición raíz (/):
# 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
Puede ver que este archivo se encuentra en las extensiones 4145465-4145467. Si el VI subyacente se creó como un VI lineal, es posible que estas extensiones sean iguales o muy similares.