Журналируемые файловые системы

Понятие «журналируемые файловые системы» окружено множеством мифов и легенд, упоминается очень часто, при этом лишь немногие до конца осознают что это такое, что от них ждать, хорошего и не очень...

Что и зачем?

При обычной работе файловой системы все изменения обычно сразу производятся с диском (вернее с кэшем диска в ОС, но это в данном контексте не важно). Но многие операции требует одновременного изменения сразу нескольких структур файловой системы (метаданных), простой пример: при создании hardlink'а нужно одновременно увеличить количество ссылок на inode и изменить содержимое каталога, в который делается ссылка. Нельзя сделать лишь одну из этих операций — содержимое файловой системы будет некорректным.

При обычной работе файловой системы подобная комплексная операция всегда выполняется целиком, если код реализации файловой системы не содержит критических ошибок. Однако при нештатной перезагрузке или аппаратном сбое эта ситуация вполне реальна. Так как после перезагрузки мы не знаем какие операции производились, что было не закончено, а знаем только о том, что диск не был корректно размонтирован (при этом сбрасывается так называемый dirty flag), то нам необходимо проанализировать файловую систему на всём диске, и, таким образом, выявить все ошибки в файловой системе и их исправить. Естественно далеко не всегда это возможно выполнить автоматически (неестественный интеллект, увы, способностям к ясновидению пока обучить никому не удалось), посему та же fsck.ext2 после нештатной перезагрузки может потребовать и ручного вмешательства.

Те кто запускал fsck на разделе в 500Гб–1Тб прекрасно понимают, что удовольствия в этом мало, администраторы же многотерабайтовых массивов, за лишнюю минуту простоя коих им могут «случайно» голову оторвать при слове “fsck” хватаются за валерьянку или просят не ругаться такими словами в их присутствии. Для решения этой проблемы давным-давно была придумана гениальная идея (если кто знает когда и кем — скажите мне, пожалуйста) — сначала записать некое описание планируемой операции на диск, а уж потом её выполнять. Тогда можно будет не тестировать весь диск на корректность, а всего лишь ограничиться просмотром содержимого журнала, и, если операция не была завершена, то откатить её. Для этого не нужно запускать fsck — это делает сам драйвер файловой системы.

Подводя итог... Единственное что может и должна делать журналируемая файловая система, это экономить время на fsck. Соответственно гарантируется непротиворечивость метаданных файловой системы, не больше, не меньше. Цена этого удовольствия, образуется небольшая (обычно измеряемая десятками мегабайт) область диска, на которую приходится максимальная нагрузка, то есть максимальное производительность, измеряемая в количестве i/o операций в секунду, падает и естественно расходуется немного дискового пространства, что в эпоху цен на диски никого уже не волнует.

В журнал обычно пишутся операции с метаданными, однако можно то же самое делать и с данными. Разумеется журналирование данных во многих случаях несколько уменьшает производительность (но далеко не всех, на сайте IBM есть результаты тестов, по которым использование журналирования данных для файловых систем, на которых находятся базы данных, может дать даже прирост производительности). Это средство тоже не гарантирует сохранность данных, однако из моего личного опыта использование ext3 с data=journal является самой надёжной файловой системой. Использование журнала это создание неравномерной нагрузки на диск, на одну маленькую (по сравнению с общим размером файловой системы) область приходится несоразмеримой объём операций.

Есть два очень интересных решения:

Во-первых можно вынести журнал на отдельный диск (большинство файловых систем это позволяют), в результате мы фактически удваиваем производительность добавлением всего одного диска. Это особенно красиво смотрится, когда производительность огромного RAID-массива увеличивается таким простым и дешёвым способом.

Во-вторых можно использовать специальные карты энергонезависимой памяти (например UMEM), которые ещё и заметно быстрее обычных дисков (но имеют небольшой размер памяти).

Есть ещё совсем экстравагантное решение, сделать журнал на блочном устройстве расположенном в памяти. Разумеется после перезагрузки такую файловую систему надо будет пересоздавать заново, но для временных данных это может дать интересное и заметное увеличение производительности. Особенно при журналировании данных, а не только метаданных. Журнал может давать и прирост скорости, есть ещё несколько оригинальных трюков, которые может использовать журналирующая файловая система для ещё большего увеличения производительности:

- Отложенное создание файла, в момент создания файла не создавать сразу запись в каталоге, а некоторое время держать её только в журнале, возможно файл временный и будет сразу удалён;

- Отложеное размещение файла, не выделять физически место даже под первый блок файла до тех пор, пока не понадобится записать хотя бы один блок, вполне возможно, что пользователь сначала изменит размер файла, а уж потом начнёт записывать данные, как результат уменьшается фрагментация;

Это самые простые, есть ещё множество маленьких ухищрений, которые позволяют журналируемой файловой системе работать быстрее обычной, оставаясь более надёжной.

Но журнал не панацея и данные не спасает, однако у многих создаётся ложное чувство безопасности от использования журналируемых файловых систем:

— Как же, можно ведь резетом машину перезагружать, она даже и не матюгнётся при загрузке!

Да, не матюгнётся и будет абсолютно корректной, с точки зрения какого-нибудь fsck файловой системой, только вот от данных при этом всё равно могут остаться одни ошмётки.

Скажем reiserfs в подобных ситуациях вполне может оставлять в модифицируемых файлах мусор (произвольные данные которые были в выделенном под файл блоке). Что, по сути, означает вполне вероятную случайную утечку информации. XFS поступает более корректно — она такие блоки прописывает нулями. Что часто шокирует пользователей. Особенно фанатов reiserfs, которая не станет прописывать нулями. В результате reiserfs скорее сохранит модификации, а XFS всеми силами избежит мусора в файлах и утечки данных — просто чуть разные стратегии. Результат один — данные могут быть утеряны, и вы даже об этом не узнаете. Пока не столкнётесь с файлом, который уже год никто не трогал (в архиве лежал), и который вдруг оказался забитым мусором или нулями.

ext3/ext4 с включенным журналированием данных такими особенностями не страдает. Однако заметно проигрывает в производительности. По-хорошему всех этих проблем можно (и нужно) избежать просто покупкой источника бесперебойного питания (UPS / Uninterruptible Power Supply), а журналирование лучше использовать как дополнительный уровень надёжности и средство увеличения производительности.

Журналируемая файловая система всего лишь немного облегчает администрирование, однако не является волшебным средством от потери данных при нештатных перезагрузках. Поэтому если вы не пользуетесь UPS (источник бесперебойного питания) и не делаете резервные копии - Backup, то ваши данные рано или поздно накроются медным тазом...