Форум русскоязычного сообщества Ubuntu


Получить помощь и пообщаться с другими пользователями Ubuntu можно
на irc канале #ubuntu-ru в сети Freenode
и в Jabber конференции ubuntu@conference.jabber.ru

Автор Тема: KVM \ динамические диски растут без видимой причины  (Прочитано 1098 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн sobakkas

  • Автор темы
  • Новичок
  • *
  • Сообщений: 3
    • Просмотр профиля
доброго дня.
оговорюсь, что уже длительное время использую KVM в качестве гипервизора и некоторое понимание (хочется верить) есть.

анамнез:
есть гипервизор с ubuntu server 18.04
KVM - это почти единственное, что устанавливалось на хост.
так же проделаны
apt update
apt upgrade

создаю диски:
qemu-img create -f qcow2 -o preallocation=off os_1.img 100Gи
qemu-img create -f qcow2 -o preallocation=off data_1.img 2Tдиски весят 198'208 B и 229'376 B соответственно.

диски data_1.img копирую в data_2.img, os_1.img в os_2.img и диски *_2.img откладываю в сторонку.

далее на диск os_1.img устанавливается ubuntu server 20.04 и уже в гостевой проделываются:
apt update
apt upgrade
больше ничего в гостевой не устанавливается и ничего не настраивается.
диск os_1.img теперь занимает 5'338'368 KiB

далее через гуй VMM большой диск монтируется в гостевую.
или командой ниже - на результат эксперимента не влияет.
virsh attach-disk guest4test data_1.img vdb --targetbus virtio --driver qemu --cache none --subdriver qcow2 --config
далее в гостевой форматирую:
mkfs.ext4 /dev/vdbесли предварительно fdisk'ом создать раздел vdb1 - на результат эксперимента не влияет.
в это время data_1.img занимает 1'206'784 KiB
добавляю uid в fstab

запускаю mount -a и... начинаю недоумевать.
диск data_1.img начинает увеличиваться в объёме. и останавливается только после достижения ~35 Gb.
внутри гостевой не происходит никаких процессов, кроме дефолтных. не устанавливается и не запускается никакой софт. ничего не копируется на диск data_1.img и не создаются какие либо файлы.
можно даже не монтировать диск, а просто после добавления в fstab перезагрузить гостевую ОСь и потом в неё даже не логиниться.
диск растёт.

если в гостевой зайти на диск - то видно, что нет ничего, кроме пустого каталога lost+found
df -hв гостевой возвращает
/dev/vdb        2.0T  121M  1.9T   1% /mnt/2T
в гипервизоре про этот диск видно так:
#virt-df -h data_1.img
Filesystem                                Size       Used  Available  Use%
data_1.img:/dev/sda        2.0T       120M       1.9T    1%

#qemu-img info data_1.img
image: data_1.img
file format: qcow2
virtual size: 2.0T (2199023255552 bytes)
disk size: 33G
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

диск os_1.img по прежнему занимает 5'338'368 KiB, т.е. не увеличился в размерах.

далее тот же процесс проделывается с дисками os_2.img и data_2.img и win10 20h2
после инсталяции ОС диск os_2.img занимает 12'253'120 KiB, а после подключения, создания раздела и форматирования диск data_2.img занимает 157'254 KiB (157 Mb).
и ни один из дисков далее самопроизвользо не распухает.

в первом приближении я бы сформулировал вопрос так: чо за херня? куда копать?
и да, я понимаю\предполагаю, что это какая то не штатная уникальная ситуация и на другом гипервизоре вероятно не повторится.
« Последнее редактирование: 27 Сентября 2021, 13:24:01 от sobakkas »

Оффлайн Morisson

  • Модератор раздела
  • Старожил
  • *
  • Сообщений: 4808
    • Просмотр профиля
Отредактируйте свое сообщение согласно правил форума, в противном случае оно будет удалено.
« Последнее редактирование: 27 Сентября 2021, 14:33:09 от Morisson »

Оффлайн valrust

  • Активист
  • *
  • Сообщений: 342
    • Просмотр профиля
Мое предположение происходящего.

Создали образ виртуального диска и подключили его к виртуальной машине. Система виртуализации считает, что все блоки на этом диске заполнены нулями и пока файл data_1.img имеет минимальную длину.

Внутри гостевой ОС форматируем диск, а затем монтируем его. Возможно после монтирования файловой системы ядро Linux запускает в фоновом режиме процесс расчета контрольных сумм для inode и записывает эти данные в соответствующие сектора виртуального диска. Так как сектора изменились, то система виртуализации должна сохранить их в файл data_1.img.

Для 2 TiB диска при форматировании создаются 134'217'728 inode. Каждый inode имеет размер 256 байт. Т.е. в одном секторе виртуального диска храниться 2 inode.

Таким образом если в каждом inode сохранить контрольную сумму, то изменяться 67'108'864 сектора на виртуальном диске. Что бы зафиксировать эти изменения системе виртуализации нужно будет сохранить все изменённые секторы в файл виртуального диска, а это составит 67'108'864 * 512 = 32 GiB.

Для 2 TiB диска при форматировании еще создается журнал размером 1 GiB, который занимает 2'097'152 секта на виртуальном диске. При создании журнала так же происходит изменение секторов в которых он располагается.

Таким образом вполне вероятно, что размер файла с образом виртуального диска изменить на 34 GiB, так как именно такой объем будет изменённых секторов виртуального жесткого диска.

Оффлайн sobakkas

  • Автор темы
  • Новичок
  • *
  • Сообщений: 3
    • Просмотр профиля
valrust, большое спасибо за такой подробный ответ.
звучит чертовски логично и похоже на правду. мне он очень нравится и что то в этом духе я тоже предполагал (признаюсь, хотя и без такой подробной математики), но такой ответ пораждает ещё вопросы и сомнения:
- не придумал сам и не нашёл какого то понятного способа как проверить и подтвердить\опровергнуть, что происходит именно это и именно так. возможно можете что то посоветовать в куда посмотреть?
- почему так сильно не разрастаются другие диски, например этой же самой гостевой, но с ОС (на этом конкретном гипервизоре много виртуалок в т.ч. и с разными линуксами, да и конкретно этот эксперимент я проделал уже наверное десяток раз)?
- этот же эксперимент был повторен "на соседнем компьютере", только в качестве гипервизора выступила lubuntu 20.04 и 2Tb диск не стал разрастаться ни после монтирования его в ОС, ни после создания на нём тестового файлика. т.е. либо эти индексы не так уж и нужны самой гостевухе, либо (что мне кажется более вероятным) гипервизор умеет сам как то расчитывать и учитывать всю эту математику снаружи и сообщать в гостевую уже какой то конечный набор инструкций как себя вести. а в случае с первоначальным вопросом этого не происходит (или происходит, но не так как должно) по причине какого то локального сбоя. и... и на этом моя мысль останавливается.

Оффлайн valrust

  • Активист
  • *
  • Сообщений: 342
    • Просмотр профиля
Мое предположение описанное выше подтвердились экспериментом и информацией из man страницы.

Эксперимент выполнил без использования виртуальной машины. Думаю так же будет работать и в виртуальной машине, желующие могут проверить.

Создал файл data_1.img с образом виртуального диска:
qemu-img create -f qcow2 -o preallocation=off data_1.img 2TПосле создания файл data_1.img имел размер 224KiB. Размер файл проверял командой:
du -h data_1.img
Далее загрузил модуль ядра nbd (Network Block Device)
sudo modprobe nbdСоединил блочное устройство /dev/nbd0 с файлом образа виртуального диска data_1.img:
sudo qemu-nbd -c /dev/nbd0 data_1.imgОтформатировал блочное устройство /dev/nbd0:
sudo mkfs.ext4 /dev/nbd0После форматирования размер файла data_1.img увеличился до 1,2GiB. Это вполне нормально, так как при форматировании изменяются блоки, где расположен журнал и изменяются некоторые другие служебные блоки.

Потом я смонтировал устройство /dev/nbd0 в каталог /mnt:
sudo mount /dev/nbd0 /mnt/После монтирования размер файла data_1.img начал постепенно увеличиваться.

Я запустил утилиту iotop:
sudo iotopи увидел активность процесса ядра с именем [ext4lazyinit].

Периодический запуск iostat для устройства /dev/nbd0
sudo iostat /dev/nbd0показал, что увеличивается значение "kB_wrtn", т.е. на блочное устройство идет запись.

И в man 8 mke2fs нашел этому подтверждение. В описании опции lazy_itable_init сказано, что ядро в фоновом режиме завершает инициализацию файловой системы.
(Нажмите, чтобы показать/скрыть)

Пользователь добавил сообщение 30 Сентября 2021, 00:37:09:
- не придумал сам и не нашёл какого то понятного способа как проверить и подтвердить\опровергнуть, что происходит именно это и именно так. возможно можете что то посоветовать в куда посмотреть?
После монтирования можно использовать iotop для отслеживания процессов с дисковой активностью.

- почему так сильно не разрастаются другие диски, например этой же самой гостевой, но с ОС (на этом конкретном гипервизоре много виртуалок в т.ч. и с разными линуксами, да и конкретно этот эксперимент я проделал уже наверное десяток раз)?
Увеличение файла виртуального диска зависит от размера виртуального диска.

- этот же эксперимент был повторен "на соседнем компьютере", только в качестве гипервизора выступила lubuntu 20.04 и 2Tb диск не стал разрастаться ни после монтирования его в ОС, ни после создания на нём тестового файлика.
Это я не могу объяснить. Если только была ошибка при создании файла виртуального диска и размер получился не 2 Tb, а меньше.
« Последнее редактирование: 30 Сентября 2021, 00:40:38 от valrust »

Оффлайн sobakkas

  • Автор темы
  • Новичок
  • *
  • Сообщений: 3
    • Просмотр профиля
valrust, ещё раз спасибо.
направление "куда копать" понятно, пойду упражняться дальше.

 

Страница сгенерирована за 0.022 секунд. Запросов: 21.