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

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

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

  • Получить PID процесса, начатого по времени
  • сеть: хост назначения недоступен
  • Получить возвращаемое значение из команды `find .. -exec ..`?
  • Какой дистрибутив Linux похож на HP-UX?
  • Восстановление данных с 4-дискового NAS RAID 10
  • Автоматический запуск определенных скриптов при первом входе в систему / при запуске ПК
  • Есть идеи?

  • Редактирование текста влево и влево в тексте и выравнивании в mobaxterm на Linux
  • Невозможно найти объяснения о настройке «fanX_div» (lm-sensor)
  • Количество процессоров в / proc / cpuinfo
  • Проверка ядра linux для исправления RT-Preempt
  • Настройка кеша LVM для очень больших файлов
  • Облигации против агрегаторов
  • 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 - лучшая ОС в мире.