Вход:  Пароль:  
FreeSource: ЖурналируемыеФайловыеСистемы ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |

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

Введение


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

Зачем?


При обычной работе файловой системы все изменения обычно сразу производятся с диском (вернее с кэшем диска в ОС, но это в данном контексте не важно).


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


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


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


Те, кто запускал fsck на разделе в 100–200G (что ныне далеко не редкость) прекрасно понимают, что удовольствия в этом мало. Администраторы же многотерабайтовых массивов, за лишнюю минуту простоя коих им могут «случайно» голову оторвать при слове “fsck” хватаются за валерьянку или просят не ругаться такими словами в их присутствии.


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


Подводя итог — единственное что может и должна делать журналируемая файловая система, это экономить время на fsck. Соответственно гарантируется непротиворечивость метаданных файловой системы, не больше, не меньше.


Цена этого удовольствия: у нас образуется небольшая (обычно измеряемая десятками мегабайт) область диска, на которую приходится максимальная нагрузка, то есть максимальное производительность, измеряемая в количестве i/o операций в секунду, падает. Ну и, естественн, расходуется немного дискового пространства, что в эпоху цен на диски < 1$/гигабайт никого не волнует.

Журналирование данных

Как вы обратили внимание, в журнал обычно пишутся операции с метаданными. Однако можно то же самое делать и с данными.


Насколько мне известно под Linux журналирование данных умеет выполнять лишь ext3 с параметром data=journal.


Разумеется журналирование данных во многих случаях несколько уменьшает производительность (но далеко не всех, на сайте IBM есть результаты тестов, по которым использование журналирования данных для файловых систем, на которых находятся базы данных, может дать даже прирост производительности).


Это средство тоже не гарантирует сохранность данных, однако из моего личного опыта использование ext3 с data=journal является самой надёжной файловой системой.

Производительность

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


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


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


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

Хитрости

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




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

Недостатки

Как я уже говорил журнал не панацея, и данные ничуть не спасает. Однако у многих создаётся от использования журналируемых файловых систем ложное чувство безопасности — как же, можно ведь резетом машину перезагружать, и даже не матюгнётся при загрузке!


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


Скажем reiserfs в подобных ситуациях вполне может оставлять в модифицируемых файлах мусор (произвольные данные которые были в выделеном под файл блоке). Что, по сути, означает вполне вероятную случайную утечку информации.


XFS поступает более корректно — она такие блоки прописывает нулями. Что часто шокирует пользователей. Особенно фанатов reiserfs, которая не станет прописывать нулями.


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


ext3 с включеным журналированием данных такими особенностями не страдает. Однако заметно проигрывает в производительности.


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

Итог


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




(C) Денис Смирнов <mithraen@freesource.info> 5 Nov 2004
Размещение этого документа на других Internet-ресурсах, а также в печатных изданиях не допускается.


Отзывы — здесь вы можете высказать своё мнение по поводу содержимого сайта

Страницы, ссылающиеся на данную: HCL/ХранениеДанных
Статьи
ТЗ/AltLinux/КакимДолженБытьУстановщикСистемы


 
Файлов нет. [Показать файлы/форму]
Много комментариев (3). [Показать комментарии/форму]