Руководство по продвинутым файловым системам
Совершенствование файловых систем

Дэниел Роббинс (Daniel Robbins), перевод Владимира Холманова, под редакцией Алексея Федорчука

Первоисточник : http://www-106.ibm.com/developerworks/library/l-fs11.html
Июнь 2002

Зачем оно нужно?

Просматривая свои прошлые статьи из серии "Руководство по "продвинутым" файловым системам" для себя я отметил, что со времени первой публикации прошел почти год! Не волнуйтесь, эта серия скоро пополнится новым содержанием, поскольку я собираюсь приступить к описанию Linux технологий JFS и EVMS (enterprise volume management) от IBM. Поскольку площадкой для публикаций является сайт IBM, я решил, что описание технологий от IBM уместно сделать после всех остальных файловых систем для Linux.

Но, прежде чем приступить к JFS и EVMS, я отвлекусь на вопросы апдейта текущего состояния файловых систем в мире Linux. Мы опробовали большое число ядер серии 2.4. Одни из них были оценены как "приличные", о других такого не говорили. Не только ядро, но и XFS, ext3 и ReiserFS находились в состоянии активного развития. При этом, большое число пользователей Gentoo Linux использовали самые разные комбинации файловых систем XFS, ext3 и ReiserFS и с разными результами. Когда кто либо из пользователей Gentoo Linux имеет проблему с журналируемой файловой системой, обычно я об этом узнаю. Итак, какие файловые системы стали наиболее популярными? Какие из их числа наиболее надежны? В этой статье я воспользуюсь результатами обратной связи с пользователями и информацией от development команд ReiserFS, ext3 и XFS.

Что можно сказать об XFS?

За прошедшие несколько месяцев XFS стала самой популярной файловой системой для Linux. Такой вывод следует из обратной связи с пользователями Gentoo Linux. Тенденция выбора в пользу XFS сложилась из-за ее хороших рабочих характеристик. Однако, в релизах 1.0.x XFS страдала одной серьезной проблемой. Давайте повторимся. Файловые системы, журналирующие только метаданные, которыми являются XFS и ReiserFS, допускают нарушение целостности самих данных. Такое происходит когда метаданные о файле модифицируются перед непредвиденным обстоятельством (аварийным отказом). Но, если у ReiserFS попавший под разрушение файл будет содержать старые (а при некоторых обстоятельствах "мусорные") блоки данных, то в случае с XFS блоки заполняются двоичными нулями. Было замечено, что XFS 1.0.x имеет плохую тенденцию обнулять слишком много модифицируемых файлов при зависании сервера или нарушении электропитания. Те, кто использовал XFS на надежном сервере с источником бесперебойного питания, чуствовали себя прекрасно. У тех, кто устанавливал XFS на системе с низкой стабильностью из за программных или аппаратных проблем, возникал большой риск накопления потерянных данных.

К счастью, разработчики SGI XFS существенно снизили такую тенденцию в релизе 1.1 XFS. Проблема проявлялась более заметно в XFS 1.0 по причине того, что слишком многие виды модификаций метаданных требовали журналирования строго в порядке их следования. Такие упорядоченные апдейты метаданных, еще называемые "синхронными" модификациями, оказывают эффект форсированной записи всех предшествующих (отложенных) модификаций. Здесь и возникала проблема. Вынужденно ранняя запись метаданных на диск (а за каждой такой операцией стоят свои блоки с данными) приводил к накапливанию блоков, которые ожидали свою запись на диск еще около 30 секунд после обновления метаданных о них. То есть, создавалось относительно большое окно для возможной утери данных.

Техническое примечание. В релизе 1.1 XFS метаданные файловой системы модифицируются синхронно только в двух случаях: если файловая система должна ассигновать новое пространство и имеется отложенная транзакция, способная освободить точно такое же пространство если XFS обрабатывает транзакцию для файлов, открытых с опцией O_SYNC (synchronous). В таком случае запись в файл станет причиной того, чтобы все остальные отложенные операции по изменению метаданных файловой системы будут сброшены на диск К счастью, подавляющее большинство операций обычного сервера асинхронны по своей природе.

Если система стала перезагружаться или повисла при наличии "окна" (т.е. после того, как информация об изменении метаданных была записана не только в журнал, но и на диск, а соответствующие этой операции блоки данных еще "висят" в памяти), то как старые, так и новые данные окажутся утерянными. Происходит это по следующей причине. Запись метаданных на диск стирает ссылку на первоначальный блок с данными и указывает на блок, в который новые данные пока еще не записаны. Когда сервер запускается после аварийного отказа, код XFS просматривает журнал, распознает ситуацию и заполняет незаписанные блоки двоичными нулями в целях предосторожности. К сожалению, данные затираются навсегда.

Эта проблема особенно неприятна в ситуациях, когда файлы регулярно переписываются "поверх" новыми данными. В таком случае раннее сбрасывание метаданных на диск создает большое окно, что может привести к потере содержимого всего файла при зависании системы в неудачное время. Именно такой сценарий сработал некоторое время назад на сервере gentoo.org. Так как наше mailman mailing list software каждые несколько минут переписывало поверх собственный конфигурационный файл, оно и стало главным кандидатом в жертвы описанному сценарию.

Вывод из ситуации следующий: парни из SGI существенно улучшили ситуацию в релизе 1.1 XFS. Если вы имеете 1.0 XFS, то должны в самое ближайшее время спланировать переход на XFS 1.1. В XFS 1.1 сделано множество и других исправлений. Как только в SGI уменьшили зависимость XFS от синхронных модификаций это оказало положительный эффект на "неудобную" в XFS 1.0.x операцию удаления файлов. Yay!

Что в ближайшей перспективе? Мы можем ожидать выхода нового релиза XFS, который лучше адаптирован под платформу Itanium (Intel). Сейчас XFS для Linux требует, чтобы у XFS размер блока файловой системы точно совпадал с размером страницы оперативной памяти платформы. Становится невозможным просто взять и переставить диск из системы x86 на Itanium, так как в Itanium размер страницы 64 K, а на x86 аппаратно поддержана страница 4 K. Размер файлового блока в 64 K близок к оптимальному значению для многих задач и используется на Itanium системах. Когда проблема жесткой привязки размеров блока и страницы будет решена, это не только облегчит перенос дисков с файловой системой XFS между платформами x86 и ia64, но и даст дополнительные удобства системным администраторам в выборе наиболее оптимального размера блока для решаемых задач.

ReiserFS

Файловая система ReiserFS, возможно, наиболее честолюбивый проект развития журналируемых файловых систем. Это не портирование существующей файловой системы на Linux ядро (подобно XFS, JFS) и не развитие уже существующей файловой системы, как ext3. Нет, ReiserFS стартовала с пустого места и гордится некоторыми впечатляющими показателями качества, скажем, обработкой маленьких файлов. Но, а как показала себя ReiserFS в терминах стабильности и наличия ошибок после ее переноса на ядра серии 2.4?

С самого начала ReiserFS имела необычно много проблем с разрушениями и стабильностью. Имеется несколько ядер, которые стали полным кошмаром для пользователей ReiserFS, включая 2.4.3, 2.4.9 и даже относительно недавнее 2.4.16. В то время как некоторые из этих проблем были вызваны ошибками непосредственно в коде файловой системы ReiserFS, имелись нежелательные побочные эффекты, вызываемые изменениями в других частях ядра. Одна неприятная вещь в процессе развития Linux ядра заключается в том, что независимо от того, насколько тщательно проверен ваш собственный код, возможны такие изменения у другого разработчика, которые приведут к ломке вашего кода. Слишком часто нежелательные побочные эффекты выявляются уже после того, как вышел релиз для неподозревающей Linux публики. Следует сказать, что немало пользователей ReiserFS были приведены в уныние такой ситуацией.

Но имеются и хорошие новости. За последние несколько месяцев ReiserFS стала смотреться намного лучше. Одной причиной стала стабилизация ядра после релиза 2.4.17. Кроме того, парни из Namesys (разработчики ReiserFS) устранили несколько неявных ошибок в своем коде. Как результат, сложилось мнение, что ядро 2.4.18 имеет очень твердую ReiserFS реализацию. А ведь 2.4.18 это не весенний цыпленок [spring chicken] - во время написания этой статьи на протяжении почти 3 месяцев так и небыло найдено существенных проблем. Фактически, из-за прекращения потока сообщений об ошибках, Namesys переорентировали Release Manager на новые задания по улучшению производительности ReiserFS.

Очень похоже, что ReiserFS и ядро 2.4 "разрулили" свои противоречия. Лично для меня это хорошая новость. Имею желание вновь начать использовать ReiserFS в качестве корневой файловой системы, как только придет время переустановки моей станции разработчика. Я уверен, что имеются много других экс-ReiserFS-пользователей, которые вернутся обратно, так как пришло спокойствие на "ядерную землю". И в самом деле, трудна жизнь без ReiserFS когда уже знаешь, как благоприятно влияет на некоторые приложения увеличение производительности на маленьких файлах.

А что мы можем ожидать от ReiserFS в ближайшем будущем? Согласно Хансу Рейзеру (Hans Reiser) и его команды, на очереди некоторые очень хорошие усовершенствования. Следует выделить журналирование данных от Криса Мэйсона (Chris Mason) (аналог режима "data=journal" в ext3) и новый код ассигнования блоков, который лучше масштабируется и немного повышает производительность на большых файлах (до 15 % на операциях чтения с IDE дисков). Кроме этих ближайших и существенных изменений мы, вероятно увидим, что ReiserFS поддерживает эквивалент режима "data=ordered" из ext3. То есть, ReiserFS предлагает эквивалент режима data integrity, реализованного в файловой системе ext3. Я очень счастлив видить, что команда разработчиков ReiserFS придает такой высокий приоритет проблеме целостности данных (а не только метаданных).

Ext3

А что относительно ext3? В общем, ext3 характеризуется как устойчивая и не страдающая серьезными проблемами файловая система. У некоторых она может вызывать "раздражение", поскольку не имеет никаких серьезных усовершенствований по сравнению с ext2, за исключением хорошей реализации журналирования. Подобное "раздражение" в мире файловых систем скорее плюс. Это значит, что файловая система выполняет свои функции без суеты и инцидентов. Кроме того, несмотря на меньшую "продвинутость" ext3 (по отношению к ResierFS, XFS и JFS), она достаточно быстра и имеет хорошие настройки для типичных файловых операций большинства серверов и рабочих станций. Ясно, что разработчики ext3 имели целью создание высококачественной журналируемой системы, на которую Linux пользователи могут смело переходить.

На ядре 2.4.19_pre5 синхронное монтирование ext3 и "chattr +S" файлов стало происходить приблизительно в десять раз быстрее. В самом ближайшем будущем ожидается добавление опции для синхронных модификаций в целых деревьях каталогов, что непременно найдет использование в почтовых программах. Следует ожидать исправлений мелких ошибок и повышения производительности. И ничего мажорного. Код ext3 уже совершенен и находится в эксплуатационном режиме.