Журналируемые файловые системы — это класс файловых систем, характерная черта которых — ведение журнала, хранящего список изменений, в той или иной степени помогающего сохранить целостность файловой системы.
Запуск проверки системы (например, fsck) на больших файловых системах может занять много времени, что очень плохо для сегодняшних высокоскоростных систем. Причиной отсутствия целостности в файловой системе может быть некорректное размонтирование, например, если в момент прекращения работы на диск велась запись. Приложения могли обновлять данные, содержащиеся в файлах, и система могла обновлять метаданные файловой системы, которые являются «данными о данных файловой системы», иными словами, информация о том, какие блоки связаны с какими файлами, какие файлы размещены в каких директориях и тому подобное. Ошибки (отсутствие целостности) в файлах данных — это плохо, но куда хуже ошибки в метаданных файловой системы, что может привести к потерям файлов и другим серьезным проблемам.
Для минимизации проблем, связанных с целостностью, и минимизации времени перезапуска системы, журналируемая файловая система хранит список изменений, которые она будет проводить с файловой системой перед фактической записью изменений. Эти записи хранятся в отдельной части файловой системы, называемой «журналом», или «логом». Как только изменения файловой системы безопасно внесены в журнал, журналируемая файловая система применяет эти изменения к файлам или метаданным, а затем удаляет эти записи из журнала. Записи журнала организованы в наборы связанных изменений файловой системы, что очень похоже на то, как изменения добавляемые в базу данных организованы в транзакции.
Наличие журнала повышает вероятность сохранения целостности файловой системы, потому что записи в лог-файл ведутся до проведения фактических изменений, и эти записи хранятся до тех пор, пока они не будут целиком и безопасно применены. При перезагрузке компьютера программа монтирования может гарантировать целостность журналируемой файловой системы простой проверкой лог-файла на наличие ожидаемых, но не произведенных изменений и последующей записью их в файловую систему. Т.о. при наличии журнала в большинстве случаев системе не нужно проводить проверку целостности файловой системы, а это означает, что компьютер будет доступен для работы практически сразу после перезагрузки. Соответственно, шансы потери данных в связи с проблемами в файловой системе значительно снижаются.
Существует несколько журналируемых файловых систем, доступных в Linux. Наиболее известные из них:
XFS, журналируемая файловая система разработанная Silicon Graphics, но сейчас выпущенная открытым кодом (open source);
ReiserFS, журналируемая файловая система разработанная специально для Linux;
JFS, журналируемая файловая система первоначально разработанная IBM, но сейчас выпущенная как открытый код;
ext3 — журналируемое расширение файловой системы ext2, используемой на большинстве версий GNU/Linux. Уникальная особенность системы ext3 — возможность перехода на неё с ext2 без переформатирования диска. Разработана доктором Стефаном Твиди (Stephan Tweedie).
DualFS - это новая высокопроизводительная журналируемая файловая система, характеризующаяся разделением хранения данных и метаданных на различных устройствах (как правило, на двух разделах одного диска), и управляет ими разными методами.
В семействе ОС Microsoft Windows к журналируемым относится файловая система NTFS. В Mac OS X — HFS+.
Основная цель, которая преследуется при создании журналируемых файловых систем, состоит в том, чтобы обеспечить быстрое восстановление системы после сбоев (например, после потери питания). Дело в том, что если произойдет такой сбой, то часть информации о расположении файлов теряется, поскольку не все изменения сразу записываются на диск. После этого программа fsck вынуждена просматривать весь диск блок за блоком (пользуясь битовыми матрицами занятых блоков и индексных дескрипторов) с целью восстановления потерянных связей. При увеличении размера дисков вдвое, вдвое увеличивается и время, которое требуется для просмотра всего диска. А при тех объемах, которых достигают современные диски, особенно на серверах, время, необходимое для того, чтобы просмотреть весь диск, стало недопустимо велико: ведь сервер в это время не отзывается! Кроме того, нет гарантии, что все связи удастся восстановить.
В журналируемых файловых системах для решения этой проблемы применяют технику транзакций, развитую в теории баз данных. Суть этой техники в том, что действие не считается завершенным, пока все изменения не сохранены на диске. А чтобы сбои, происходящие в течение времени, необходимого для завершения всех операций, не приводили к необратимым последствиям, все действия и все изменяемые данные протоколируются. Если сбой все-таки произойдет, то по этому протоколу можно вернуть систему в безошибочное состояние.
Главное отличие в технике транзакций, применяемой в базах данных, от аналогичной техники, применяемой в журналируемых файловых системах, состоит в том, что в базах данных сохраняются в протоколе как сами изменяемые данные, так и вся управляющая информация, в то время как понятие транзакции в файловых системах подразумевает сохранение только мета-данных: индексных дескрипторов изменяемого файла, битовых карт распределения свободных блоков и свободных индексных дескрипторов. Дело в том, что если сохранять все изменяемые данные, то теряется смысл кэширования записи на диск и уменьшается скорость дисковых операций. Мета-данные же, во-первых, меньше по размеру, а, во-вторых, сохраняются в специально выделенной области диска, что позволяет избежать чрезмерных затрат времени на ведение протокола.
Файловые системы ext3fs и JFS являются журналируемыми. Надо отметить, что ext3fs не является совершенно новой разработкой, а является просто надстройкой над ext2fs, обеспечивающей ведение журнала и организацию транзакций. Файловые системы XFS и JFS являются открытыми версиями коммерческих файловых систем.

         XFS — высокопроизводительная журналируемая файловая система, созданная компанией Silicon Graphics для их операционной системы IRIX. 1 мая 2001 года Silicon Graphics выпустила XFS под GNU General Public License.
Поддержка XFS была включена в ядро Linux версий 2.4 (начиная с 2.4.25, когда Марсело Тосатти (Marcelo Tosatti) посчитал её достаточно стабильной) и 2.6, и, таким образом, она стала довольно универсальной для Linux-систем. Инсталляторы дистрибутивов SuSE, Gentoo, Mandriva, Slackware, Ubuntu, Fedora и Debian предлагают XFS как вариант файловой системы для установки. FreeBSD стала поддерживать XFS в режиме чтения в декабре 2005 года.
Особенности XFS:
• 64-битная файловая система
• Журналирование только метаданных
• Изменение размера «на лету» (только увеличение)
• Размещение в нескольких разных линейных областях — т. н. «allocation groups» (увеличивает производительность путём выравнивания активности запросов к разным дискам на RAID-массивах типа «stripe»)
• Дефрагментация «на лету»
• API ввода/вывода реального времени (для приложений жёсткого или мягкого реального времени, например, для работы с потоковым видео)
• Запись на диск производится только при нехватке памяти. Это позволяет уменьшить фрагментацию, а также снизить активность запросов к диску.
• Интерфейс (DMAPI) для поддержки иерархического управления хранением (HSM (англ.) )
• Инструменты резервного копирования и воостановления (xfsdump and xfsrestore)
• Реальный размер файла на файловой системе, в отличии от кратного размеру блока.
• Очень большое количество inode.
  Недостатки XFS:
• Невозможно уменьшить размер существующей файловой системы.
• Старые версии XFS страдали от опасности беспорядочной записи, которые могли привести к возникновению таких проблем как — файлы приложений во время краха/ошибки/аварии ФС или приложения набирали хвост из мусора к следующему монтированию ФС.
• Версии загрузчика GRUB до 0.91 не поддерживают XFS.
• Восстановление удалённых файлов в XFS практически невозможно.
• Возможность потери данных при сбое питание, так как большое кол-во буферов хранится в памяти.
• Относительно высокая нагрузка на центральный процессор

 

Первоначально JFS была разработана корпорацией IBM для операционной системы AIX. Следующая версия JFS была разработана IBM для ОС Warp Server for e-Business. Позже она была перенесена в IBM AIX и Linux. Целью разработчиков было обеспечить высокую производительность, надежность и масштабируемость для многопроцессорных компьютеров.
Эта файловая система разрабатывается компанией IBM и распространяется под лицензией GNU GPL. Описание JFS можно найти в Интернете на сайте http://jfs.sourceforge.net. JFS используется не только в Linux, но и в других операционных системах, например, в AIX и OS/2.
JFS — журналируемая файловая система. Основной её конёк — использование совместно с LVM (Logical Volume Manager). LVM позволяет объединять несколько физических разделов жёстких дисков в один логический, который затем можно разбивать на разделы как обыкновенный жёсткий диск. При этом некоторые типы LVM позволяют на лету подключать новое дисковое пространство. И если на увеличивающихся разделах использовать файловую систему ext3, в один прекрасный момент вы получите сообщение о невозможности создания нового файла. Дело в том, что при форматировании раздела в ext3 в нём заранее, в зависимости от размера, резервируется конечное количество inodes. То есть заранее известно максимальное количество файлов. Если размер файловой системы не будет увеличиваться, то этого количества inodes вполне хватает для нормальной работы. В JFS есть возможность динамического увеличения файловой системы и количества inodes. Благодаря этому свойству, при увеличении размера файловой системы не возникает ограничение на количество создаваемых файлов.
JFS имеет интересное внутренне устройство. Например, при создании файловой системы ext3 в разделе выделятся суперблок, в котором описаны параметры и корневая директория файловой системы. При создании файла выделятся дисковое пространство для inode и данных файла. В JFS раздел разбивается на так называемые агрегаты. В каждом агрегате создается свой суперблок и свой журнал. Фактически мы получаем набор файловых систем. Причём эти файловые системы при желании можно использовать отдельно! При увеличении размера файловой системы просто создаётся новый агрегат, в котором распределяется свое количество inodes.
 В системе ReiserFS применяются так называемые "сбалансированные деревья" или "B+Trees", время поиска в которых пропорционально не количеству объектов (файлов в каталоге или числа блоков на диске), а логарифму этого числа. В сбалансированном дереве все ветви (пути от корня до "листа") имеют одинаковую (или примерно одинаковую) длину. ReiserFS использует сбалансированные деревья для хранения всех объектов файловой системы: файлов в каталогах, данных о свободных блоках и т. д. Это позволяет существенно повысить производительность обращения к дискам.
Кроме того, ReiserFS является журналируемой, т. е. в ней решена и проблема быстрого восстановления после сбоев.
Для файловой системы JFS существуют следующие ограничения:
Максимальный размер файла ограничивается разрядностью операционной системы.
Максимальный размер файловой системы — 512 Тбайт.

ext3 или 3-я расширенная файловая система — журналируемая файловая система, используемая в операционных системах на ядре Linux, является файловой системой по умолчанию во многих дистрибутивах. Основана на ФС ext2.
Основное отличие от ext2fs состоит в том, что ext3 журналируема, то есть в ней предусмотрена запись некоторых данных, позволяющих восстановить файловую систему при сбоях в работе компьютера.
Стандартом предусмотрено три режима журналирования:
1. writeback: в журнал записываются только метаданные файловой системы, то есть информация о её изменении. Не может гарантировать целостности данных, но уже заметно сокращает время проверки по сравнению с ext2;
2. ordered: то же, что и writeback, но запись данных в файл производится гарантированно до записи информации о изменении этого файла. Немного снижает производительность, также не может гарантировать целостности данных (хотя и увеличивает вероятность их сохранности при дописывании в конец существующего файла);
3. journal: полное журналирование как метаданных ФС, так и пользовательских данных. Самый медленный, но и самый безопасный режим; может гарантировать целостность данных при хранении журнала на отдельном разделе (а лучше — на отдельном жёстком диске).
Указывается режим журналирования в строке параметров для программы mount, например:
mount /dev/hda6 /mnt/disc -o data=<режим>
либо в файле /etc/fstab.
Особенности ext3:
Файловая система ext3 может поддерживать файлы размером до 1 ТБ. С Linux-ядром 2.4 объем файловой системы ограничен максимальным размер блочного устройства, что составляет 2 терабайта. В Linux 2.6 (для 32-разрядных процессоров) максимальный размер блочных устройств составляет 16 ТБ, однако ext3 поддерживает только до 4 ТБ.

NTFS (от англ. New Technology File System — «файловая система новой технологии») — стандартная файловая система для семейства операционных систем Microsoft Windows NT.
NTFS заменила использовавшуюся в MS-DOS и Microsoft Windows файловую систему FAT. NTFS поддерживает систему метаданных и использует специализированные структуры данных для хранения информации о файлах для улучшения производительности, надёжности и эффективности использования дискового пространства. NTFS имеет встроенные возможности разграничивать доступ к данным для различных пользователей и групп пользователей, а также назначать квоты (ограничения на максимальный объём дискового пространства, занимаемый теми или иными пользователями). NTFS использует систему журналирования для повышения надёжности файловой системы.
Различают несколько версий NTFS: v1.2 используется в Windows NT 3.51 и Windows NT 4.0, v3.0 поставляется с Windows 2000, v3.1 — с Windows XP и Windows Server 2003. Иногда последние версии обозначают как v4.0, v5.0 и v5.1 в соответствии с версиями Windows NT, с которыми они поставляются.

Механизм журналирования NTFS.
NTFS - отказоустойчивая система, которая вполне может привести себя в корректное состояние при практически любых реальных сбоях. Любая современная файловая система основана на таком понятии, как транзакция - действие, совершаемое целиком и корректно или не совершаемое вообще. У NTFS просто не бывает промежуточных (ошибочных или некорректных) состояний - квант изменения данных не может быть поделен на до и после сбоя, принося разрушения и путаницу - он либо совершен, либо отменен.
Пример 1: осуществляется запись данных на диск. Вдруг выясняется, что в то место, куда мы только что решили записать очередную порцию данных, писать не удалось - физическое повреждение поверхности. Поведение NTFS в этом случае довольно логично: транзакция записи откатывается целиком - система осознает, что запись не произведена. Место помечается как сбойное, а данные записываются в другое место - начинается новая транзакция.
Пример 2: более сложный случай - идет запись данных на диск. Вдруг, бах - отключается питание и система перезагружается. На какой фазе остановилась запись, где есть данные, а где чушь? На помощь приходит другой механизм системы - журнал транзакций. Дело в том, что система, осознав свое желание писать на диск, пометила в метафайле $LogFile это свое состояние. При перезагрузке это файл изучается на предмет наличия незавершенных транзакций, которые были прерваны аварией и результат которых непредсказуем - все эти транзакции отменяются: место, в которое осуществлялась запись, помечается снова как свободное, индексы и элементы MFT приводятся в с состояние, в котором они были до сбоя, и система в целом остается стабильна. Ну а если ошибка произошла при записи в журнал? Тоже ничего страшного: транзакция либо еще и не начиналась (идет только попытка записать намерения её произвести), либо уже закончилась - то есть идет попытка записать, что транзакция на самом деле уже выполнена. В последнем случае при следующей загрузке система сама вполне разберется, что на самом деле всё и так записано корректно, и не обратит внимания на "незаконченную" транзакцию.
И все-таки журналирование - не абсолютная панацея, а лишь средство существенно сократить число ошибок и сбоев системы. Вряд ли рядовой пользователь NTFS хоть когда-нибудь заметит ошибку системы или вынужден будет запускать chkdsk - опыт показывает, что NTFS восстанавливается в полностью корректное состояние даже при сбоях в очень загруженные дисковой активностью моменты. Вы можете даже оптимизировать диск и в самый разгар этого процесса нажать reset - вероятность потерь данных даже в этом случае будет очень низка. Важно понимать, однако, что система восстановления NTFS гарантирует корректность файловой системы, а не ваших данных. Если вы производили запись на диск и получили аварию - ваши данные могут и не записаться.

HFS+ была представлена 19 января 1998 г. вместе с Mac OS 8.1, но впервые её представили в качестве тестовой файловой системы для так и не вышедшей OS Copland (1994—1996 гг.) Начиная с 11 ноября 2002 г., с выпуском обновления 10.2.2, Apple Inc. сделала возможным журналирование для повышения надёжности хранения информации. Оно было легко доступно с серверной версией Mac OS X, но только через интерфейс командной строки с настольных клиентов. Начиная с Mac OS X v10.3, журналирование стало включённым по умолчанию, а том с журналом получил название HFSJ.
С Mac OS 10.3 так же был представлен вариант HFS+ — HFSX.

HFS Plus или HFS+ — файловая система, разработанная Apple Inc. для замены ранее использующейся HFS, основной файловой системы на компьютерах Macintosh. Так же с этой файловой системой может работать плеер iPod. HFS+ можно рассматривать, как усовершенствованную версию HFS для расширения возможностей Mac OS. Во время разработки, эта система называлась Sequoia.
HFS+ является улучшенной версией HFS, с поддержкой файлов большого размера (32-битная адресация вместо старой 16-битной) и использует кодировку Unicode для имён файлов и папок. HFS+ поддерживает имена длинной до 255 символов формата UTF-16 и многопоточные файлы, подобно NTFS, однако, почти все программы используют только data fork (поток данных) и resource fork (поток с ресурсами). HFS+ так же использует 32-битную allocation mapping table (таблица привязки файла к месту на диске) вместо 16-битной в HFS. Старая адресация являлась серьёзным ограничением HFS, не позволяя работать с томами объёмом более 65 536 блоков (как FAT16 и FAT-32). При обьёме диска в 1 ГБ размер кластера (блока) составлял 16 КБ — даже файл из 1 байта занимал все 16 КБ.
Подобно предшественнице, HFS+ использует древовидную структуру B*-tree для хранения большей части метаданных.
Особенности HFS+
Том в HFS+ поделён на сектора (в HFS назывались логическими блоками), обычно равные 512 мб. Один или более секторов составляют кластер, общее число кластеров зависит от объёма диска. 32-битная адрессация позволяет получить доступ к 4 294 967 296 (232) кластерам против старых 65 536 (216).
Обычно, том в HFS объединяется с HFS Wrapper, хотя это становится менее распространенным. Wrapper был разработан для нескольких целей: во-первых, он позволяет Макинтошам без поддержки HFS+ в ПЗУ загружатся с таких томов. Во-вторых, это позволяет упростить переход на HFS+ путём создания простейшего загрузочного тома HFS, на котором есть досупный только для чтения файл Where_have_all_my_files_gone? (англ. Куда пропали все мои файлы?). Файл содержит информацию для пользователей Mac OS без поддержки HFS+, о том, что этот логический диск требует операционную систему с подержкой HFS+. Заголовок HFS тома содержит сигнатуру и смещение до вложенного HFS+ тома. Сектора, используемые HFS+ помечены в HFS как дефектные блоки (bad blocks).

         Проект, начатый в 2000 году Хуаном Пирнасом Кановасом (из малоизвестного Университета в городе Murcia Испании)  как экспериментальный и почти при единоличном  участии, с небольшими вкладами Тони Кортеса, и Хосе М. Гарсияя. Затем он был приостановлен на некоторое время. Однако, в 2006 году работы по проекту возобновились, и после нескольких месяцев обновлений и многообещающих тестов он был возобновлен, как проект с открытым исходным кодом на www.SourceForge.net  (http://sourceforge.net/projects/dualfs) с  намерением воплотить в жизнь это старое, но все же перспективное начинание.
DualFS - это новая высокопроизводительная журналируемая файловая система, характеризующаяся разделением хранения данных и метаданных на различных устройствах (как правило, на двух разделах одного диска), и управляет ими разными методами. В отличие от других журналируемых файловых систем, DualFS имеет только одну копию каждого блока метаданных. Эта копия находится на устройстве для метаданных, это журнал, который встроен в файловую систему DualFS для чтения и записи  блоков метаданных. С его помощью, а также с помощью упреждающего чтения изменяемых блоков, избегается дорогое по производительности, дополнительное чтение и копирование блоков метаданных, DualFS может достигать хорошей производительности по сравнению с другими журналируемыми файловыми системами. По итогам предварительного тестирования прототипа DualFS, которое было проведено с помощью microbenchmarks и macrobenchmarks, было выяснено, что DualFS значительно сокращает общее время ввода / вывода файловой системы в большинстве случаев до 97%.