Проверять или не проверять fsck после 180 дней

По умолчанию после 180 дней или некоторого количества монтирований большинство файловых систем Linux принуждают к выполнению проверки файловой системы (fsck). Конечно, это можно отключить с помощью, например, tune2fs -c 0 -i 0 на ext2 или ext3.

На малых файловых системах эта проверка является лишь неудобством. Однако, учитывая большие файловые системы, эта проверка может занять часы. Когда ваши пользователи зависят от этой файловой системы для своей продуктивности, скажем, она обслуживает их домашние директории через NFS, отключили бы вы запланированную проверку файловой системы?

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

180-дневное время по умолчанию для fsck является обходным решением для недоработки, что 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 с поддержкой работы с плохими секторами на HDD.

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

ext2/3/4, fat, ntfs и т.д. (офлайн-тест) могут черный список плохих блоков, но не XFS.

Так что для некорпоративных установок, XFS, вероятно, не подходит. Я использую XFS с программным RAID1 Linux для резервных разделов, где содержимое состоит из множества маленьких файлов, которые не сильно изменяются со временем.