Proxmox LVM-thin «вичерпано простір даних»: звільнити місце без видалення віртуальних машин

October 7, 2025 • February 3, 2026 • Читання: 5 хв • Views: 6

Було корисно?

Ви помічаєте це спочатку, коли резервні копії не проходять. Потім віртуальна машина зависає під час запису. Потім Proxmox починає викидати помилки на кшталт
thin-pool ... out of data space і раптом ваш тихий віртуалізаційний хост поводиться як валіза, зібрана дитиною: нічого не влізає, а все розкидано.

Хороша новина: thinpool LVM, який показує «вичерпано простір даних», зазвичай можна відновити без видалення віртуальних машин. Погана новина:
треба діяти обережно, бо «звільнити місце» в thin-провізованому сховищі — не те саме, що видалити файли.
Виправляємо pool, а не «прибираємо навколо».

Що насправді означає «вичерпано простір даних» (і чого це не означає)

Сховище Proxmox local-lvm часто налаштовано як thin pool LVM: великий логічний том («thinpool»), з якого за потреби виділяються диски для ВМ (thin LV).
Можна зробити оверпровізію: показати 10 ТБ віртуальних дисків, покритих 2 ТБ реальних блоків, допоки гості фактично не запишуть усі ці дані.

Коли thinpool повідомляє, що «вичерпано простір даних», це означає, що LV даних пулу (частина, яка зберігає реальні блоки)
заповнений. Записи будь-яких thin-томів можуть затримуватися або зазнавати помилок. Залежно від налаштувань, LVM може призупинити pool, щоб уникнути корупції,
що виглядає як «усе зависло» на рівні ВМ.

Два ключових нюанси, які врятують вас від найгіршого рішення о 2-й ночі:

Видалення файлів всередині ВМ не обов’язково звільняє місце в thinpool, якщо не увімкнено і не виконано discard/TRIM.
Без discard хост усе ще вважає ці блоки зайнятими.
Снапшоти — не «безкоштовна страховка». Thin-снапшоти можуть сильно вирости, якщо базовий диск активно змінюється.
Снапшоти працюють за принципом копіювання при записі; постійна генерація змін перетворює їх на прихованих поглиначів місця.

Якщо ви запам’ятаєте одне: ваше завдання — визначити, чи pool вичерпався за рахунок даних, метаданих (metadata) чи обох, і потім
вибрати найменш ризиковий шлях для звільнення або додавання місця. Паніка — опціонально.

Жарт №1: thinpool не «закінчує місце», він просто «досягає повної ефективності» перед тим, як ваше SLA досягне нового мінімуму.

Швидкий план діагностики (перевірки першочергові/другорядні/третинні)

Це послідовність «не загубитися в деталях», яку я застосовую, коли мені сигналять про thinpool Proxmox.
Мета — знайти справжнє вузьке місце менше ніж за п’ять хвилин.

Перше: підтвердіть що саме повне (дані чи метадані) і чи pool призупинено

Перевірте використання thinpool за допомогою lvs (Data% та Meta%).
Подивіться стан пулу: активний, тільки для читання чи призупинений?

Друге: знайдіть що споживає блоки (снапшоти, бекапи, покинуті томи)

Перелік LV з розмірами і Data% щоб знайти активних записувачів.
Перегляньте снапшоти в Proxmox і в LVM (це можуть бути різні історії).
Перевірте наявність покинутих томів після видалення ВМ або невдалих відновлень.

Третє: оберіть аварійний важіль (звільнення vs розширення vs обидва)

Якщо можна швидко додати ємність: розширте VG і thinpool.
Якщо не можна: звільніть місце через видалення снапшотів і discard/trim, потім розгляньте тимчасові заходи.
Якщо метадані є обмежувачем: розширіть metadata негайно; це невелике та швидке і часто справжня причина.

Якщо вагаєтесь: розширення thinpool (дані + metadata) — найменш драматичний крок, якщо у VG є вільні екстенти або можна підключити диск.
Звільнення місця більш делікатне і часто дивує людей.

Цікаві факти та контекст (чому LVM-thin так поводиться)

Це не тривіальні факти заради тривіальностей. Кожен пункт відповідає за режим відмов або кращу операційну звичку.

Снапшоти LVM старші за thin provisioning і були відомі своїми крахами продуктивності. Класичні снапшоти використовували окремий COW-том і могли дуже сповільнюватися при майже повному обсязі; thin-снапшоти покращили механіку, але не прибрали правило «простір росте з обігом даних».
Thin provisioning — це обіцянка, а не гарантія. Математично можливо виділити більше віртуальної ємності, ніж фізично є; pool залишається здоровим, якщо зростання записів під контролем.
Thin pool має два обмеження: дані і метадані. Метадані відстежують відображення віртуальних блоків на фізичні. Можна мати багато вільного простору даних і все одно померти від нестачі метаданих.
Тиск на метадані зростає з фрагментацією і снапшотами. Більше відображень, більше COW-подій та більше змін на блочному рівні підвищують споживання метаданих.
Discard/TRIM не стали стандартною операційною практикою за одну ніч. Багато стеків за замовчуванням мали discard вимкненим роками через початкові проблеми з продуктивністю або непередбачуваною поведінкою на деяких накопичувачах.
За замовчуванням Proxmox «local-lvm» налаштовано на зручність, а не на досконалість. Це розумна відправна точка для лабораторій і невеликих кластерів, але очікує, що ви моніторите та налаштовуєте.
Автоматичне розширення thin pool існує, але це не няня. LVM може автоматично розширити thinpool при досягненні порога, але лише якщо у VG є вільні екстенти. Якщо VG теж повний — ви все одно вріжетеся в стіну.
Відновлення простору — це багаторівнева переговорна операція. Гостьова ОС має позначити блоки як вільні, файлова система має підтримувати trim, віртуальний шлях має передати discard, а thinpool має його прийняти.

Практичні завдання: команди, виводи, рішення

Нижче — реальні завдання, які можна виконати на вузлі Proxmox. Кожне містить: команду, типовий вивід та рішення, яке слідує з нього. Не копіюйте бездумно. Читайте вивід як діагностичний звіт — бо це він і є.

Завдання 1: Визначити thinpool і подивитися Data% та Meta%

cr0x@server:~$ sudo lvs -a -o+seg_monitor,lv_attr,lv_size,data_percent,metadata_percent,pool_lv,origin vg0
  LV                      VG  Attr       LSize   Data%  Meta%  Pool          Origin  Monitor
  root                    vg0 -wi-ao----  96.00g
  swap                    vg0 -wi-ao----   8.00g
  data                    vg0 twi-aotz--   1.60t  99.12  71.43                         monitored
  data_tmeta              vg0 ewi-ao----   8.00g
  data_tdata              vg0 ewi-ao----   1.60t
  vm-101-disk-0           vg0 Vwi-aotz--  80.00g                 data                 monitored
  vm-102-disk-0           vg0 Vwi-aotz-- 200.00g                 data                 monitored

Що це означає: Thinpool LV — це vg0/data (Attr починається з twi-). Data% = 99.12%: ви фактично на межі.
Meta% = 71.43%: метадані поки що не критичні, але тренд небезпечний.

Рішення: Розглядайте це як аварію. Зупиніть все, що інтенсивно записує (бекапи, відновлення, масивні логи) і оберіть — звільняти чи розширювати зараз.
Якщо Meta% було б 95–100%, пріоритарно розширюйте метадані.

Завдання 2: Перевірити чи thinpool призупинено (можуть зависати записи)

cr0x@server:~$ sudo dmsetup status /dev/vg0/data
0 3355443200 thin-pool 0 5118/524288 131072/1048576 - rw no_discard_passdown queue_if_no_space

Що це означає: Pool у режимі rw і встановлено queue_if_no_space. Це означає, що записи можуть ставати в чергу при заповненні
замість негайної помилки. Здається «безпечніше», поки це не викличе дедлок вашого навантаження і терпіння.

Рішення: Якщо ви застрягли в спіралі черг записів, треба звільнити або додати місце. Також подумайте, чи хочете ви мати queue_if_no_space довгостроково.

Завдання 3: Швидкий вигляд на рівні Proxmox: яке сховище повне?

cr0x@server:~$ pvesm status
Name      Type     Status           Total        Used       Avail      %
local     dir      active        100789248    22133704    73419180   21.96%
local-lvm lvmthin  active       1753219072  1738919936     14299136   99.18%

Що це означає: local (директорієве сховище) в нормі. local-lvm майже повний. Диски ВМ на local-lvm під загрозою.

Рішення: Сфокусуйтеся на ремедіації LVM-thin, а не на випадкових видаленнях у /var/lib/vz.

Завдання 4: Знайти найбільших порушників на рівні LV

cr0x@server:~$ sudo lvs -o lv_name,lv_size,lv_attr,data_percent,metadata_percent --sort -lv_size vg0
  LV            LSize   Attr       Data%
  data          1.60t   twi-aotz--  99.12
  vm-102-disk-0 200.00g Vwi-aotz--
  vm-101-disk-0  80.00g Vwi-aotz--
  root           96.00g -wi-ao----
  swap            8.00g -wi-ao----

Що це означає: Thin-томи не показують Data% тут (це рівень пулу), але видно, які ВМ мають великі віртуальні диски.
Великий віртуальний розмір не гарантує великих фізичних витрат, але це добрий короткий список «хто може багато писати».

Рішення: Корелюйте ці ВМ з останніми завданнями бекапу, обслуговуванням БД, спалахами логів або спурносними снапшотами.

Завдання 5: Перевірити детальний звіт thinpool (чанки, id транзакції, фічі)

cr0x@server:~$ sudo lvs -o+chunk_size,lv_health_status,thin_count,discards vg0/data
  LV   VG  Attr       LSize  Pool Origin Data%  Meta%  Chunk  Health  #Thins Discards
  data vg0 twi-aotz-- 1.60t             99.12  71.43  64.00k  ok      12     passdown

Що це означає: Розмір чанку 64K. Discards встановлено як passdown (добрий знак). Стан ok (він повний, але не пошкоджений).

Рішення: Якщо discards вимкнені тут, обрізання на хості не допоможе. Потрібно дозволити discard і запустити trims у гостях або на хості, де це доречно.

Завдання 6: Перелік снапшотів Proxmox («людські» снапшоти)

cr0x@server:~$ qm listsnapshot 102
`-> pre-upgrade
    `-> weekly-retain-1
`-> weekly-retain-2

Що це означає: VM 102 має кілька снапшотів. Кожен снапшот може закріплювати блоки і викликати ріст використання простору.

Рішення: Якщо немає місця, видаляйте снапшоти, які не потрібні — починаючи зі старих, після перевірки, що вони не входять в активний бекап/реплікацію.

Завдання 7: Безпечно видалити снапшот Proxmox (та на що звернути увагу)

cr0x@server:~$ qm delsnapshot 102 weekly-retain-2
Deleting snapshot 'weekly-retain-2'...
TASK OK

Що це означає: Proxmox запланував злиття снапшоту. На thin-сховищі злиття може створити I/O; вони також можуть тимчасово підвищити активність запису.
Це не причина уникати видалення; це причина робити його усвідомлено.

Рішення: Якщо пул на 99–100% — подумайте про зупинку важких записувачів перед злиттям, щоб воно не конфліктувало з активним навантаженням.

Завдання 8: Виявити покинуті LVs (проблема «храниться привид»)

cr0x@server:~$ sudo lvs vg0 | grep -E 'vm-[0-9]+-disk-[0-9]+' | awk '{print $1}'
vm-101-disk-0
vm-102-disk-0
vm-109-disk-0
vm-999-disk-0

cr0x@server:~$ ls /etc/pve/qemu-server/ | sed 's/\.conf$//' | sort | tail -n +1
101
102
109

Що це означає: Є vm-999-disk-0 LV, але немає 999.conf. Цей диск, ймовірно, покинутий: створений під час невдалого відновлення,
клонування або ручних змін.

Рішення: Підтвердіть, що він справді не використовується, і тільки потім видаліть його, щоб звільнити місце. Не видаляйте просто через «виглядає дивно» — видаляйте, коли довели.

Завдання 9: Довести, що підозрілий orphan не посилається з конфігів ВМ

cr0x@server:~$ grep -R "vm-999-disk-0" /etc/pve/qemu-server/

cr0x@server:~$ echo $?
1

Що це означає: Код виходу 1 означає «не знайдено». Це доказ (не абсолютне), що том не підключений.

Рішення: Також перевірте запущені процеси QEMU і мапінги блок-пристроїв перед видаленням.

Завдання 10: Підтвердити, що жодна запущена ВМ не має LV відкритим

cr0x@server:~$ sudo lsof | grep "/dev/vg0/vm-999-disk-0" | head

Що це означає: Відсутність виводу підказує, що нічого не має його відкритим. На завантаженому хості lsof може бути важким; використовуйте обережно.

Рішення: Якщо він не відкритий і не посилається в конфігах — можна видаляти.

Завдання 11: Видалити покинутий thin LV

cr0x@server:~$ sudo lvremove -y /dev/vg0/vm-999-disk-0
  Logical volume "vm-999-disk-0" successfully removed.

Що це означає: Ви видалили LV-мапу. Місце має повернутися у пул негайно (хоча метадані thin і облік ядра можуть оновитися з невеликим лагом).

Рішення: Перевірте знову Data% і Meta% thinpool, щоб підтвердити вплив. Якщо нічого не змінилося — ви не видалили те, що треба, або причиною є метадані.

Завдання 12: Повторно перевірити використання пулу після видалень

cr0x@server:~$ sudo lvs -o lv_name,lv_size,data_percent,metadata_percent vg0/data
  LV   LSize  Data%  Meta%
  data 1.60t  96.44  70.90

Що це означає: Ви відкотили близько ~3% від пулу. Це може розблокувати операції, але не є вирішенням, якщо ріст продовжиться.

Рішення: Якщо ви все ще вище ~90% і триває високе навантаження, розширюйте пул. Звільнення — тимчасовий захід, якщо не змінити поведінку.

Завдання 13: Перевірити вільне місце VG (можна розширити без додавання дисків?)

cr0x@server:~$ sudo vgs -o vg_name,vg_size,vg_free,vg_free_count
  VG   VSize  VFree   #VFree
  vg0  1.80t  180.00g 46080

Що це означає: У вас 180G вільно у volume group. Ви можете зараз розширити thinpool.

Рішення: Розширте data LV thinpool і подумайте про розширення метаданих теж. Зробіть обидва; це недорога страховка.

Завдання 14: Розширити data thinpool (онлайн), а потім metadata (онлайн)

cr0x@server:~$ sudo lvextend -L +150G /dev/vg0/data
  Size of logical volume vg0/data changed from 1.60 TiB (419430 extents) to 1.75 TiB (458752 extents).
  Logical volume vg0/data successfully resized.

cr0x@server:~$ sudo lvextend -L +2G /dev/vg0/data_tmeta
  Size of logical volume vg0/data_tmeta changed from 8.00 GiB (2048 extents) to 10.00 GiB (2560 extents).
  Logical volume vg0/data_tmeta successfully resized.

Що це означає: Дані зросли на 150G. Метадані зросли на 2G. Thin-метадані невеликі, але критичні; зазвичай розумно розширювати проактивно.

Рішення: Повторно перевірте Data% і Meta% після цього. Якщо Meta% лишається дуже високим — можливо потрібна більша metadata або менше снапшотів/змін.

Завдання 15: Перевірити, чи thinpool тепер здоровий і має запас

cr0x@server:~$ sudo lvs -o lv_name,lv_size,data_percent,metadata_percent vg0/data
  LV   LSize  Data%  Meta%
  data 1.75t  88.12  56.41

Що це означає: Ви купили запас повітря. 88% — ще «пильнуйте», але ви вже не на межі катастрофи.

Рішення: Тепер запобігайте повторенню: увімкніть discard скрізь, зменшіть зберігання снапшотів і налаштуйте оповіщення.

Завдання 16: Якщо у VG немає вільного місця — додайте новий диск і розширте VG

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT
NAME         SIZE TYPE FSTYPE      MOUNTPOINT
sda        1.8T  disk
├─sda1       1M  part
├─sda2     1G  part ext4         /boot
└─sda3   1.8T  part LVM2_member
  ├─vg0-root  96G lvm  ext4         /
  ├─vg0-swap   8G lvm  swap         [SWAP]
  └─vg0-data 1.75T lvm
sdb        1.0T  disk

cr0x@server:~$ sudo pvcreate /dev/sdb
  Physical volume "/dev/sdb" successfully created.

cr0x@server:~$ sudo vgextend vg0 /dev/sdb
  Volume group "vg0" successfully extended

cr0x@server:~$ sudo vgs -o vg_name,vg_size,vg_free
  VG   VSize  VFree
  vg0  2.80t  1.03t

Що це означає: Ви додали фізичну ємність. Тепер можна знову розширити thinpool.

Рішення: Розширте vg0/data і (за бажанням) vg0/data_tmeta. Потім налаштуйте моніторинг, щоб не повторювати цю історію.

Завдання 17: Увімкнути щотижневий TRIM для гостей, де це доречно (і підтвердити)

cr0x@server:~$ systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
     Loaded: loaded (/lib/systemd/system/fstrim.timer; enabled)
     Active: active (waiting)

Що це означає: Гості з systemd можуть періодично скидати невикористані блоки. Це одне з небагатьох «налаштуй і забув» рішень, яке працює.

Рішення: Переконайтеся, що discard дозволений у налаштуваннях диска ВМ і підтримується файловою системою/сховищем. Якщо ні — ви просто плануєте надію.

Завдання 18: Перевірити, чи диск ВМ налаштований на pass discard (Proxmox)

cr0x@server:~$ qm config 102 | grep -E 'scsi|virtio|sata'
scsi0: local-lvm:vm-102-disk-0,discard=on,iothread=1,size=200G

Що це означає: Для того диска встановлено discard=on. Добре. Без цього guest TRIM не дійде до thinpool.

Рішення: Для дисків, з яких хочете звільнення, увімкніть discard. Для чутливих до латентності навантажень — тестуйте спочатку, але в більшості випадків слід увімкнути.

Варіанти відновлення без знищення ВМ

Коли вичерпано простір даних, у вас є три реальні важелі: зупинити записи, звільнити блоки та додати ємність. Найкраще рішення зазвичай поєднання.
Неправильне рішення — «видаляти випадкові речі, поки помилка не зникне».

Опція A: Видалити непотрібні снапшоти (найшвидше «реальне» звільнення)

Якщо у вас є старі снапшоти — це перше місце для перевірки. Снапшоти закріплюють старі версії блоків і тримають дані, які інакше були б повторно використовувані.
Видалення може звільнити багато місця, але злиття створює I/O — тож робіть це свідомо.

Коли робити: пул повний, є снапшоти і ви можете терпіти деяке злиття.
Коли уникати: снапшот потрібен як активна точка відкату під час планової операції (рідко).

Опція B: Видалити орфанні томи та сміття від невдалих відновлень (рух «підмести склад»)

Proxmox загалом охайний, але люди творчі. Орфани з’являються після невдалих бекапів, перерваних відновлень або ручних LVM-редагувань.
Це може бути чиста, малоризикова вигода — якщо спочатку перевірити посилання.

Опція C: Розширити thinpool (нудна, зазвичай найкраща опція)

Якщо volume group має вільні екстенти — розширення thinpool швидке і онлайн. Якщо ні — додайте диск і розширте VG.
З операційної точки зору це найвпевненіша дія: негайно знімає тиск.

Опція D: Звільнення всередині гостей через TRIM (добре, але не миттєво)

Звільнення не магічне. Гість має віддати discard, віртуальний контролер має пропустити його, а thinpool має прийняти.
Також: гість може не виконувати discard автоматично, поки ви його не запустите (fstrim) або не змонтуєте з continuous discard (не завжди рекомендовано).

Опція E: Тимчасова триаж: зупинити течію крові

Якщо ви на 99–100% і ВМ зависають — негайна дія: зупиніть завдання з високою інтенсивністю запису:
бекапи, відновлення, агрегацію логів, вакуум/компактацію БД, індексацію, CI-артефактне сміття.
Ви не «вирішуєте проблему», ви зупиняєте каскадний відмовний ефект, поки створюєте простір.

Жарт №2: Найшвидший спосіб звільнити сховище — призначити вікно технічного обслуговування; раптом усі пам’ятають, що можна видалити.

Три корпоративні історії з тонкопулових фронтів

Міні-історія 1: Інцидент через неправильне припущення

Середня організація тримала Proxmox-кластер для внутрішніх сервісів: Git, CI-ранери, кілька аплікаційних серверів і базу даних, яку всі «робили вигляд», що вона не продукційна,
бо не орієнтується на клієнтів. Вона жила на local-lvm, тон-провізинг з щедрими віртуальними дисками. Моніторинг дивився на хост-файлову систему,
а не на thinpool. Все виглядало зеленим — допоки ні.

Неправильне припущення було просте: «Якщо гість видаляє файли, хост отримує місце назад». Їхні CI-ранери генерували артефакти, завантажували їх і чистили робочі каталоги.
Всередині ВМ місце виглядало вільним. На хості thinpool піднімався. Ніхто не помічав, бо не дивився на Data%.

Потім оновлення ОС створило пакети, логи виросли, CI запрацював інтенсивно й thinpool перетнув межу. Записи стали в чергу. CI зупинився. Git сповільнився.
База почала часами чекати, бо fsync не завершувався. Здавалося, що «мережа хитка», поки хтось не перевірив LVM.

Виправлення не було героїчним: увімкнули discard на дисках ВМ, увімкнули щотижневий fstrim у гостях, видалили старі снапшоти і розширили пул на кілька сотень гіг.
Культурна зміна була важливішою: додали моніторинг thinpool і перестали вважати local-lvm «безкінечним через thin».

Ніхто не був звільнений. Але ставлення команди до «припущень» змінилося назавжди. Thin provisioning — це контракт з реальністю, а реальність читає дрібний шрифт.

Міні-історія 2: Оптимізація, яка вдарила в спину

Інший підрозділ хотів «швидші бекапи». Вони робили снапшоти зайнятої ВМ і запускали часті джоби бекапу. Щоб зменшити час бекапу, вони збільшили частоту снапшотів
і зберігали більше точок відновлення. Графіки виглядали добре — поки thinpool не вичерпався.

Снапшоти дешеві при створенні. Ось у чому пастка. ВМ була логонавантаженим сервером з постійними записами. Кожен снапшот закріплював старі блоки; чим більше снапшотів,
тим більше версій «гарячих» блоків існувало одночасно. Thinpool заповнювався швидше саме тому, що їхня «оптимізація» зберігала обіг.

Коли thinpool досяг ліміту, саме джоб бекапу, який «робив безпечніше», став тригером простою. Ще гірше: видалення снапшотів під час інциденту викликало
сплеск merge-операцій у той момент, коли система вже була під I/O-стресом. Це злиття не був ворогом, але точно не була заспокійлива колискова.

Довгострокове виправлення було контрінтуїтивним: менше снапшотів, розумніший графік бекапів і винесення високочастотних навантажень на окреме сховище, розраховане на обіг.
Вони також ввели авто-розширення thinpool з правилом «VG має мати вільні екстенти» і оповіщенням при низькому вільному просторі.

Продуктивність покращилася. Надійність — теж. Скарга «бекапи повільні» перетворилася на «бекапи нудні», що є найвищою похвалою для операційників.

Міні-історія 3: Нудна, але правильна практика врятувала день

Консервативна команда вела Proxmox для внутрішніх платформ. У них була проста, майже нудна політика: кожен бекенд сховища мав оповіщення на трьох рівнях (попередження, терміново,
зупинити світ), а thinpool ставився як продакшн-база даних — планування ємності, а не надія.

Вони також мали звичку, що звучить як паперова робота: після кожного тесту відновлення або міграції вони запускали «прибирання орфанів», щоб переконатися, що не залишилися зайві томи.
Це був невеликий скрипт і невелике нагадування в календарі. Люди іноді скрушно посміхалися.

Одного дня тест відновлення зупинився наполовину через мережевий збій. Він залишив кілька великих thin-томів. Наступного дня прибирання орфанів їх виявило.
Видалили сміття — і все добре. Жодного інциденту. Жодного екстреного розширення. Жодних нічних дзвінків.

Через місяці схожий збій відновлення трапився у завантажений період. Але та сама нудна практика спрацювала. Хост ніколи не досяг краю, бо команда не дозволяла накопичуванню безвласного стану.

Урок не в «бути параноїком». Урок — «бути рутинним». Більшість відмов утворюються не через екзотичні баги, а через повільне накопичення невідомого стану.

Поширені помилки: симптом → корінь → виправлення

Це патерни, які я бачу у реальних Proxmox-середовищах. Якщо щось співпадає з вашою ситуацією — не сперечайтесь, дійте.

1) Симптом: thinpool повний, але в гості вільно місця вдосталь

Корінь: Discard/TRIM не доходить до thinpool або ніколи не виконувався.
Виправлення: Увімкніть discard=on для дисків ВМ; увімкніть і запустіть fstrim у гостях; підтвердіть, що discards пулу — passdown.

2) Симптом: «вичерпано простір даних» раптово після увімкнення частих снапшотів

Корінь: Утримання снапшотів + високий обіг. COW закріплює старі блоки; обіг множить споживаний простір.
Виправлення: Зменшіть кількість/термін зберігання снапшотів; плануйте снапшоти під час низького обігу; розширте пул; розгляньте виділення високочастотних ВМ на окреме сховище.

3) Симптом: Data% пулу помірний, але записи все одно падають або пул здається завислим

Корінь: Метадані заповнені (Meta% близько 100%) або ризик корупції метаданих.
Виправлення: Розширити data_tmeta; зменшити кількість снапшотів; знизити фрагментацію/обіг; перевірити стан і розглянути обслуговування при підозрі на корупцію.

4) Симптом: ви видалили ВМ, але використання thinpool мало змінилося

Корінь: Диски ВМ фактично не на тому thinpool, або є додаткові снапшоти/орфани, або ви видалили конфіг, але не диски.
Виправлення: Перевірте qm config і мапінг сховищ; перелічіть LVs; видаліть орфанів; підтвердіть, що Proxmox налаштовано видаляти диски при видаленні ВМ.

5) Симптом: після звільнення місця пул все ще близький до повного

Корінь: Звільнені блоки не були відправлені discard; облік thinpool або ядра відстає; або ви звільнили місце в іншому сховищі (директорія vs lvmthin).
Виправлення: Перевірте знову за pvesm status і lvs; запустіть trims; підтвердіть discards; переконайтеся, що працюєте з local-lvm.

6) Симптом: злиття/видалення снапшотів погіршує продуктивність під час інциденту

Корінь: Видалення снапшотів викликає cleanup/merge I/O у найгірший можливий час.
Виправлення: Спочатку зупиніть важкі задачи запису; видаляйте снапшоти стратегічно; якщо можливо, додайте ємність перед злиттями, щоб знизити тиск.

Контрольні списки / покроковий план

Аварійний чекліст (thinpool 95–100%)

Зупиніть гучних записувачів: призупиніть бекапи/відновлення, зупиніть потоки логів, відкладіть обслуговування бази даних.
Мета — припинити прискорене виведення в стіну.
Підтвердіть проблему: запустіть pvesm status і lvs для Data% і Meta%.
Видаліть низькоцінні снапшоти: почніть зі старих і найменш виправданих. Залишайте «той, що може знадобитися» тільки, якщо він справді потрібен.
Видаліть доведені орфани: grep по конфігах, перевірте відкриті дескриптори, потім lvremove.
Розширте thinpool, якщо можете: перевірте vgs; якщо VG має вільні екстенти — розширяйте зараз.
Проактивно розширте метадані: особливо якщо Meta% > 70% і ви використовуєте снапшоти.
Перевірте стан: підтвердіть, що Data% опустився до безпечнішого діапазону і ВМ відновилися.

Чекліст стабілізації (після зупинки кровотечі)

Увімкніть discard скрізь: налаштування диска Proxmox discard=on, гостева ОС виконує trims, thinpool приймає discards passdown.
Визначте політику снапшотів: обмежте кількість, вік і синхронізуйте з патернами обігу.
Впровадьте оповіщення: попередження на 70–80%, терміново на 85–90%, критично на 95% для Data% і Meta% thinpool.
Вимірюйте обіг: визначте ВМ, які постійно пишуть; розглядайте їх як множники ємності.
Тестуйте процеси відновлення: невдалі відновлення — головне джерело орфанів.

Чекліст планування ємності (щоб не повертатися до цього)

Визначте коефіцієнт оверпровізингу: оберіть показник, який можете захистити (наприклад, 2:1) і впровадьте культурно.
Відстежуйте швидкість росту thinpool: якщо Data% зростає на 1–2% на день — ви на зворотному відліку.
Тримайте вільний простір у VG: якщо ви покладаєтесь на авто-розширення, тримайте вільні екстенти. Інакше авто-розширення — просто приємна ідея.
Розділяйте навантаження: розміщуйте високочастотні ВМ на сховищі, розрахованому на обіг, а не на тому ж thinpool, що й «тихі» інфраструктурні ВМ.

Запобігання: зробіть це нудним і постійним

Аварія thinpool зазвичай не одинична. Це відкладений рахунок за попередню зручність: оверпровізинг без моніторингу, снапшоти без дисципліни збереження
і гості, які видаляють дані без discard.

Моніторинг, який справді працює

Слідкуйте за Data% і Meta% thinpool LV. Не покладайтеся на «вільний диск» всередині гостей. Не покладайтеся на df -h на файловій системі хоста.
Це різні шари з різними істинами.

Практичне правило: оповіщайте досить рано, щоб можна було реагувати в робочий час. Мета — не спіймати 99%, а запобігти досягненню критичної межі.

Дисципліна зі снапшотами

Снапшоти — це операційний борг з наростаючими відсотками. Зберігайте їх, коли вони мають сенс: коротка страховка для ризикової зміни.
Не тримайте їх «бо сховище дешеве». При thin provisioning сховище не дешеве — воно просто відкладено.

Discard: увімкніть, а потім доведіть, що працює

Увімкнення discard на диску Proxmox необхідне, але не достатнє. Гості мають виконувати trims. Деякі файлові системи і робочі навантаження виграють від періодичного fstrim
більше, ніж від безперервного mount з discard. Тестуйте на своєму навантаженні, але не пропускайте цей крок.

Autoextend: добрий слуга, поганий господар

Авто-розширення LVM може врятувати від повільного зростання сюрпризів, але воно не створює місце з нічого. Воно лише споживає вільні екстенти VG.
Якщо ви витиснете VG до нуля вільного простору, авто-розширення стане хибним відчуттям безпеки — як запасне колесо з картону.

Цитата, що тримає чесність

Парафраз ідеї від John Allspaw: надійність визначається тим, як система поводиться під навантаженням, а не бажанням, щоб навантаження не траплялося.

Часті питання

1) Чи можна виправити «вичерпано простір даних» без перезавантаження Proxmox-хоста?

Зазвичай так. Розширення thinpool і видалення снапшотів/орфанів здебільшого онлайн-операції. Перезавантаження потрібні, коли ви викопали глибшу яму (або при проблемах з ядром/драйверами),
а не для базових проблем з ємністю.

2) У чому різниця між простором «data» і «metadata» thinpool?

Дані — це фактичні блоки, що зберігають диски ВМ. Метадані — база відображень, яка тримає, де знаходиться кожен віртуальний блок у пулі і як пов’язані снапшоти.
Можна вичерпати будь-який з них, і симптоми можуть бути схожі.

3) Чому видалення файлів у ВМ не звільняє місце на хості?

Бо thinpool знає про повторне використання блоків тільки коли отримує discards. Видалення файлу позначає блоки вільними всередині файлової системи, але без TRIM/discard
нижній рівень все ще вважає ці блоки зайнятими.

4) Чи безпечно увімкнути `discard=on` для всіх ВМ?

Для більшості загальних навантажень — так, і це зазвичай правильний дефолт для thin provisioning. Для деяких чутливих до латентності навантажень — тестуйте спочатку.
Більший ризик — це працювати з thin без рекламації і дивуватися, коли він заповниться.

5) Я видалив снапшоти, але Data% майже не змінився. Чому?

Або снапшоти не були головним споживачем, або пул заповнений активними даними, що все ще посилаються поточними дисками, або ви обмежені метаданими.
Також «майже не змінився» може бути значущим на багатотерабайтному пулі; перевірте lvs і корелюйте з джерелами обігу.

6) Чи варто додати більше місця для метаданих, навіть якщо Meta% не високий?

Якщо ви широко використовуєте снапшоти або маєте високий обіг — так, у розумних межах. Розширення метаданих дешевше, ніж інцидент, коли Meta% досягає 100% і пул рушить.

7) Чи можна зменшити диск ВМ, щоб звільнити місце в thinpool?

Стискання можливе, але рідко перше рішення: воно вимагає зменшення файлової системи всередині гостя (і це не завжди підтримується), і це операційно ризиково.
Віддайте перевагу reclamation через discard і очищенню снапшотів. Якщо можна — розширюйте ємність.

8) Яка найбезпечніша «перша дія», коли пул на 99% і ВМ повільні?

Зупиніть або призупиніть найбільших генераторів записів (бекапи/відновлення/лог-шторм), потім створіть місце шляхом видалення снапшотів/орфанів або розширення пулу.
Не починайте «прибирання» всередині гостя в надії, що воно дійде до хоста. Надія — це не драйвер сховища.

9) Чому він заповнився так швидко, коли розміри дисків ВМ не такі великі?

Заповнення thinpool залежить від фізично записаних блоків, а не від віртуального розміру дисків. Шаблони високого обігу (БД, логи, CI), плюс снапшоти, можуть помножити фізичне використання дуже швидко.

10) Якщо я розширю thinpool, чи Proxmox автоматично це побачить?

У більшості випадків — так; Proxmox читає стан LVM і відобразить нову ємність у pvesm status. Якщо не оновлюється миттєво, перевірте, що ви розширили потрібний LV
і що дефініція сховища вказує на цей пул.

Висновок: що зробити сьогодні

Якщо читаєте це під час інциденту — зробіть три речі в порядку: підтвердіть, чи переповнені дані або метадані, звільніть простір видаленням снапшотів і доведених орфанів,
потім розширте thinpool (і metadata), якщо маєте можливість додати ємність. Це виведе вас із небезпечної зони без знищення ВМ.

Потім зробіть те, що запобіжить сиквелу: увімкніть discard наскрізь, запускайте trims, встановіть політику збереження снапшотів як доросла людина і додайте моніторинг Data% та Meta% thinpool.
Зробіть сховище нудним знову. Ваше майбутнє «я» вже втомлене.