Determinando números de extensão do LVM para um determinado arquivo

Atualmente, estou envolvido em um exercício de lição de casa não relacionado ao trabalho. Eu tenho um sistema de arquivos ext4 sentado em um volume lógico. Estou testando diferentes estratégias de ajuste de desempenho e essa ideia me ocorreu. Como o pvmove pode mover individuais e intervalos de extensões, existe uma maneira de mapear quais extensões físicas contêm um arquivo específico (em teoria, ele pode fazer backup de arquivos para um banco de dados ou um grande compartilhamento de arquivos comumente acessado) e movê-los para um determinado dispositivo de armazenamento (por exemplo, eu tenho um disco rígido normal e uma unidade SSD no mesmo grupo de volumes LVM)?

Pensei em usar "filefrag", mas me ocorreu que eu não sabia 100% se os números de extensão seriam necessariamente usados ​​em ordem seqüencial (portanto, saber quantos setores no ext4 vê um arquivo não necessariamente deixa para descobrir em que extensão os números / volumes em que o arquivo está fisicamente.

Alguma ideia?

Os dois principais ingredientes são hdparm --fibmap file: informa onde o arquivo está localizado fisicamente no LV e lvs -o +seg_pe_ranges,vg_extent_sizeindica onde o LV está fisicamente localizado no (s) dispositivo (s).

O resto é matemática.

Então, por exemplo:

# 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
     [...]

Não sei por que isso é tão fragmentado - baixado com o wget. Pode ser um bom exemplo, porque, como você vê, fica com dor de cabeça sem criar scripts de alguma forma, pelo menos para arquivos fragmentados. Vou pegar o primeiro segmento 288776-298511 (9736 setores). A contagem está errada, pois não são setores de 512 bytes, mas de qualquer maneira.

Primeiro verifique se esses dados estão realmente corretos:

# 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  -

É idêntico, então estamos lendo o LV-src no lugar certo. Agora, onde está localizado o LV de origem?

# 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
[...]

Agora que é chato, esse LV não está fragmentado. Sem dor de cabeça aqui. De qualquer forma.

Ele diz que src está em / dev / dm-1 e começa no PE 5920 e termina no PE 6047. E o tamanho do PE é 32 MiB.

Então, vamos ver se podemos ler a mesma coisa diretamente de / dev / dm-1. Em termos matemáticos, isso é um pouco obscuro, pois usamos tamanho de bloco de 512 bytes mais cedo ...: - / mas eu sou preguiçoso, então apenas calculo o MiB e depois divido por 512! Ha! :-D

# 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. Não é isso que estamos procurando. O que deu errado? Ah! Esquecemos de adicionar o deslocamento ocupado pelo LVM no início de um PV para armazenar metadados e porcaria do LVM. Normalmente, isso é alinhado ao MiB, então basta adicionar outro 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  -

Aí está.