Określanie numerów ekstensywnych LVM dla danego pliku

Obecnie jestem zaangażowany w pracę domową niezwiązaną z pracą. Mam system plików ext4 siedzący na woluminie logicznym. Testuję różne strategie dostrajania wydajności i ten pomysł przyszedł mi do głowy. Ponieważ pvmove może przenosić poszczególne zakresy i zakresy, istnieje sposób odwzorowania, jakie zakresy fizyczne przechowują dany plik (teoretycznie może to być tworzenie kopii zapasowej plików bazy danych lub dużego udziału plików, do którego często uzyskiwany jest dostęp) i przeniesienie ich do określonego urządzenie pamięci masowej (na przykład mam zwykły dysk twardy i dysk SSD w tej samej grupie woluminów LVM)?

Pomyślałem o użyciu „filefrag”, ale potem przyszło mi do głowy, że nie byłem w 100% pewien, czy liczby rozpiętości byłyby koniecznie używane w kolejności sekwencyjnej (więc wiedza o tym, ile sektorów w ext4 widzi plik niekoniecznie pozwoli zastanawiam się, w jakim zakresie liczby / woluminy znajduje się fizycznie plik.

Jakieś pomysły?

Dwa główne składniki to: hdparm --fibmap fileinformacja, gdzie plik znajduje się fizycznie w LV, i lvs -o +seg_pe_ranges,vg_extent_sizektóra informuje, gdzie LV znajduje się fizycznie na twoim urządzeniu (urządzeniach).

Reszta to matematyka.

Na przykład:

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

Nie wiem, dlaczego jest tak rozdrobniony - pobrany za pomocą wget. Może to być dobry przykład, ponieważ, jak widzisz, odczuwasz ból głowy bez skryptu, przynajmniej w przypadku pofragmentowanych plików. Po prostu wezmę pierwszy segment 288776-298511 (9736 sektorów). Liczba jest błędna, ponieważ nie jest to 512 bajtów sektorów, ale tak czy inaczej.

Najpierw sprawdź, czy te dane są rzeczywiście poprawne:

# 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. To jest identyczne, więc czytamy LV-src we właściwym miejscu. Gdzie jest teraz źródło 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
[...]

To nudne, ten LV nie jest podzielony. Tutaj nie ma bólu głowy. Tak czy siak.

Mówi, że src jest na / dev / dm-1 i zaczyna się od PE 5920, a kończy na PE 6047. A rozmiar PE to 32 MiB.

Zobaczmy więc, czy możemy bezpośrednio odczytać to samo z / dev / dm-1. Z matematycznego punktu widzenia jest to trochę niewyraźne, ponieważ wcześniej użyliśmy 512-bajtowego rozmiaru bloku ...: - / ale jestem leniwy, więc po prostu obliczę MiB, a następnie podzielę przez 512! Ha! :-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. Nie tego szukamy. Co poszło nie tak? Ach! Zapomnieliśmy dodać przesunięcie zajmowane przez LVM na początku PV do przechowywania metadanych i bzdur LVM. Zwykle jest to zgodne z MiB, więc po prostu dodaj kolejną 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  -

Masz to.