Что можно сказать об 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). В таком случае запись в файл станет причиной того, чтобы все остальные отложенные операции по изменению метаданных файловой системы будут сброшены на диск
К счастью, подавляющее большинство операций обычного сервера асинхронны по своей природе.
<
/p>
Если система стала перезагружаться или повисла при наличии "окна" (т.е. после того, как информация об изменении метаданных была записана не только в журнал, но и на диск, а соответствующие этой операции блоки данных еще "висят" в памяти), то как старые, так и новые данные окажутся утерянными. Происходит это по следующей причине. Запись метаданных на диск стирает ссылку на первоначальный блок с данными и указывает на блок, в который новые данные пока еще не записаны. Когда сервер запускается после аварийного отказа, код 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, но и даст дополнительные удобства системным администраторам в выборе наиболее оптимального размера блока для решаемых задач.
