После решения использовать LVM2 в качестве диспетчера томов на наших серверах возникла потребность в файловой системе с изменяемым размером в режиме онлайн. Прочитав несколько статей, я решил использовать JFS в пользу XFS.
Сегодня у меня отключилось электричество на нашем офисном сервере, и я обнаружил, что один файл на томе JFS был полностью поврежден. Хотя это могло случиться, система обманула меня, заставив поверить, что все в порядке, не указав на какие-либо проблемы с файловой системой во время загрузки после сбоя питания. После воспроизведения журнала все файловые системы были чистыми.
Это оставляет у меня дурной вкус. Мне не нужна файловая система, которая не могла бы нормально восстановиться после отключения электроэнергии, но мне действительно не нужна файловая система, которая не сообщает мне, что может быть проблема.
Поэтому я решил попробовать и спросить, какую файловую систему вы предпочитаете? Какой из них вы предпочитаете и почему? Я ищу следующие особенности:
Я также хотел бы знать, использовали ли вы JFS и имели ли вы плохой опыт работы с ним - также, конечно, есть ли истории успеха с использованием JFS. И, наконец: вы бы предпочли XFS вместо JFS или наоборот (как упоминалось для повседневного использования, а не для конкретных рабочих нагрузок)
XFS.
JFS в основном мертв / не поддерживается.
Большинство / все разработчики XFS сейчас работают в Redhat, а поддержка ядра для XFS доступна прямо из коробки в RHEL 5.4.
Воспроизведение журнала просто означает, что метаданные возвращаются в чистое состояние. Он не дает никаких гарантий относительно самих данных. Это верно для любой журналируемой файловой системы, по крайней мере, для любой, которая также не выполняет других трюков, таких как COW (копирование при записи). Таким образом, существует вероятность такого повреждения данных каждый раз, когда сервер некорректно завершает работу, независимо от того, какую файловую систему вы выбрали. Ваша файловая система выполнила свою работу и смогла вернуть файловую систему в чистое состояние, минимизируя потерю / повреждение данных.
Таким образом, урок, извлеченный из этого, должен заключаться в том, что ваши серверы всегда должны быть подключены к ИБП, который может дать серверу команду корректно выключиться при низком уровне заряда батареи. И всегда имейте хорошие резервные копии.
Если вы действительно беспокоитесь о целостности данных, вам придется перейти на более надежную файловую систему, такую как ZFS на OpenSolaris или BSD. Это единственное готовое к эксплуатации бесплатное решение, о котором я знаю на данный момент. BTRFS для Linux станет достойным решением через несколько лет, как только он станет зрелым и протестированным. Но в настоящее время я бы не рекомендовал использовать его в производственной среде. Даже эти более надежные файловые системы не заменяют резервные копии.
Интересно, пробовал ли кто-нибудь из вышеупомянутых «неудачников» использовать fsck, прежде чем отказался от JFS? JFS @ Linux не имеет встроенного в ядро кода восстановления журнала и, следовательно, требует использования соответствующего инструмента в пользовательском пространстве для этого.
Тот же опыт, что и у Брэда.
JFS была действительно хорошей производительностью и функциональностью, но я просто потерял 3 раздела данных после принудительного завершения работы.
Таким образом, я выбросил JFS в мусорное ведро и в будущем буду использовать XFS (и ждать ZFS в Linux, а также BTRFS).
Стандартная файловая система Linux ext3 поддерживает онлайн-рост, а также отвечает вашим другим требованиям. Если у вас нет других особых потребностей, это действительно правильный ответ. Несмотря на то, что XFS имеет долгую историю и хорошую репутацию, его использование по-прежнему ставит вас в особый случай, и это нормально, но влечет за собой повышенную сложность - и зачем «платить» за то, что вам не нужно?
Я использовал JFS в крупномасштабной профессиональной среде и сильно обгорел. Массивные проблемы с повреждением, которые не проявлялись сразу, иногда все файлы оказывались утерянными + найденными только после чистой перезагрузки.
Перешел на XFS и больше не оглядывался. Используется уже 5 лет на сотнях мутитерабайтных систем.