Определение номеров экстентов 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 в нужном месте. Теперь, где находится источник-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
[...]

Теперь это скучно, этот LV не фрагментирован. Здесь нет головной боли. Тем не мение.

Он говорит, что 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  -

Там у вас есть это.