Determinar números de extensión LVM para un archivo dado

Actualmente estoy involucrado en un ejercicio de tarea no relacionado con el trabajo. Tengo un sistema de archivos ext4 sentado en un volumen lógico. Estoy probando diferentes estrategias de ajuste de rendimiento y se me ocurrió esta idea. Dado que pvmove puede mover rangos individuales y rangos de extensiones, ¿hay alguna manera de mapear qué extensiones físicas contienen un archivo en particular (en teoría, puede estar respaldando archivos para una base de datos o un gran recurso compartido de archivos de acceso común) y moverlos a un determinado dispositivo de almacenamiento (por ejemplo, tengo un HDD normal y un disco SSD en el mismo grupo de volúmenes LVM)?

Pensé en usar "filefrag" pero luego se me ocurrió que no estaba al 100% sobre si los números de extensión se usarían necesariamente en orden secuencial (por lo tanto, saber cuántos sectores en ext4 ve un archivo no necesariamente va a permitir Me imagino en qué extensión números / volúmenes se encuentra físicamente el archivo.

¿Algunas ideas?

Los dos ingredientes principales son hdparm --fibmap file, que le dice dónde se encuentra físicamente el archivo dentro del LV, y lvs -o +seg_pe_ranges,vg_extent_sizeque le dice dónde está ubicado físicamente el LV en su (s) dispositivo (s).

El resto es matemática.

Así por ejemplo:

# hdparm --fibmap linux-3.8.tar.bz2 

linux-3.8.tar.bz2:
 filesystem blocksize 4096, begins at LBA 0; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0     288776     298511       9736
     4984832     298520     298623        104
     5038080     298640     298695         56
     5066752     298736     298799         64
     5099520     298824     298895         72
     [...]

No sé por qué esto está tan fragmentado, descargado con wget. Puede ser un buen ejemplo porque, como puede ver, le duele la cabeza sin escribir esto de alguna manera, al menos para archivos fragmentados. Tomaré el primer segmento 288776-298511 (9736 sectores). El recuento es incorrecto ya que no son sectores de 512 bytes, pero de todos modos.

Primero verifique que estos datos sean realmente correctos:

# dd if=linux-3.8.tar.bz2 bs=512 skip=0 count=9736 | md5sum
9736+0 records in
9736+0 records out
4984832 bytes (5.0 MB) copied, 0.0506548 s, 98.4 MB/s
7ac1bb05a8c95d10b97982b07aceafa3  -

# dd if=/dev/lvm/src bs=512 skip=288776 count=9736 | md5sum
9736+0 records in
9736+0 records out
4984832 bytes (5.0 MB) copied, 0.123292 s, 40.4 MB/s
7ac1bb05a8c95d10b97982b07aceafa3  -

Wheeee. Eso es idéntico, así que estamos leyendo el LV-src en el lugar correcto. Ahora, ¿dónde está ubicada la fuente-LV?

# lvs -o +seg_pe_ranges,vg_extent_size
  LV          VG   Attr      LSize   Pool Origin Data%  Move Log Copy%  Convert PE Ranges             Ext   

[...]
 src         lvm  -wi-ao---   4.00g                                            /dev/dm-1:5920-6047   32.00m
[...]

Ahora que es aburrido, este LV no está fragmentado. No hay dolor de cabeza aquí. De todas formas.

Dice src está en / dev / dm-1 y comienza en PE 5920 y termina en PE 6047. Y el tamaño de PE es 32 MiB.

Entonces, veamos si podemos leer lo mismo de / dev / dm-1 directamente. En cuanto a las matemáticas, esto es un poco triste ya que usamos un tamaño de bloque de 512 bytes antes ...: - / pero soy flojo, así que calcularé el MiB y luego lo dividiré entre 512. ¡Decir ah! :-RE

# dd if=/dev/dm-1 bs=512 skip=$((1024*1024/512 * 32 * 5920 + 288776)) count=9736 | md5sum
9736+0 records in
9736+0 records out
4984832 bytes (5.0 MB) copied, 0.0884709 s, 56.3 MB/s
3858a4cd75b1cf6f52ae2d403b94a685  -

Boo Boo. Esto no es lo que estamos buscando. ¿Qué salió mal? Ah! Olvidamos agregar el desplazamiento que ocupa LVM al comienzo de un PV para almacenar metadatos y basura LVM. Por lo general, esto está alineado con MiB, así que solo agregue otro MiB:

# dd if=/dev/dm-1 bs=512 skip=$((1024*1024/512 * 32 * 5920 + 288776 + 1024*1024/512)) count=9736 | md5sum
9736+0 records in
9736+0 records out
4984832 bytes (5.0 MB) copied, 0.0107592 s, 463 MB/s
7ac1bb05a8c95d10b97982b07aceafa3  -

Ahí tienes.