По умолчанию через 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 с программным обеспечением raid1 linux для разделов резервного копирования, где содержимое представляет собой множество небольших файлов с небольшими изменениями с течением времени.