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

Question

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 o indivíduo e os intervalos de extensões, existe uma maneira de mapear quais extensões físicas mantêm um determinado arquivo (em teoria ele pode estar fazendo backup de arquivos para um banco de dados ou um compartilhamento de arquivo comumente acessado) e movê-los para um determinado arquivo. dispositivo de armazenamento (por exemplo, eu tenho um disco rígido regular e uma unidade SSD no mesmo grupo de volume LVM)?

Eu pensei em usar "filefrag" mas depois ocorreu-me que eu não estava 100% se os números de extensão seriam necessariamente usados em ordem sequencial (então saber quantos setores no ext4 vêem um arquivo não é necessariamente vou deixar-me descobrir em que medida números / volumes o arquivo está fisicamente sentado.

Alguma idéia?

    

Answer 1

Os dois principais ingredientes são hdparm --fibmap file , que informa onde o arquivo está fisicamente localizado no LV e lvs -o +seg_pe_ranges,vg_extent_size , que informa onde o LV está fisicamente localizado em seu (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
     [...]

Eu não sei porque isso é tão fragmentado - baixado com o wget. Pode ser um bom exemplo, porque, como você vê, você 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, já que não são setores de 512 bytes, mas de qualquer forma.

Primeiro verifique se esses dados estão 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  -

Wheeee.Isso é idêntico, então estamos lendo o LV-src no lugar certo. Agora, onde está a fonte-LV localizada?

# 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 isso é chato, esse LV não é fragmentado. Nenhuma dor de cabeça aqui. Enfim.

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

Então vamos ver se podemos ler a mesma coisa de / dev / dm-1 diretamente. Em termos matemáticos, isso é um pouco incômodo já que usamos blocos de 512 bytes antes ...: - / mas eu sou preguiçoso, então vou calcular o MiB e depois dividir 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 offset que é ocupado pelo LVM no início de um PV para armazenar metadados e lixo do LVM. Geralmente isso é alinhado ao MiB, então adicione 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  -

Lá você tem isso.