Як довго fsck може зайняти об'єм 30 ТБ?

У середині листопада VPS, який я орендую у приймаючої компанії, перестав реагувати. Коли я зв’язався із службою підтримки, вони пояснили, що відключення електроенергії в центрі обробки даних викликало вимушене перезавантаження та fsck. Врешті-решт я запитав, чому це займає так довго, і мені відповіли, що розмір гучності становить 30 ТБ. Востаннє я отримував оновлення в лютому, і вони не відповіли на мій останній запит.

Я розумію, що fsck може бути дуже повільним для деяких файлових систем, але чи можливо, щоб fsck зайняв 6 місяців на об'ємі 30 ТБ, чи слід вважати, що ця хостингова компанія бреше мене, щоб я продовжував сплачувати свій рахунок кожен місяць?

fsckшвидкість головним чином залежить від кількості файлів та способу їх поширення у відповідній директорії. Однак, 6 місяців для A fsckабсолютно абсурдно: він повинен був завершитись за декілька годин, особливо якщо використання xfsцього має швидку xfs_repairкорисність. Тут ви можете знайти деякий fsckпробіг у масштабі - все завершено за одну годину (3600). Отже, не можливо, що ваш fsckвсе ще працює.

У будь-якому випадку, несподівана втрата електроенергії не спричинить повний удар fsck, а лише дуже швидке (кілька секунд) перезапис журналу . Однак якщо деякі ключові файли були пошкоджені, ОС може бути незавантаженою.

Але вони, напевно, просто збрехали вам. Слід негайно припинити платити, попросити пояснення та подати заявку на повне повернення коштів.

Концепція: їх система використовує RAID (без програмного забезпечення RAW / FBWC) (або навіть програмний RAID) з усіма можливими кешами запису (включаючи такі на самих жорстких дисках), встановлених у найагресивніших налаштуваннях, щоб отримати максимальну продуктивність за мінімальні витрати. Постійне відключення електроенергії при такій установці може залишити файлову систему журналу в стані, коли журналу не можна довіряти і не можна використовувати для відновлення. Проблема полягає в тому, що така система агресивно впорядковує і відкладає записування, а це означає, що запис у журналі можна писати з ефектом втраченої дії даних ... або втрачається запис журналу під час дії даних, яка була наслідком.

Відновлення такої системи з найгіршого випадку відключення може означати, що вам потрібно зробити "повільний" fsck / ремонт, який фактично вивчає всі структури файлової системи такими, якими вони є, що дійсно може зайняти день-два за 30 Тб .... і це малоймовірно, що вам доведеться запустити кілька циклів ремонту. Додайте до цього, що персонал може бути не завжди доступний для моніторингу цього, ви можете легко перейти на один fsck, що робиться на тиждень. Вони, напевно, здалися і забули.

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

У гіршому випадку він може прочитати весь диск ( наприклад, щось подібне fsck.ext4 -cc /dev/sda, яке робить неруйнівний тест запису на кожен блок), що може зайняти кілька днів за 30 ТБ. Якщо ви знаєте швидкість приводів, ви можете розрахувати розмір / швидкість . Для жорсткого диска споживача, який копіює кілька ТБ, близько 100 Мб / с може зайняти більше годин, ніж очікували більшість людей.

Якби це ваш сервер, у вас може виникнути проблема, що він завантажується, тоді він зависає, коли fsckзапитує, чи хочете виправити помилку. Але адміністратор Центру обробки даних не залишить fsckвисіти протягом 6 місяців, поки всі VPS в режимі офлайн.

Тож вони вам або брешуть, або виникає величезне непорозуміння. Або вони працювали fsck деякий час тому і не повідомляли вас про нову проблему після її закінчення.