Определение значений LVM для заданного файла

В настоящее время я занимаюсь домашним заданием, не связанным с работой. У меня файловая система ext4, сидящая на логическом томе. Я тестирую различные стратегии настройки производительности, и эта идея возникла для меня. Поскольку pvmove может перемещать отдельные и диапазоны экстентов, существует ли способ определить, какие физические экстенты содержат определенный файл (теоретически это может быть поддержка файлов для базы данных или большого общего доступа к файлу) и переместить их в конкретный (например, у меня есть обычный жесткий диск и SSD-диск в той же группе томов LVM)?

Я думал об использовании «filefrag», но потом мне пришло в голову, что я не был на 100% уверенным, будут ли номера экстентов обязательно использоваться в последовательном порядке (так что знание того, сколько секторов в ext4 видит файл, не обязательно будет позволять я выясняю, в какой степени числа / томов физически сидит файл.

Есть идеи?

  • Невозможно смонтировать файловую систему под luks. Устройство не существует
  • Можно ли записывать снимки LVM? (и используется для временных экспериментов)
  • LVM - Восстановление от повреждения таблицы разделов
  • Проблема с корневым устройством Arch linux в '/ dev / mapper / MyStorage-rootvol'
  • Создать раздел (стандартный раздел и физический том LVM) в установке CentOS
  • Как определить LVM-over-LUKS или LUKS-over-LVM
  • mdadm raid0 с дисками разного размера?
  • как сделать LVM доступным для загрузки? kernel panic - dracut не может найти логические тома после обновления ядра в CentOS 6.6
  • One Solution collect form web for “Определение значений LVM для заданного файла”

    Двумя основными ингредиентами являются 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 MiB.

    Поэтому давайте посмотрим, можем ли мы напрямую прочитать одно и то же из / dev / dm-1. Math-wise, это немного bleargh, так как мы использовали 512-байтовый блок раньше …: – / но я ленив, поэтому я просто вычислил MiB, а затем разделил на 512! Ха! 😀

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

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

    Linux и Unix - лучшая ОС в мире.