Fsck или нет 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 с поддержкой работы с плохими блоками жесткого диска.

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

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

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