Перейти до змісту

27. Обслуговування та видалення тому

Work in progress

Обслуговування StudioFS охоплює кілька різних завдань: перевірку метаданих, пошук зайвих об’єктів у S3, видалення локальних даних клієнта або остаточне видалення тому. Для кожного завдання є окрема команда. Почнімо з перевірки, а до видалення перейдемо лише після того, як з’ясуємо його наслідки.

Перевірка метаданих: fsck

fsck шукає неузгодженості у структурі файлової системи: записи каталогів без відповідного об’єкта метаданих, об’єкти без зв’язку з каталогом, неправильну кількість посилань та незавершені службові операції. Для тому з PostgreSQL команда спочатку синхронізує локальні метадані з сервером, а потім будує звіт.

Звичайний запуск fsck може змінити дані ще до підтвердження виправлень. Уже підготовча синхронізація оновлює локальну базу. Якщо знайдено проблеми, команда пропонує їх виправити. Для першого огляду не погоджуйтеся: на запит Repair all detected issues now? [y/N]: натисніть Enter або введіть n.

studiofs fsck myvolume

У звіті зверніть увагу на такі рядки:

Поле Що означає
dangling dentries Записи каталогів, що посилаються на відсутні об’єкти метаданих
orphan inodes Об’єкти метаданих, не приєднані до дерева каталогів
nlink mismatches Розбіжності в кількості посилань
pending creates, deferred deletes, поля undo Службовий стан незавершених операцій

Повідомлення No issues found. означає, що перевірка не виявила відповідних проблем у метаданих. Воно не підтверджує цілісність усіх файлів у S3 і не доводить справність резервної копії.

Коли потрібне виправлення

Виправлення змінює метадані й може видалити записи та об’єкти, які команда вважає некоректними. Перш ніж погодитися, зупиніть роботу StudioFS на всіх клієнтах і підготуйте резервні копії. Не підтверджуйте виправлення лише тому, що у звіті є ненульові числа.

Можна погодитися на виправлення після перегляду звіту звичайного fsck. Окремий прапорець запускає його без додаткового запиту:

studiofs fsck myvolume --repair

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

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

Зайві об’єкти у S3: janitor

Після видалень у сховищі можуть залишатися об’єкти, на які вже немає посилань у метаданих. janitor шукає такі кандидати й враховує захист об’єктів знімками. Він не очищує SSD вашого комп’ютера і не замінює fsck.

Починайте з попереднього перегляду:

studiofs janitor myvolume --dry-run

--dry-run не видаляє об’єкти у S3. Команда все одно читає метадані та звертається до віддалених служб; це не автономна перевірка локального кешу.

У підсумку scanned — кількість переглянутих файлів-об’єктів, orphan candidates — кількість кандидатів без посилань, а would delete — скільки об’єктів було б видалено за поточними обмеженнями. Кандидати й заплановані видалення можуть відрізнятися: команда пропускає надто нові об’єкти, об’єкти з невідомим віком та об’єкти понад ліміт циклу.

Типово віковий поріг становить 15 хвилин, а ліміт — 500 об’єктів за цикл. Для обережнішого попереднього перегляду можна збільшити поріг і зменшити ліміт:

studiofs janitor myvolume --dry-run --skip-newer-minutes 60 --max-deletes 100

Без --dry-run команда справді видаляє об’єкти у S3, без окремого інтерактивного підтвердження. Запускайте очищення лише після перевірки звіту, резервних копій та стану синхронізації всіх клієнтів. Віковий поріг і ліміт зменшують обсяг одного проходу, але не гарантують збереження даних.

studiofs janitor myvolume --skip-newer-minutes 60 --max-deletes 100

Прапорець --loop повторює цикли; --interval-minutes задає інтервал між ними. Для першого ручного обслуговування достатньо одного проходу. Перевірте deleted, delete errors та причини пропусків у його підсумку.

Прибрати том із цього комп’ютера чи видалити для всіх?

Це принципово різні дії:

Команда Локальний стан цього клієнта Спільні дані
destroy myvolume --local Видаляє каталог локальних метаданих разом із кешем усередині нього Зберігає S3 і спільні метадані
destroy myvolume Видаляє той самий локальний стан Видаляє дані тому у S3 та його спільні метадані PostgreSQL

Локальне видалення: destroy --local

Цей варіант потрібен, коли ви свідомо прибираєте локальний стан тому з конкретного комп’ютера, наприклад через застарілу конфігурацію. У поточній реалізації він не потребує доступу до PostgreSQL чи S3.

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

studiofs destroy myvolume --local

Перевірте показаний шлях і межі очищення. Команда спочатку просить відповісти y, а потім повторити назву тому. Порожня відповідь на перший запит або неправильна назва скасовують видалення.

Після підтвердження команда отримує виключний доступ до локальної бази. Якщо змонтований том або інший процес утримує цю базу відкритою, команда не зможе її видалити. Відмонтуйте том і закрийте процес, який використовує базу; не видаляйте її файли вручну, щоб обійти блокування.

Повне видалення: destroy

Це незворотне видалення тому для всіх користувачів: його даних у S3 та спільних метаданих. Команда не створює резервну копію й не має команди скасування. Перед запуском зупиніть роботу й відмонтуйте том на всіх комп’ютерах. Перевірте назву тому, сховище та резервні копії. Виконуйте цю команду лише тоді, коли том справді більше не потрібен.

studiofs destroy myvolume

Команда перевіряє відповідність локального й віддаленого тому, показує межі видалення та запитує два підтвердження, як і локальний варіант. Якщо віддалену ідентичність перевірити не вдалося або UUID не збігаються, вона не продовжує повне видалення й може запропонувати локальне очищення. Це окреме рішення з ризиками, описаними вище.

Після підтвердження команда отримує виключний доступ до локальної бази й утримує його під час віддаленого очищення. Якщо базу використовує інший процес на цьому комп’ютері, віддалене видалення не починається. Це блокування не зупиняє клієнти на інших комп’ютерах. Їх потрібно відмонтувати заздалегідь.

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

Що залишиться на локальному диску?

Обидва режими destroy прибирають весь каталог метаданих цього тому, включно зі стандартним кешем усередині нього. Нестандартний cache_dir автоматично не визначається і не видаляється. Команда нагадує про це та, якщо змогла прочитати локальні метадані, показує UUID тому.

Не видаляйте довільну папку кешу за схожою назвою. Спочатку звірте власні налаштування, шлях і UUID, переконайтеся, що каталог належить саме цьому тому й не містить потрібних локальних змін. До цього моменту залиште його на місці. Якщо мета — лише звільнити місце на SSD, поверніться до глави про кеш, а не видаляйте том.


Зміст · English · ← Попередня · Наступна →