Визначення LVM Обширних чисел для даного файлу

Зараз я займаюся домашнім завданням, пов'язаним з неробочими роботами. У мене файлова система ext4 сидить на логічному томі. Я тестую різні стратегії настройки продуктивності, і ця ідея мені прийшла в голову. Оскільки pvmove може переміщувати окремі та діапазони розширень, чи є спосіб відобразити, які фізичні розширення вміщують певний файл (теоретично це може бути резервне копіювання файлів для бази даних або великий загальнодоступний файл спільного доступу) та переміщення їх до певного запам'ятовуючий пристрій (наприклад, у мене звичайний жорсткий диск і накопичувач SSD в тій же групі обсягів LVM)?

Я думав використовувати "filefrag", але тоді мені прийшло в голову, що я не на 100% від того, чи обов'язково будуть використовуватися числа ступенів у послідовному порядку (тому знаючи, скільки секторів у ext4 бачить файл, не обов'язково давати мені зрозуміти, в якій мірі цифри / обсяги файл фізично сидить.

Будь-які ідеї?

Два основні інгредієнти - hdparm --fibmap fileце вказівка, де файл знаходиться фізично в межах LV, і lvs -o +seg_pe_ranges,vg_extent_sizeвказується, де LV знаходиться на вашому пристрої.

Решта - математика.

Так, наприклад:

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

Я не знаю, чому це так фрагментарно - завантажено з wget. Це може бути хорошим прикладом, тому що, як бачите, у вас болить голова, не проробляючи це якось, принаймні для фрагментованих файлів. Я просто візьму перший сегмент 288776-298511 (9736 секторів). Підрахунок неправильний, оскільки це не 512 байтових секторів, але так чи інакше.

Спочатку перевірте, чи справді ці дані є правильними:

# 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. Це ідентично, тому ми читаємо LV-src в потрібному місці. Тепер де знаходиться джерело НН?

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

Тепер це нудно, цей НН не роздроблений. Тут немає головного болю. У всякому разі.

Він говорить, що src увімкнено / dev / dm-1, починається з PE 5920 і закінчується на PE 6047. А розмір PE - 32 МіБ.

Тож давайте подивимось, чи зможемо ми прочитати те ж саме з / dev / dm-1 безпосередньо. Математично, це трохи нерозумно, оскільки ми раніше використовували 512 байтових блоків ...: - /, але я лінивий, тому я просто обчисляю MiB, а потім ділю на 512! Га! :-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  -

Бу-Бу. Це не те, що ми шукаємо. Що пішло не так? Ах! Ми забули додати зміщення, яке займає LVM на початку PV для зберігання метаданих LVM та лайна. Зазвичай це вирівнювання MiB, тому просто додайте інший 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  -

Там у вас є.