Belirli bir dosya için LVM Dahili numaralarını belirleme

Şu anda işle ilgili olmayan bir ödev alıştırması yapıyorum. Mantıksal bir birim üzerinde oturan bir ext4 dosya sistemim var. Farklı performans ayarlama stratejilerini test ediyorum ve bu fikir bana geldi. Pvmove bireysel ve uzantı aralıklarını taşıyabildiğinden, hangi fiziksel uzantıların belirli bir dosyayı tuttuğunu haritalamak için bir yol vardır (teorik olarak bir veritabanı için dosyaları veya yaygın olarak erişilen büyük bir dosya paylaşımını yedeklemek olabilir) ve bunları belirli bir dosyaya taşıyabilir depolama cihazı (örneğin aynı LVM Birim Grubunda normal bir HDD ve SSD sürücüm var)?

Ben "filefrag" kullanmayı düşündüm ama sonra bana kapsam sayıları mutlaka sırayla kullanılacak olup olmadığını% 100 değildi (yani ext4 içinde kaç sektör bir dosyayı görüyor mutlaka bilmek Dosyanın fiziksel olarak hangi boyutta / hacimde olduğunu anlıyorum.

Herhangi bir fikir?

İki ana bileşen hdparm --fibmap file, dosyanın fiziksel olarak LV içinde lvs -o +seg_pe_ranges,vg_extent_sizenerede bulunduğunu söyleyen ve LV'nin cihazlarınızda fiziksel olarak nerede bulunduğunu söyleyen unsurlardır.

Gerisi matematik.

Yani mesela:

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

Bunun neden bu kadar parçalanmış olduğunu bilmiyorum - wget ile indirildi. İyi bir örnek olabilir, çünkü gördüğünüz gibi, en azından parçalanmış dosyalar için bunu bir şekilde komut dosyası yazmadan baş ağrınız olur. Sadece ilk segmenti 288776-298511 (9736 sektör) alacağım. Sayı 512 bayt sektör değil, her nasılsa yanlış.

İlk olarak bu verilerin gerçekten doğru olup olmadığını kontrol edin:

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

Aynısı bu yüzden LV-src'yi doğru yerde okuyoruz. Şimdi kaynak-LV nerede bulunuyor?

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

Şimdi bu sıkıcı, bu LV parçalanmamış. Burada baş ağrısı yok. Neyse.

Src'nin / dev / dm-1 üzerinde olduğunu ve PE 5920'de başladığını ve PE 6047'de sona erdiğini ve PE boyutunun 32 MiB olduğunu söylüyor.

Aynı şeyi doğrudan / dev / dm-1'den okuyabilir miyiz bakalım. Matematik açısından, bu biraz bleargh çünkü daha önce 512 bayt blok boyutu kullandık ...: - / ama tembelim, bu yüzden MiB'yi hesaplayacağım ve sonra 512'ye böleceğim! 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. Aradığımız şey bu değil. Ne yanlış gitti? Ah! LVM meta verilerini ve bokunu saklamak için bir PV'nin başlangıcında LVM tarafından işgal edilen ofseti eklemeyi unuttuk. Genellikle bu MiB uyumludur, bu yüzden başka bir MiB ekleyin:

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

İşte aldın.