Анатомия журналируемых файловых систем Linux. Отложенная запись и контрольные точки журналирования
Основная цель, которая преследуется при создании журналируемых файло-вых систем, состоит в том, чтобы обеспечить как можно большую вероят-ность быстрого восстановления системы после сбоев (например, после по-тери питания). Дело в том, что если происходит сбой, то часть информации о расположении файлов теряется, поскольку система не успевает записать все изменения из буфера на диск. После сбоя утилита, например, fsck должна прове-рить все диски, которые не были корректно демонтированы, с целью вос-становления потерянной информации. При современных объемах жестких дисков, на проверку двух-трех таких дис-ков может уйти слишком много времени. Кроме того, нет гарантии, что все данные удастся восстановить.
В журналируемых файловых системах для решения этой проблемы приме-няют транзакции, которые хорошо известны всем программистам баз дан-ных. Идея транзакции достаточно проста — существует набор связанных операций, называемых транзакцией, и эта группа операций является ато-марной (неделимой). Таким образом, транзакция является успешной (завершенной) в том случае, если все операции, составляющие транзакцию, завершились успешно. Но это еще не все. Система ведет журнал, в котором отражаются все действия с данными и все изменения данных протоколиру-ются. В случае сбоя на основании журнала можно вернуть систему в без-ошибочное состояние.
Основное отличие транзакций из области баз данных от транзакций, при-меняемых в журналируемых файловых системах, состоит в том, что в базах данных в журнале сохраняются изменяемые данные и вся управляющая ин-формация, а в файловых системах — только метаданные: индексные деск-рипторы изменяемых файлов, битовые карты распределения свободных бло-ков и свободных индексных дескрипторов.
Пример1. Файловая система Ext3
По большому счету, файловая система Ext3 не была новой файловой системой. Это похоже на ситуацию с файловой системой FAT 16/FAT 32 — они совместимы, но проблема решена экстенсивным путем. Было необхо-димо срочно создать журналируемую файловую систему. Если начинать с нуля — долго и накладно, тогда сделали для Ext2 несколько десятков специ-альных функций и назвали все это Ext3 — получился непонятный гибрид.
Файловая система ext3 имеет несколько опций, которые позволяют выбрать, сколько информации нужно журналировать. В системе Red Hat Linux, чтобы прочитать и восстановить данные из обычного журнала, требуется около секунды. Время, необходимое для восстановления журнальной файловой системы после неправильного выключения компьютера, зависит не от размера файловой системы, а от того, сколько данных содержится в журнале.
В файловой системе ext3, как и в остальных журналируемых файловых системах, нет необходимости осуществлять традиционную проверку с помощью программы fsck. Тем не менее, fsck еще используется в других журнальных файловых системах.
При выборе опций журналирования можно отключить проверку целостности данных при пересылке, чтобы увеличить скорость выполнения операций в файловой системе; из-за конструкции файловой системы нужно выбирать что-то одно: либо обеспечение целостности, либо скорость. Можно повысить скорость обработки данных, установив для них режим Writeback. Но при этом данные могут повредиться, если во время операции над ними произойдет аварийное выключение компьютера. Или же можно пожертвовать скоростью выполнения операций, но обеспечить целостность данных.
В файловой системе ext3 доступны 3 режима работы с данными:
- Writeback - позволяет старым данным оставаться в системе, при этом операции над этими данными, как правило, выполняются быстрее. Этот режим не предусматривает планирование каких-либо операций над данными.
- Ordered - хранит данные в согласованном состоянии, однако скорость выполнения операций над данными падает (этот режим установлен по умолчанию).
- Journal - требует дополнительного пространства на диске для выполнения журналирования. При этом может упасть производительность, поскольку данные записываются дважды.
Для большинства пользователей наилучшим режимом будет Ordered , который выбран по умолчанию. Режим выбирается с помощью соответствующей опции монтирования в файле /etc/fstab.
Пример2. Файловая система ReiserFS
Кроме проблемы быстрого восстановления после сбоев, в файловой системе Ext2 имеется еще несколько нерешенных проблем. Из самых основных — нерациональное использование дискового пространства, ограничение на размер файла, неоптимальный поиск.
Поскольку в файловой системе используется простой связный список, то время поиска информации линейно зависит от длины списка. Таким обра-зом, чем длиннее список (к примеру, файлов в каталоге), тем дольше идет поиск необходимого элемента.
В системе ReiserFS применяются так называемые "сбалансированные дере-вья" или "B+Trees", время поиска в которых пропорционально не количест-ву объектов, а логарифму этого числа. В сбалансированном дереве все ветви имеют одинаковую длину. ReiserFS использует сбалансированные деревья для хранения всех объектов файловой системы: файлов в каталогах, данных о свободных блоках и т.д. Это позволяет существенно повысить производи-тельность обращения к дискам.
Кроме того, система ReiserFS является журналируемой, т.е. в ней решена проблема быстрого восстановления после сбоев. Решена в ReiserFS и про-блема с ограничением на размер файла.
NTFS - отказоустойчивая система, которая вполне может привести себя в корректное состояние при практически любых реальных сбоях. Любая современная файловая система основана на таком понятии, как транзакция - действие, совершаемое целиком и корректно или не совершаемое вообще. У NTFS просто не бывает промежуточных (ошибочных или некорректных) состояний - квант изменения данных не может быть поделен на до и после сбоя, принося разрушения и путаницу - он либо совершен, либо отменен.
Пример 1: осуществляется запись данных на диск. Вдруг выясняется, что в то место, куда мы только что решили записать очередную порцию данных, писать не удалось - физическое повреждение поверхности. Поведение NTFS в этом случае довольно логично: транзакция записи откатывается целиком - система осознает, что запись не произведена. Место помечается как сбойное, а данные записываются в другое место - начинается новая транзакция.
Пример 2: более сложный случай - идет запись данных на диск. Вдруг, отключается питание и система перезагружается. На какой фазе остановилась запись, где есть данные, а где нет? На помощь приходит другой механизм системы - журнал транзакций. Дело в том, что система, осознав свое желание писать на диск, пометила в метафайле $LogFile это свое состояние. При перезагрузке это файл изучается на предмет наличия незавершенных транзакций, которые были прерваны аварией и результат которых непредсказуем - все эти транзакции отменяются: место, в которое осуществлялась запись, помечается снова как свободное, индексы и элементы MFT приводятся в с состояние, в котором они были до сбоя, и система в целом остается стабильна. Ну а если ошибка произошла при записи в журнал? Тоже ничего страшного: транзакция либо еще и не начиналась (идет только попытка записать намерения её произвести), либо уже закончилась - то есть идет попытка записать, что транзакция на самом деле уже выполнена. В последнем случае при следующей загрузке система сама вполне разберется, что на самом деле всё и так записано корректно, и не обратит внимания на "незаконченную" транзакцию.
И все-таки помните, что журналирование - не абсолютная панацея, а лишь средство существенно сократить число ошибок и сбоев системы.
Опыт показывает, что NTFS восстанавливается в полностью корректное состояние даже при сбоях в очень загруженные дисковой активностью моменты. Вы можете даже оптимизировать диск и в самый разгар этого процесса нажать reset - вероятность потерь данных даже в этом случае будет очень низка. Важно понимать, однако, что система восстановления NTFS гарантирует корректность файловой системы , а не ваших данных. Если вы производили запись на диск и получили аварию - ваши данные могут и не записаться, но всегда есть их копия.
Сжатие
Файлы NTFS имеют один довольно полезный атрибут - "сжатый". Дело в том, что NTFS имеет встроенную поддержку сжатия дисков - то, для чего раньше приходилось использовать Stacker или DoubleSpace. Любой файл или каталог в индивидуальном порядке может хранится на диске в сжатом виде - этот процесс совершенно прозрачен для приложений. Сжатие файлов имеет очень высокую скорость и только одно большое отрицательное свойство - огромная виртуальная фрагментация сжатых файлов, которая, правда, никому особо не мешает. Сжатие осуществляется блоками по 16 кластеров и использует так называемые "виртуальные кластеры" - опять же предельно гибкое решение, позволяющее добиться интересных эффектов - например, половина файла может быть сжата, а половина - нет. Это достигается благодаря тому, что хранение информации о компрессированности определенных фрагментов очень похоже на обычную фрагментацию файлов: например, типичная запись физической раскладки для реального, несжатого, файла:
кластеры файла с 1 по 43-й хранятся в кластерах диска начиная с 400-го
кластеры файла с 44 по 52-й хранятся в кластерах диска начиная с 8530-го...
Физическая раскладка типичного сжатого файла:
кластеры файла с 1 по 9-й хранятся в кластерах диска начиная с 400-го
кластеры файла с 10 по 16-й нигде не хранятся
кластеры файла с 17 по 18-й хранятся в кластерах диска начиная с 409-го
кластеры файла с 19 по 36-й нигде не хранятся
Видно, что сжатый файл имеет "виртуальные" кластеры, реальной информации в которых нет. Как только система видит такие виртуальные кластеры, она тут же понимает, что данные предыдущего блока, кратного 16-ти, должны быть разжаты, а получившиеся данные как раз заполнят виртуальные кластеры - вот, по сути, и весь алгоритм.
Журналируемые файловые системы - это класс файловых систем, характерная черта которых - ведение журнала, хранящего список изменений, в той или иной степени помогающего сохранить целостность файловой системы.
Запуск проверки системы (например, fsck) на больших файловых системах может занять много времени, что очень плохо для сегодняшних высокоскоростных систем. Причиной отсутствия целостности в файловой системе может быть некорректное размонтирование, например, если в момент прекращения работы на диск велась запись. Приложения могли обновлять данные, содержащиеся в файлах, и система могла обновлять метаданные файловой системы, которые являются «данными о данных файловой системы», иными словами, информация о том, какие блоки связаны с какими файлами, какие файлы размещены в каких директориях и тому подобное. Ошибки (отсутствие целостности) в файлах данных - это плохо, но куда хуже ошибки в метаданных файловой системы, что может привести к потерям файлов и другим серьезным проблемам.
Для минимизации проблем, связанных с целостностью, и минимизации времени перезапуска системы, журналируемая файловая система хранит список изменений, которые она будет проводить с файловой системой перед фактической записью изменений. Эти записи хранятся в отдельной части файловой системы, называемой «журналом», или «логом». Как только изменения файловой системы безопасно внесены в журнал, журналируемая файловая система применяет эти изменения к файлам или метаданным, а затем удаляет эти записи из журнала. Записи журнала организованы в наборы связанных изменений файловой системы, что очень похоже на то, как изменения добавляемые в базу данных организованы в транзакции.
Наличие журнала повышает вероятность сохранения целостности файловой системы, потому что записи в лог-файл ведутся до проведения фактических изменений, и эти записи хранятся до тех пор, пока они не будут целиком и безопасно применены. При перезагрузке компьютера программа монтирования может гарантировать целостность журналируемой файловой системы простой проверкой лог-файла на наличие ожидаемых, но не произведенных изменений и последующей записью их в файловую систему. Т.о. при наличии журнала в большинстве случаев системе не нужно проводить проверку целостности файловой системы, а это означает, что компьютер будет доступен для работы практически сразу после перезагрузки. Соответственно, шансы потери данных в связи с проблемами в файловой системе значительно снижаются.
Существует несколько журналируемых файловых систем, доступных в Linux. Наиболее известные из них:
XFS, журналируемая файловая система разработанная Silicon Graphics, но сейчас выпущенная открытым кодом (open source);
ReiserFS, журналируемая файловая система разработанная специально для Linux;
JFS, журналируемая файловая система первоначально разработанная IBM, но сейчас выпущенная как открытый код;
xt3 - журналируемое расширение файловой системы ext2, используемой на большинстве версий GNU/Linux. Уникальная особенность системы ext3 - возможность перехода на неё с ext2 без переформатирования диска. Разработана доктором Стефаном Твиди (Stephan Tweedie).
В семействе ОС Microsoft Windows к журналируемым относится файловая система NTFS. В Mac OS X - HFS+.
Настоящее и будущее журналирования
Существует множество определений журналируемых файловых систем, однако давайте приведем формулировку, понятную каждому: журналируемая файловая система - это систем для тех, кому надоела программа проверки fsck во время загрузки. Также это система для тех, кому близка идея устойчивых к сбоям систем. Если некорректно отключить питание в обычной системе, где отсутствует журналирование, то ОС обнаруживает этот факт и запускает утилиту проверки целостности диска fsck при следующей загрузке. Эта утилита сканирует файловую систему и пытается устранить проблемы, не нанося вреда данным. Процесс проверки может занять довольно много времени. Иногда файловая система повреждается настолько сильно, что ОС загружается только в однопользовательском режиме и предлагает пользователю провести дальнейшее восстановление.
Скажи fsck
Еще хуже то, что процесс fsck может запускаться операционной системой автоматические при монтировании файловой системы, чтобы удостовериться, что метаданные верны (даже если не было повреждений). Таким образом, устранение лишних проверок целостности файловой системы - это заметная область для улучшения.
Итак, теперь вы знаете, кто нуждается в журналируемых файловых системах, однако почему таким системам не нужны проверки fsck ? Вкратце - потому, что в них ведется специальный журнал. Журнал - это файл, представляющий собой кольцевой буфер, в который заносятся все действия, связанные с изменением файловой системы. Периодически эти изменения применяются к файловой системе. В случае сбоя, журнал может быть использован в качестве отправной точки для восстановления несохраненных данных и для предотвращения повреждения метаданных.
Резюмируя, скажем, что журналируемая файловая система - это устойчивая к сбоям файловая система, команды изменения для которой заносятся в журнал, прежде чем быть исполненными, что помогает избежать повреждения метаданных. (См. рисунок 1). Как обычно в Linux, существует множество вариантов таких систем. Давайте сделаем небольшой обзор истории файловых систем, а затем рассмотрим имеющиеся на сегодня файловые системы и их различия.
Что такое метаданные?
Метаданными называются служебные структуры данных, необходимые для хранения основных данных. Такие операции, как создание и удаление файла и каталога, увеличение файла, усечение файла и.т.д., затрагивают метаданные.
Рисунок 1. Типичная журналируемая файловая система.
История журналируемых файловых систем Linux
IBM® первой разработала журналируемую файловую систему, которая называлась JFS (Journaled File System). Первая версия JFS была представлена в 1990 году, а современная версия поддерживается в Linux как JFS2, разработанная позже. В 1994 году компания Silicon Graphics представила высокопроизводительную файловую систему XFS для ОС IRIX. В 2001 году XFS была портирована для Linux. В 1998 году для систем Amiga была разработана файловая система Smart File System (SFS), которая впоследствии выпускалась под лицензией GNU Lesser General Public License (LGPL) и получила поддержку в Linux 2005 году. Наибольшее распространение получила файловая система ext3fs (от англ. third extended file system ), которая является расширением системы ext2 с добавлением журналирования. Поддержка ext3fs появилась в Linux в 2001 году. И наконец, получившая широкое распространение журналируемая файловая система ReiserFS открыла много новых путей и возможностей для развития. Однако развитие этой системы замедлилось в связи с юридическими проблемами ее автора.
Разновидности журналирования
Все журналируемые файловые системы ведут журнал для буферизации изменений файловой системы (который также нужен для аварийного восстановления), однако существуют различные стратегии того, что и когда заносить в журнал. Существует три наиболее распространенные стратегии - режим обратной записи, режим упорядочивания и режим данных.
В режиме обратной записи журналированию подвергаются только метаданные, а блоки с данными записываются непосредственно на диск. Это способствует нерушимости структуры файловой системы и защищает от повреждений, однако повреждение самих данных все же возможно (например, если крах системы наступает после записи метаданных в журнал, но до записи блока с данными). Решить указанную проблему позволяет режим упорядочивания . В этом режиме в журнал заносятся также только метаданные, но сами данные записываются до журналирования метаданных. Этим гарантируется согласованность данных файловой системы после восстановления. И наконец, возможно журналирование в режиме данных , при котором в журнал заносятся как метаданные, так и сами данные. Этот режим обладает наивысшим уровнем устойчивости к повреждению и потере данных, но имеет недостаток в виде низкой производительности, поскольку все данные записываются дважды (сначала в журнал, потом на диск).
Правила применения изменений, зафиксированных в журнале, также могут быть разными в разных подходах. Например, когда следует применять изменения? Когда журнал полон? Или когда истекает некий таймаут?
Журналируемые файловые системы сегодня
На сегодняшний день активно используется несколько журналируемых файловых систем, каждая из которых имеет свои преимущества и недостатки. Ниже представлена четверка самых популярных журналируемых файловых систем.
JFS2
JFS2 (также известная как улучшенная журналируемая файловая система ) является первой журналируемой файловой системой и долгое время применялась в ОС IBM AIX®, прежде чем была перенесена в Linux. JFS2 - это 64-разрядная файловая система, которая, имея корни оригинальной JFS, была заметно усовершенствована в плане масштабируемости и поддержки многопроцессорных архитектур.
JFS2 поддерживает упорядоченное журналирование, обладает высокой производительностью и временем восстановления менее секунды. Для повышения быстродействия в ней применяется метод размещения файлов на основе экстентов. Размещение на основе экстентов означает размещение файла в виде нескольких непрерывных участков, а не множества одинаковых блоков. Благодаря непрерывности, эти участки обеспечивают более быстрое чтение и запись. Дополнительное преимущество экстентов - меньшие расходы на работу с метаданными. При размещении файла блоками записи подлежат метаданные каждого блока. Если используются экстенты, то изменяются метаданные для экстентов, которые обычно состоят из нескольких блоков.
JFS2 также использует B+-деревья как для эффективного поиска по каталогам, так и для управления дескрипторами экстентов. JFS2 не имеет собственной политики переноса изменений на диск, - вместо этого она основывается на таймауте демона kupdate.
XFS
XFS - еще одна из ранних журналируемых файловых систем, первоначально разработанная Silicon Graphics в 1995 году для ОС IRIX. В 2001 году XFS была реализована в Linux, уже будучи на тот момент продуманной и надежной файловой системой.
XFS использует полноценную 64-разрядную адресацию и обеспечивает очень высокую производительность за счет применения B+-деревьев для размещения каталогов и файлов. XFS хранит данные в виде экстентов, поддерживая переменный размер экстентов (от 512 байт до 64 килобайт). Наряду с экстентами в XFS применяется отложенное размещение, при котором размещение блоков задерживается до тех пор, пока не наступит время их записи на диск. Такая особенность повышает вероятность заполнения подряд нескольких дисковых блоков, поскольку на момент записи будет известно их количество.
Другие интересные свойства XFS - это гарантированная скорость ввода/вывода, когда пользователям файловой системы выделяется резерв пропускной способности для операций ввода/вывода, и прямой ввод/вывод, при котором данные копируются напрямую между диском и буфером приложения (вместо того чтобы проходить несколько буферов). Журналирование в XFS ведется методом обратной записи.
Третья расширенная файловая система (ext3fs)
Третья расширенная файловая система (ext3fs) - наиболее популярная журналируемая файловая система, возникшая как эволюция известной файловой системы ext2. На самом деле она совместима с ext2, так как оперирует идентичными структурами, но с добавлением журнала. Более того, возможно смонтировать раздел ext3 как ext2 либо преобразовать ext2 в ext3, используя утилиту tune2fs .
В ext3fs поддерживаются все три стратегии журналирования (обратная запись, упорядочивание и режим данных), однако по умолчанию используется режим упорядочивания. Политику переноса данных журнала на диск можно настраивать, но изначально она такова, что перенос происходит либо по заполнении 1/4 журнала, либо по истечении одного из таймеров переноса.
Один из главных недостатков ext3fs происходит из того, что она изначально не задумывалась как именно журналируемая файловая система. Поскольку она основана на ext2fs, в ней отсутствуют многие прогрессивные нововведения, имеющиеся в других файловых системах (например, экстенты). Также она обычно показывает слабую производительность по сравнению с ReiserFs, JFS и XFS, однако меньше нагружает процессор и потребляет памяти, чем многие другие файловые системы.
ReiserFS
Что такое уплотнение хвостов?
Очень часто бывает, что файл имеет размер, меньший размера логического блока. Вместо того чтобы выделять на каждый такой файл по целому блоку, оставляя часть блока незанятой (эту часть называют хвостом ), в один блок стараются уместить несколько файлов. Такой способ дает выигрыш в 5% свободного места по сравнению с другими файловыми системами, но негативно сказывается на производительности.
Файловая система ReiserFS с самого начала создавалась как журналируемая. В 2001 году она была добавлена в главную ветку ядра 2.4 и стала первой журналируемой файловой системой, появившейся в Linux. Основной метод журналирования - упорядочивание. Поддерживается увеличение размера файловой системы "на лету". ReiserFS также поддерживает уплотнение хвостов для динамического уменьшения фрагментации, что позволяет ей обгонять по скорости ext3fs при работе с маленькими файлами.
В ReiserFS (также ее называют ReiserFS v3) применяется много современных подходов, например B+-деревья. Формат файловой системы базируется на единственном B+-дереве, что делает операции поиска особенно быстрыми и масштабируемыми. Политика переноса данных из журнала на диск зависит от размера журнала и основана на количестве блоков, требующих переноса.
Репутация ReiserFS была несколько раз подпорчена: последний раз - проблемами автора системы с законом (подробную информацию см. в разделе ).
Будущее журналируемых файловых систем
Ознакомившись с журналируемыми файловыми системами настоящего и прошлого, давайте посмотрим, что их ждет в будущем (и что не ждет).
Reiser4
После успешного внедрения ReiserFS в ядро и применения во многих дистрибутивах Linux компания Namesys (которая стоит за ReiserFS) начала работу над новой журналируемой файловой системой, Reiser4, которая была создана полностью с нуля и включает в себя множество передовых возможностей.
Улучшенное журналирование в Reiser4 достигается за счет использования блуждающих записей и отложенного размещения блоков до момента переноса данных журнала (как это было сделано в XFS). В архитектуре Reiser4 предусматривалась гибкая поддержка плагинов (например, чтобы добавить функции сжатия или шифрования), но эта идея была отвергнута Linux-сообществом, которое считало, что место этим расширенным функциям - в подсистеме виртуальной файловой системы (VFS).
После вынесения обвинения владельцу Namesys и одновременно автору ReiserFS вся коммерческая деятельность вокруг Reiser4 была приостановлена.
Четвертая расширенная файловая система
Четвертая расширенная файловая система (ext4fs) - это дальнейшее развитие ext3fs. Ext4fs была задумана как замена ext3fs, имеющая с ней прямую и обратную совместимость, но включающая в себя множество улучшений (некоторые из которых нарушают эту совместимость). На практике можно монтировать раздел ext4 как ext3 и наоборот.
Во-первых, ext4fs - это 64-разрядная файловая система с поддержкой томов огромного размера (до 1 эксабайта). Она также может использовать экстенты, но в этом случае теряется совместимость с ext3fs. Аналогично XFS и Reiser4, в ext4fs размещение блоков на диске задерживается и происходит по необходимости (что уменьшает фрагментацию). Журнал также хранит контрольные суммы содержимого для большей надежности. Вместо B+- или B*-деревьев применяется специальная разновидность B-дерева, т.н. H-дерево , что позволяет поддиректориям иметь намного больший размер (в ext3 он ограничен 32Кб).
Хотя отложенное размещение уменьшает фрагментацию, со временем файловая система большого размера все равно фрагментируется. Для решения этой проблемы была разработана утилита e4defrag, которую можно использовать для дефрагментации отдельных файлов или целой файловой системы.
Еще одно интересное отличие ext4fs от ext3fs заключается в точности временной метки файлов. В ext3 размерность временной метки - одна секунда. Ext4fs смотрит в будущее: при непрекращающемся росте скоростей процессора и интерфейсов требуется более точное измерение. Поэтому в качестве размерности времени была взята одна наносекунда.
Хотя ext4fs включена в ядро Linux в версии 2.6.19, она уже может считаться стабильной. Эта система, разработка которой продолжается, является отправной точкой для создания журналируемой файловой системой будущего в Linux.
Двигаясь дальше
Журналируемые файловые системы обеспечивают надежность и защиту от повреждения данных при крахе системы или потере питания. Помимо этого, время восстановления в таких системах намного меньше, чем в традиционных файловых системах (например таких в которых применяется fsck). Разработка новых методов журналирования основывается как на прошлом опыте, идущем от JFS и XFS, так и на поиске новых алгоритмов и структур. Не совсем ясно, как будут развиваться журналируемые файловые системы в будущем, однако их полезность очевидна, и они уже стали новым стандартом файловых систем.