Для fsck чи не fsck через 180 днів

За замовчуванням через 180 днів або деяку кількість монтування більшість файлових систем Linux змушує перевірити файлову систему (fsck). Звичайно, це можна вимкнути, використовуючи, наприклад, tune2fs -c 0 -i 0 на ext2 або ext3.

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

Я задаю це запитання, оскільки наразі це 2:15 ранку, і я чекаю завершити дуже довгий fsck (ext3)!

Час fsck за 180 днів за замовчуванням є вирішенням проблеми з дизайном, що ext3 не підтримує перевірку відповідності в Інтернеті. Справжнє рішення - знайти файлову систему, яка це підтримує. Я не знаю, чи є якась зріла файлова система. Це справжня трагедія. Можливо, btrfs врятує нас одного дня.

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

Велика частина проблеми полягає в тому, що ext3 має нерозумно повільний fsck. Хоча xfs має набагато швидший fsck, він використовує занадто багато пам'яті для дистрибутивів, щоб заохочувати xfs за замовчуванням у великих файлових системах. І все-таки для більшості систем це не проблема. Перехід на xfs принаймні дозволить отримати досить швидкий fsck. Це може полегшити графік роботи fsck як частини звичайного обслуговування.

Якщо ви запускаєте RedHat і плануєте використовувати xfs, ви повинні остерігатися того, наскільки сильно вони перешкоджають використанню xfs та тому, що на ядра, яке ви працюєте, мало людей, які використовують xfs.

Я розумію, що проект ext4 має на меті принаймні дещо покращити продуктивність fsck.

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

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

Залежить .. Наприклад, у нас був один сервер для запуску технічного обслуговування, на якому працював стек QMail. QMail створює та вбиває безліч файлів із часом, і це був дуже зайнятий поштовий сервер. На fsck пішло десь 36 годин. Це не так, як ми врятували певну ефективність від угоди, але, нарешті, я гадаю, ви могли б стверджувати, що файлова система була здоровішою. Чи справді варто було хаосу, який настав? Ні. В. Усі.

XFS цікава. Це завжди послідовний ФС. Він не потребує fsck. Це не спричинить простої через fsck.

Але це має ще одну проблему. Вам потрібен контролер RAID з підтримкою роботи з поганими блоками жорсткого диска.

XFS не має функції чорного списку поганих блоків, коли ОС починає знати про погані блоки, а список поганих блоків апаратних засобів жорсткого диска заповнений.

ext2 / 3/4, жир, ntfs тощо (тест офлайн) можуть в чорний список погані блоки, але не XFS.

Отже, для нефірмових установок XFS, ймовірно, не підходить добре. Я використовую XFS з програмним забезпеченням linux raid1 для резервних розділів, де вміст багато невеликих файлів, які з часом не змінюються.