Какая журналируемая файловая система используется в windows

Обновлено: 04.07.2024

Одной из важных составляющих современных операционных систем являются дисковые файловые системы. В общем случае каждая из них разработана с учетом специфики применения. Ярким примером может служить файловая система XFS от Silicon Graphics. Однако, за некоторыми исключениями в виде той же XFS, большинство файловых систем общего назначения стремятся обеспечить не только быстродействие. Немаловажным показателем является устойчивость файловой системы к сбоям. В этом контексте имеется в виду обеспечение согласованности данных в случае непредвиденных сбоев в работе аппаратного обеспечения, например в результате сбоя питания.

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

Одним из первых заимствований из области баз данных в область обеспечения отказоустойчивости стали журналы транзакций. Здесь стоит оговориться. То, что называется транзакциями почти во всех современных файловых системах общего назначения, не стоит считать транзакциями в полной мере. Они не соответствуют общим требованиям к транзакциям. Например, их нельзя отменить. Однако, с другой стороны, транзакции файловых систем работают аналогично транзакциям базы данных. Иначе говоря, если происходят какие-то изменения в файловой системе, то сначала они фиксируются в журнале транзакций в синхронном режиме. Если между фиксацией транзакции в журнале и записью в файловую систему произойдет сбой, состояние файловой системы можно будет восстановить по содержимому журнала.

Основными свойствами транзакции являются:

атомарность (Atomicity): изменения, производимые в рамках транзакции, являются одним целым. Они либо происходят все, либо не происходит ни одно из них, и данные остаются в том состоянии, в котором были до начала транзакции; непротиворечивость (Consistency): данные по окончании транзакции должны подчиняться правилам, заданным для набора данных, к которым эта транзакция применяется. Например, не может появиться два одинаковых значения для поля, содержимое которого должно быть уникально; изоляция (Isolation): транзакции не должны влиять друг на друга в процессе выполнения; долговечность (Durability): независимо от внешних факторов, выполненная транзакция сохраняется, и ничто не может вернуть систему в состояние до начала транзакции.

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

Почти все файловые системы современных операционных систем общего назначения, таких как Windows или Linux, имеют журналирующую файловую систему в качестве основной. Их можно условно разделить на две категории:

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

В первом случае журналирование не обеспечивает отказоустойчивости данных. Его основной задачей является обеспечение непротиворечивости метаданных файловой системы, а также повышение скорости проверки структуры файловой системы при старте операционной системы. К примеру, если вы переносите файл из каталога в каталог и происходит сбой, может случиться так, что файловая система будет иметь записи о новом и старом файлах. Мало того, если при этом должно было пройти копирование содержимого исходного файла в новый файл, но оно не произошло, попытка обратиться к новому файлу может привести к неожиданным последствиям. Кроме того, в NTFS журналирование может использоваться для быстрого отслеживания изменений в файлах для тех или иных целей. Такой метод мониторинга изменений используется для работы распределенной файловой системы DFS, репликации политик каталога Active Directory и работы различных приложений резервного копирования. Кроме того, метаданные можно использовать в качестве истории произошедших изменений, например для того, чтобы выявить различные санкционированные и несанкционированные действия с вашими файлами. Как же все-таки выглядят такого вида журналы в разных операционных системах?

В операционной системе Windows начиная с Windows 2000 используется файловая система NTFS версии 5, которая поддерживает журналирование метаданных. В клиентских версиях операционных систем ведение журнала по умолчанию отключено.

Если журнал активен, то каждый раз, когда на томе происходят изменения, файловая система добавляет запись в журнал изменений NTFS. Журнал представляет собой специальный системный файл метаданных$Extend$UsnJrnl. Данные журнала хранятся в потоке $J. Этот файл является разреженным файлом NTFS, поэтому он никогда не переполняется. Он имеется на каждом разделе диска, на котором активен журнал. Каждая запись идентифицируется значением номера последовательных изменений Update Sequence Number (USN) и добавляется в конец журнала. Записи не хранятся вечно. Система удаляет устаревшие записи журнала в случае, если его размер в два раза превышает заданный максимальный размер. Кроме того, NTFS поддерживает значение LastUSN для каждой записи в таблице MFT. Таким образом, даже в том случае, когда записи об изменении файла или папки были удалены из журнала, по наличию этого значения можно судить о том, что файл или папка были изменены. Однако необходимо помнить, что при отключении журналирования файл журнала удаляется вместе со всеми записями. Cистема при этом сбрасывает значение LastUSN каждой записи в MFT в ноль, т. е. операция удаления журнала — сравнительно продолжительная по времени.

Журнал изменений

Рассмотрим вкратце, как устроен этот журнал Windows. Структура записи журнала представлена в листинге 1. Наиболее важными, с точки зрения администратора, полями являются:

FileName. Это имя файла или каталога, с которым произошли изменения. К сожалению, это только имя. Путь в этом поле не хранится. Кроме того, в дополнение к этому полю в структуре предусмотрены еще вспомогательные поля FileNameLength и FileNameOffset, которые определяют длину имени и смещение поля с именем относительно начала структуры. Microsoft рекомендует работать с именами файлов в этой структуре, не рассчитывая на то, что имя оканчивается нулем, но используя значения смещения и длины строки. Таким образом обеспечивается совместимость с последующими версиями. FileReferenceNumber. Поле, в котором содержится уникальное значение, идентифицирующее файл. Каждый файл или папка в системе имеют такой идентификатор. Идентификатор раздела и идентификатор файла уникально идентифицируют любой файл на компьютере. По открытым файловым описателям можно узнать, указывают ли они на один и тот же файл. Для этого нужно просто получить эти значения из описателя при помощи функции GetFileInformationByHandle и сравнить соответствующие значения. Если они равны, значит, описатели указывают на один и тот же файл. ParentFileReferenceNumber. В этом поле содержится идентификатор контейнера записи, т. е. если запись описывает файл, то в этом поле будет содержаться идентификатор каталога, в котором он лежит. Это же верно и для папки. Для того чтобы получить полный путь до этого файла, необходимо пройти по дереву идентификаторов до самого корня, которым является идентификатор раздела, и получить имена каждого узла в этом пути. Reason. Здесь хранится флаг, описывающий действие, которое происходит с объектом. Все возможные флаги причин указаны в табл. 1. Необходимо обратить внимание на одну особенность. При изменении файла система не проставляет один и тот же флаг дважды. В случае если выполняется несколько операций записи в файл, система создаст только одну запись в файл журнала с флагом USN_REASON_DATA_OVERWRITE после первой операции. Все последующие операции с этим флагом не отобразятся в журнале. Рассмотрим пример, в котором происходит следующая последовательность операций с файлом:

В этом случае записи журнала будут производиться, как показано в табл. 2.

TimeStamp. Штамп времени этой записи в формате UTC. USN. Номер последовательности изменений данной записи журнала. Значение USN является смещением записи относительно начала журнала. Оно постоянно возрастает, а значит, чем новее запись, тем это значение больше.

А как дела в Linux?

Наиболее распространенными файловыми системами в Linux являются reiserfs, ext2, ext3. Первая из этих файловых систем поддерживает журналирование как метаданных, так и данных. Но поддержка журналирования данных основана на особенностях функционирования самой файловой системы и является, так сказать, ее побочным эффектом и фактически не используется. Рассмотрим механизм журналирования в этой файловой системе подробней.

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

Общая структура журнала имеет вид, представленный на рис. 1. Journal Header — это описатель журнала, в котором содержится информация о последней оконченной (flushed) транзакции, а также о местоположении следующей неоконченной транзакции в журнале. Его структура представлена в табл. 3.

Транзакции, хранящиеся в журнале этой файловой системы, имеют вид, показанный на рис. 2. Все транзакции, попадающие в журнал, имеют заголовок, описывающий транзакцию и ее содержимое — description block, за которым следуют непосредственно блоки, которые и являются изменениями, применяемыми к файловой системе (см. табл. 4).

Наиболее важным полем в этом блоке является поле Real blocks, в котором блокам, следующим за description block, ставятся в соответствие реальные блоки файловой системы, которые и будут изменены по завершении транзакции. Иными словами, в этом поле содержится номер блока, в который попадет соответствующий блок из журнала. Например, представим это поле как массив четырехбайтных значений от К [1] до К [n]. Тогда если К [1]=8840, то в блок реальной файловой системы с номером 8840 попадет блок, идущий первым за description block, в блок с номером К [2] — второй и т. д. Окончание транзакции отмечается при помощи commit block, его описание дано в табл. 5.

Стоит отметить, что если блоки транзакции не умещаются в description block, то не уместившиеся блоки будут перенесены в это же поле в commit block. Таким образом, получается, что размер блока файловой системы влияет на объем сохраняемых данных в журнале транзакций. Чем меньше размер блока, тем меньше данных попадет в транзакцию, поскольку число соответствий ограничено значением 2* (размер блока — 24). Однако для журналирования в этой файловой системе этого более чем достаточно.

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

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

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

Теперь о файловой системе ext3

Перейдем к рассмотрению устройства файловой системы ext3. Она является расширением файловой системы ext2, в которую добавлена возможность журналирования. В зависимости от вариантов монтирования файловой системы, на ней создается скрытый или видимый файл журнала. Кроме того, этот файл можно создавать на отдельном носителе, т. е. не на том, в котором происходят сами изменения. Такой подход призван обеспечить ускорение записи данных на диск за счет того, что время ожидания окончания записи в журнал будет меньше, чем если бы это происходило на одном диске. Сам механизм журналирования вынесен в отдельный логический уровень файловой системы, который занимается управлением и диспетчеризацией транзакций. Формат самого файла журнала сходен с применяемым в ReiserFS, как показано на рис. 3.

В начале журнала расположен заголовок, или суперблок. В нем описаны параметры журнала. Он предваряется структурой стандартного заголовка блока (см. листинг 2). Стандартный заголовок является общим для всех типов блоков, которые могут использоваться в журнале. Сам суперблок ext3 версии 2 представлен в листинге 3. Как мы видим, его структура несколько сложнее, чем в ReiserFS. Это обусловлено более развитыми механизмами журналирования и большей функциональностью.

В журнале присутствует несколько типов блоков:

На типах суперблока мы подробно останавливаться не будем. Коснемся только блоков, описывающих транзакции. Первый блок — DESCRIPTOR_BLOCK. Он описывает начало транзакции. Его структура, а также флаги, которые могут быть в нем выставлены, представлена в листинге 4. Говоря просто, при записи в журнал этим блоком открывается транзакция. Номер этой транзакции записывается в соответствующее поле стандартного заголовка. Следом за заголовком идут записи типа journal_block_tag_t из листинга 4. Каждая из этих записей определяет, какому блоку файловой системы соответствует данный блок журнала. Например, первый блок журнала после блока дескрипторов соответствует блоку файловой системы, описанному первой записью дескриптора. Этот механизм описания соответствия блоков журнала с блоками файловой системы схож с механизмом, применяемым в ReiserFS. При записи изменений на диск транзакция закрывается блоком COMMIT_BLOCK. Закрытие означает удачное завершение транзакции и тот факт, что данные будут непротиворечивы. Он содержит только стандартный заголовок, в котором указан номер закрываемой транзакции. В случае сбоя системы данные и метаданные файловой системы могут быть восстановлены в соответствии с блоками закрытой транзакции. Блок файловой системы, включенный в журнал, может быть отменен, чтобы хранящиеся в нем изменения не применялись в процессе восстановления. Для этой цели используется блок отмены (отзыва; см. листинг 5), который содержит порядковый номер и список отменяемых блоков. Во время восстановления все блоки, указанные в блоке отмены, порядковые номера которых меньше порядкового номера блока отмены, восстанавливаться не будут. Механизм отмены используется с целью избежать повторного применения журналированных данных. Например, вы удаляете каталог. Затем создаете некий файл, а файловая система выделят под него те же блоки, что были выделены под каталог. Обе эти транзакции зафиксированы. Происходит сбой. После перезагрузки начинается восстановление данных по журналу. Процедура восстановления начинает повторять транзакции, при этом берет измененные блоки из журнала. В итоге блоки нового файла, если данные не журналировались, могут оказаться затертыми метаданными каталога, т. е. в файловой системе появится удаленный ранее каталог и испортит ваш файл. Для того чтобы избежать такого поведения, во время процедуры фиксации транзакции в журнал записываются блоки отмены для операций удаления метаданных.

Таким образом, можно сказать, что в случае с ext3 мы имеем систему журналирования, сходную по своему принципу с ReiserFS. Тут также журналируется содержимое целых блоков. Однако, в отличие от ReiserFS и NTFS, существуют дополнительные режимы, позволяющие журналировать не только метаданные, но и сами данные файлов. Это может несколько уменьшить производительность, однако значительно повышает устойчивость файловой системы к различного рода сбоям. Кроме того, журналирование данных и знание устройства журнала может помочь вам побороть последствия хакерской атаки.

Подведем итог

Наиболее отказоустойчивой файловой системой, исходя из функциональности журналов, является файловая система ext3 в режиме полного журналирования. ReiserFS и NTFS в этом вопросе уступают. Кроме того, в NTFS процедура восстановления по журналу несколько сложнее логически, нежели в ReiserFS или ext3. Однако тут стоит отметить, что журнал NTFS предоставляет больше возможностей с точки зрения удобства отслеживания изменений в файловой системе в целях безопасности. Об этих возможностях и методах отслеживания речь пойдет в следующей статье.

Каждая операционная система использует собственные файловые системы для хранения данных. Для Windows это NTFS, в macOS применяется APFS, а большинство Linux дистрибутивов полагаются на Ext4. Несмотря на то, что все эти файловые системы отличаются друг от друга на фундаментальном уровне, у них есть и нечто общее – все они являются журналируемыми файловыми системами.

Давайте немного поговорим о журналировании и том, как оно влияет на повседневную работу.

Что такое журналирование?

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

К примеру, удаление файла в файловой системе Unix включает в себя три шага:

Удаление его записи в директории
Освобождение индексного дескриптора в пул свободных дескрипторов
Возврат всех дисковых блоков в пул свободных дисковых блоков

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

Для того чтобы предотвратить эти проблемы журналируемые файловые системы выделяют специальную область – журнал, в который записываются все изменения, перед тем как применять их к файлам и директориям. В случае возникновения сбоя, утилита восстановления просто производит чтение из журнала файловой системы и воспроизводит все изменения, пока ФС вновь не станет согласованной.

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

Заключение

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

Журналируемые файловые системы обещают освободить системных администраторов от проблем с повреждением диска при сбоях системы. Даже без запуска проверки целостности файловой системы. Хотя в реальности, конечно, все немного сложнее. И как показывает недавнее обсуждение, может, даже более запутанно, чем многие из нас думают, поскольку обеспечение целостности журналируемых файловых систем влияет на производительность.

Файловая система, такая как ext3, использует отдельную область на диске, называемую журнал. При внесении изменений в метаданные файловой системы, эти изменения сначала записываются в журнал без модификации остальной файловой системы. После записи всех изменений в журнал в него добавляется "коммит блок", указывающий на завершение транзакции. И только после записи коммит блока, транзакция фиксируется, и измененные метаданные записываются на диск. Если система в какой-то момент выйдет из строя, то с помощью информации в журнале можно безопасно завершить работу и избежать повреждений файловой системы из-за того, что обновилась только часть метаданных.

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

Но есть еще одна проблема: файловые системы ext3 и ext4 по умолчанию не используют барьеры. Опция есть, но если администратор не включил их явно, то эти файловые системы работают без барьеров, хотя в некоторых дистрибутивах (например, SUSE) значения по умолчанию другие. Эрик Сандин (Eric Sandeen) недавно решил, что эту ситуацию надо изменить и сделал патч, модифицирующий настройки по умолчанию для ext3 и ext4. И тогда началось бурное обсуждение.

Эндрю Мортон (Andrew Morton) очень подробно ответил, почему значение по умолчанию именно такое:

В прошлый раз, когда мы пытались это изменить, производительность на многих нагрузках ухудшилась на 30%, поэтому я в ужасе выбросил все эти патчи. Я думаю, что мы не можем пойти на это и замедлить работу всех машин настолько серьезно…
Здесь нет идеальных решений, и я склоняюсь к тому, чтобы не будить эту спящую собаку и оставить параметры по умолчанию на усмотрение разработчиков дистрибутивов.

Но это не просто везение. Тед Тсо (Ted Ts'o) объясняет это тем, что журнал ext3 / ext4 обычно расположен непрерывно. Во-первых, драйвер файловой системы пытается создать его непрерывным. Во-вторых, журнал обычно создается одновременно с файловой системой, когда легко найти непрерывное пространство. Непрерывность и упорядоченность полезны не только для производительности, но и для предотвращения переупорядочивания. Обычно коммит блок будет размещаться сразу после остальных данных в журнале, поэтому у диска нет причин для переупорядочивания. Коммит блок естественным образом записывается на диск сразу после остальных записей журнала.

Тем не менее никто не утверждает, что так будет всегда. Дисковые накопители могут вести себя и по-другому. Кроме того, журнал представляет собой кольцевой буфер. Поэтому когда транзакция записывается в конец журнала, то коммит блок может оказаться в более раннем блоке, перед другими записями журнала. Так что вероятность повреждения есть всегда. На самом деле, у Криса Мэйсона (Chris Mason) есть для этого тесты. Нет сомнений, что работа без барьеров менее безопасна, чем с ними.

Если вы готовы принять удар по производительности, то можете включить барьеры. В том случае, конечно, когда ваша файловая система не основана на LVM (как в некоторых дистрибутивах по умолчанию). Оказывается, device mapper не поддерживает барьеры. В остальных случаях было бы неплохо уменьшить снижение производительности. И, похоже, это можно сделать.

Текущая реализация ext3 (когда барьеры включены) для каждой транзакции выполняет следующую последовательность операций:

Данные записываются в журнал

Записывается коммит блок

Выполняется следующий барьер

Позже метаданные сбрасываются на диск

В ext4 первый барьер (шаг 2) можно опустить, так как файловая система ext4 поддерживает контрольные суммы в журнале.

Если данные журнала и коммит блок переупорядочены, а операция прервана в результате сбоя, то контрольная сумма журнала не будет соответствовать той, которая хранится в коммит блоке, и транзакция будет отклонена.

Крис Мейсон полагает, что было бы "в целом безопасно" убрать этот барьер и в ext3, с возможным исключением, когда журнал доходит до конца и начинает писаться с начала.

Еще одна идея для ускорения работы — отложить операции с барьерами, когда это возможно. Если нет острой необходимости сразу сбрасывать данные на диск, то можно создать несколько транзакций в журнале, и сбрасывать на диск одним барьером.

Также есть некоторый потенциал для улучшения за счет тщательного упорядочивания операций, чтобы барьеры (которые обычно реализованы в виде запросов "сбросить все отложенные операции на диск") не форсировали запись блоков, не требующих упорядоченности.

Похоже, пришло время подумать, как сделать стоимость барьеров приемлемой. Тед Тсо, кажется, считает аналогично:

Я думаю, что мы должны включить барьеры в ext3/4, а затем работать над уменьшением накладных расходов в ext4 / jbd2. Скорее всего, подавляющее большинство систем не работают в условиях, подобных тем, которые использовал Крис для демонстрации проблемы и безопасность файловой системы по умолчанию должна быть в приоритете.

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

Интересно развиваться в данном направлении? Запишитесь на бесплатный Demo-урок «Конфигурирование web-сервера (Apache, Nginx, балансировка Nginx)» и участвуйте в трансляции «Работа с логами в Linux», которую проведёт Павел Викирюк — оператор связи MVNO, DevOps-инженер.

Рядовому пользователю компьютерных электронных устройств редко, но приходится сталкиваться с таким понятием, как «выбор файловой системы». Чаще всего это происходит при необходимости форматирования внешних накопителей (флешек, microSD), установке операционных систем, восстановлении данных на проблемных носителях, в том числе жестких дисках. Пользователям Windows предлагается выбрать тип файловой системы, FAT32 или NTFS, и способ форматирования (быстрое/глубокое). Дополнительно можно установить размер кластера. При использовании ОС Linux и macOS названия файловых систем могут отличаться.

Возникает логичный вопрос: что такое файловая система и в чем ее предназначение? В данной статье дадим ответы на основные вопросы касательно наиболее распространенных ФС.

Что такое файловая система

Обычно вся информация записывается, хранится и обрабатывается на различных цифровых носителях в виде файлов. Далее, в зависимости от типа файла, кодируется в виде знакомых расширений – *exe, *doc, *pdf и т.д., происходит их открытие и обработка в соответствующем программном обеспечении. Мало кто задумывается, каким образом происходит хранение и обработка цифрового массива в целом на соответствующем носителе.

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

Запись файлов большого объема приводит к необходимости фрагментации, когда файлы не сохраняются как целые единицы, а делятся на фрагменты. Каждый фрагмент записывается в отдельные кластеры, состоящие из ячеек (размер ячейки составляет один байт). Информация о всех фрагментах, как части одного файла, хранится в файловой системе.

Файловая система связывает носитель информации (хранилище) с прикладным программным обеспечением, организуя доступ к конкретным файлам при помощи функционала взаимодействия программ A PI. Программа, при обращении к файлу, располагает данными только о его имени, размере и атрибутах. Всю остальную информацию, касающуюся типа носителя, на котором записан файл, и структуры хранения данных, она получает от драйвера файловой системы.

На физическом уровне драйверы ФС оптимизируют запись и считывание отдельных частей файлов для ускоренной обработки запросов, фрагментации и «склеивания» хранящейся в ячейках информации. Данный алгоритм получил распространение в большинстве популярных файловых систем на концептуальном уровне в виде иерархической структуры представления метаданных (B-trees). Технология снижает количество самых длительных дисковых операций – позиционирования головок при чтении произвольных блоков. Это позволяет не только ускорить обработку запросов, но и продлить срок службы HDD. В случае с твердотельными накопителями, где принцип записи, хранения и считывания информации отличается от применяемого в жестких дисках, ситуация с выбором оптимальной файловой системы имеет свои нюансы.

Основные функции файловых систем

Файловая система отвечает за оптимальное логическое распределение информационных данных на конкретном физическом носителе. Драйвер ФС организует взаимодействие между хранилищем, операционной системой и прикладным программным обеспечением. Правильный выбор файловой системы для конкретных пользовательских задач влияет на скорость обработки данных, принципы распределения и другие функциональные возможности, необходимые для стабильной работы любых компьютерных систем. Иными словами, это совокупность условий и правил, определяющих способ организации файлов на носителях информации.

Основными функциями файловой системы являются:

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

Задачи файловой системы

Функционал файловой системы нацелен на решение следующих задач:

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

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

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

Операционные системы и типы файловых систем

Существует три основных вида операционных систем, используемых для управления любыми информационными устройствами: Windows компании Microsoft, macOS разработки Apple и операционные системы с открытым исходным кодом на базе Linux. Все они, для взаимодействия с физическими носителями, используют различные типы файловых систем, многие из которых дружат только со «своей» операционкой. В большинстве случаев они являются предустановленными, рядовые пользователи редко создают новые дисковые разделы и еще реже задумываются об их настройках.

В случае с Windows все выглядит достаточно просто: NTFS на всех дисковых разделах и FAT32 (или NTFS) на флешках. Если установлен NAS (сервер для хранения данных на файловом уровне), и в нем используется какая-то другая файловая система, то практически никто не обращает на это внимания. К нему просто подключаются по сети и качают файлы.

На мобильных гаджетах с ОС Android чаще всего установлена ФС версии ext4 во внутренней памяти и FAT32 на карточках microSD. Владельцы продукции Apple зачастую вообще не имеют представления, какая файловая система используется на их устройствах – HFS+, HFSX, APFS, WTFS или другая. Для них существуют лишь красивые значки папок и файлов в графическом интерфейсе.

Более богатый выбор у линуксоидов. Но здесь настройка и использование определенного типа файловой системы требует хотя бы минимальных навыков программирования. Тем более, мало кто задумывается, можно ли использовать в определенной ОС «неродную» файловую систему. И зачем вообще это нужно.

Рассмотрим более подробно виды файловых систем в зависимости от их предпочтительного использования с определенной операционной системой.

Файловые системы Windows

Исходный код файловой системы, получившей название FAT, был разработан по личной договоренности владельца Microsoft Билла Гейтса с первым наемным сотрудником компании Марком Макдональдом в 1977 году. Основной задачей FAT была работа с данными в операционной системе Microsoft 8080/Z80 на базе платформы MDOS/MIDAS. Файловая система FAT претерпела несколько модификаций – FAT12, FAT16 и, наконец, FAT32, которая используется сейчас в большинстве внешних накопителей. Основным отличием каждой версии является преодоление ограниченного объема доступной для хранения информации. В дальнейшем были разработаны еще две более совершенные системы обработки и хранения данных – NTFS и ReFS.

FAT (таблица распределения файлов)

Числа в FAT12, FAT16 и FAT32 обозначают количество бит, используемых для перечисления блока файловой системы. FAT32 является фактическим стандартом и устанавливается на большинстве видов сменных носителей по умолчанию. Одной из особенностей этой версии ФС является возможность применения не только на современных моделях компьютеров, но и в устаревших устройствах и консолях, снабженных разъемом USB.

Пространство FAT32 логически разделено на три сопредельные области:

зарезервированный сектор для служебных структур;
табличная форма указателей;
непосредственная зона записи содержимого файлов.

К недостатком стандарта FAT32 относится ограничение размера файлов на диске до 4 Гб и всего раздела в пределах 8 Тб. По этой причине данная файловая система чаще всего используется в USB-накопителях и других внешних носителях информации. Для установки последней версии ОС Microsoft Windows 10 на внутреннем носителе потребуется более продвинутая файловая система.

С целью устранения ограничений, присущих FAT32, корпорация Microsoft разработала обновленную версию файловой системы exFAT (расширенная таблица размещения файлов). Новая ФС очень схожа со своим предшественником, но позволяет пользователям хранить файлы намного большего размера, чем четыре гигабайта. В exFAT значительно снижено число перезаписей секторов, ответственных за непосредственное хранение информации. Функция очень важна для твердотельных накопителей ввиду необратимого изнашивания ячеек после определенного количества операций записи. Продукт exFAT совместим с операционными системами Mac, Android и Windows. Для Linux понадобится вспомогательное программное обеспечение.

NTFS (файловая система новой технологии)

Стандарт NTFS разработан с целью устранения недостатков, присущих более ранним версиям ФС. Впервые он был реализован в Windows NT в 1995 году, и в настоящее время является основной файловой системой для Windows. Система NTFS расширила допустимый предел размера файлов до шестнадцати гигабайт, поддерживает разделы диска до 16 Эб (эксабайт, 10 18 байт ). Использование системы шифрования Encryption File System (метод «прозрачного шифрования») осуществляет разграничение доступа к данным для различных пользователей, предотвращает несанкционированный доступ к содержимому файла. Файловая система позволяет использовать расширенные имена файлов, включая поддержку многоязычности в стандарте юникода UTF, в том числе в формате кириллицы. Встроенное приложение проверки жесткого диска или внешнего накопителя на ошибки файловой системы chkdsk повышает надежность работы харда, но отрицательно влияет на производительность.

ReFS (Resilient File System)

Последняя разработка Microsoft, доступная для серверов Windows 8 и 10. Архитектура файловой системы в основном организована в виде B + -tree. Файловая система ReFS обладает высокой отказоустойчивостью благодаря реализации новых функций:

Copy-on-Write (CoW) – никакие метаданные не изменяются без копирования;
данные записываются на новое дисковое пространство, а не поверх существующих файлов;
при модификации метаданных новая копия хранится в свободном дисковом пространстве, затем система создает ссылку из старых метаданных на новую версию.

Все это позволяет повысить надежность хранения файлов, обеспечивает быстрое и легкое восстановление данных.

Файловые системы macOS

Для операционной системы macOS компания Apple использует собственные разработки файловых систем:

HFS+, которая является усовершенствованной версией HFS, ранее применяемой на компьютерах Macintosh, и ее более соверешенный аналог APFS. Стандарт HFS+ используется во всех устройствах под управлением продуктов Apple, включая компьютеры Mac, iPod, а также Apple X Server.
Кластерная файловая система Apple Xsan, созданная из файловых систем StorNext и CentraVision, используется в расширенных серверных продуктах. Эта файловая система хранит файлы и папки, информацию Finder о просмотре каталогов, положениях окна и т.д.

Файловые системы Linux

В отличие от ОС Windows и macOS, ограничивающих выбор файловой системы предустановленными вариантами, Linux предоставляет возможность использования нескольких ФС, каждая из которых оптимизирована для решения определенных задач. Файловые системы в Linux используются не только для работы с файлами на диске, но и для хранения данных в оперативной памяти или доступа к конфигурации ядра во время работы системы. Все они включены в ядро и могут использоваться в качестве корневой файловой системы.

Основные файловые системы, используемые в дистрибутивах Linux:

Ext2, Ext3, Ext4 или Extended Filesystem – стандартная файловая система, первоначально разработанная еще для Minix. Содержит максимальное количество функций и является наиболее стабильной в связи с редкими изменениями кодовой базы. Начиная с ext3 в системе используется функция журналирования. Сегодня версия ext4 присутствует во всех дистрибутивах Linux.

JFS или Journaled File System разработана в IBM в качестве альтернативы для файловых систем ext. Сейчас она используется там, где необходима высокая стабильность и минимальное потребление ресурсов (в первую очередь в многопроцессорных компьютерах). В журнале хранятся только метаданные, что позволяет восстанавливать старые версии файлов после сбоев.

ReiserFS также разработана в качестве альтернативы ext3, поддерживает только Linux. Динамический размер блока позволяет упаковывать несколько небольших файлов в один блок, что предотвращает фрагментацию и улучшает работу с небольшими файлами. Недостатком является риск потери данных при отключении энергии.

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

Btrfs или B-Tree File System легко администрируется, обладает высокой отказоустойчивостью и производительностью. Используется как файловая система по умолчанию в OpenSUSE и SUSE Linux.

Другие ФС, такие как NTFS, FAT, HFS, могут использоваться в Linux, но корневая файловая система на них не устанавливается, поскольку они для этого не предназначены.

Дополнительные файловые системы

В операционных системах семейства Unix BSD (созданы на базе Linux) и Sun Solaris чаще всего используются различные версии ФС UFS (Unix File System), известной также под названием FFS (Fast File System). В современных компьютерных технологиях данные файловые системы могут быть заменены на альтернативные: ZFS для Solaris, JFS и ее производные для Unix.

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

ZFS – «Zettabyte File System» разработана для распределенных хранилищ Sun Solaris OS;
Apple Xsan – эволюция компании Apple в CentraVision и более поздних разработках StorNext;
VMFS (Файловая система виртуальных машин) разработана компанией VMware для VMware ESX Server;
GFS – Red Hat Linux именуется как «глобальная файловая система» для Linux;
JFS1 – оригинальный (устаревший) дизайн файловой системы IBM JFS, используемой в старых системах хранения AIX.

Практический пример использования файловых систем

Владельцы мобильных гаджетов для хранения большого объема информации используют дополнительные твердотельные накопители microSD (HC), по умолчанию отформатированные в стандарте FAT32. Это является основным препятствием для установки на них приложений и переноса данных из внутренней памяти. Чтобы решить эту проблему, необходимо создать на карточке раздел с ext3 или ext4. На него можно перенести все файловые атрибуты (включая владельца и права доступа), чтобы любое приложение могло работать так, словно запустилось из внутренней памяти.

Операционная система Windows не умеет делать на флешках больше одного раздела. С этой задачей легко справится Linux, который можно запустить, например, в виртуальной среде. Второй вариант - использование специальной утилиты для работы с логической разметкой, такой как MiniTool Partition Wizard Free . Обнаружив на карточке дополнительный первичный раздел с ext3/ext4, приложение Андроид Link2SD и аналогичные ему предложат куда больше вариантов.

Флешки и карты памяти быстро умирают как раз из-за того, что любое изменение в FAT32 вызывает перезапись одних и тех же секторов. Гораздо лучше использовать на флеш-картах NTFS с ее устойчивой к сбоям таблицей $MFT. Небольшие файлы могут храниться прямо в главной файловой таблице, а расширения и копии записываются в разные области флеш-памяти. Благодаря индексации на NTFS поиск выполняется быстрее. Аналогичных примеров оптимизации работы с различными накопителями за счет правильного использования возможностей файловых систем существует множество.

Надеюсь, краткий обзор основных ФС поможет решить практические задачи в части правильного выбора и настройки ваших компьютерных устройств в повседневной практике.

Читайте также: