XFS - журналируемая файловая система разработанная Silicon Graphics, но сейчас выпущенная открытым кодом (open source).

Официальная информация на http://oss.sgi.com/projects/xfs/

XFS была создана в начале 90ых (1992-1993) фирмой Silicon Grapgics (сейчас SGI) для мультимедийных компьютеров с ОС Irix. Файловая система была ориентирована на очень большие файлы и файловые системы. Особенностью этой файловой системы является устройство журнала - в журнал пишется часть метаданных самой файловой системы таким образом, что весь процесс восстановления сводится к копированию этих данных из журнала в файловую систему. Размер журнала задается при создании системы, он должен быть не меньше 32 мегабайт; а больше и не надо - такое количество незакрытых транзакций тяжело получить.

Некоторые особенности:

Более эффективно работает с большими файлами.

Имеет возможность выноса журнала на другой диск, для повышения производительности.

Сохраняет данные кэша только при переполнении памяти, а не периодически как остальные.

В журнал записываются только мета-данные.

Используются B+ trees.

Используется логическое журналирование

11.6.4 Файловая система rfs

RFS (RaiserFS) - журналируемая файловая система разработанная Namesys.

Официальная информация на RaiserFS

Некоторые особенности:

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

Использует специально оптимизированные b* balanced tree (усовершенствованная версия B+ дерева)

Динамически ассигнует i-узлы вместо их статического набора, образующегося при создании "традиционной" файловой системы.

Динамические размеры блоков.

11.6.4 Файловая система jfs

JFS (Journaled File System) - журналируемая файловая система разработанная IBM для ОС AIX, но сейчас выпущенная как открытый код.

Официальная информация на Journaled File System Technology for Linux

Некоторые особенности:

Журналы JFS соответствуют классической модели транзакций, принятой в базах данных

В журнал записываются только мета-данные

Размер журнала не больше 32 мегабайт.

Асинхронный режим записи в журнал - производится в моменты уменьшения трафика ввода/вывода

Используется логическое журналирование.

11.7 Сравнительная таблица некоторых современных файловых систем

Выбор файловой системы всегда вызывал жаркие споры среди приверженцев Linux, которые готовы бить свою грудь, пытаясь убедить своих оппонентов в том, что они абсолютно ошибаются. И это более чем понятно, поскольку, в отличие от Windows или macOS, пользователям которых гораздо реже приходится думать об этом в ходе повседневных компьютерных приключений, в этой операционной системе нет недостатка в различных вариантах файловой системы. Хотя ext используется по умолчанию для большинства дистрибутивов Linux, XFS вряд ли воспитывает заднюю часть и пользуется большой популярностью в мире Linux. Но что это за файловая система и как она отличается от ее коллег?

XFS - это, по сути, одна из старейших и самых зрелых файловых систем, доступных для Linux. Будучи разработанной Silicon Graphics и представленная в 1994 году с их операционной системой IRIX, в 2001 году она перешла на ядро ​​Linux с целью успешно справиться с огромными объемами данных. Формат был необязательным в течение длительного времени и был окончательно выбран по умолчанию для Red Hat Enterprise Linux 7 в 2014 году. В настоящее время он поддерживается большинством дистрибутивов Linux, в то время как RHEL, Oracle Linux 7, CentOS 7 и некоторые другие используют его как файловая система по умолчанию.

XFS - это 64-битная файловая система ведения журнала. Содержимое каждого файла в XFS хранится в блоках данных на диске. Чтобы эффективно записывать все выделенное и свободное пространство, XFS группирует эти блоки в смежные последовательности, называемые экстентами, которые могут быть решены файловой системой как отдельные единицы. Минимальный размер экстента - один блок, и он может расти по мере увеличения размера файла. Вся информация о файле (его метаданных) хранится в специальной структуре данных, называемой inode. Сама файловая система состоит из трех основных компонентов:

The data section используется для хранения всех метаданных файловой системы, а также пользовательских данных (кроме файлов реального времени). Этот раздел разделен на определенное количество групп распределения с равным размером (вы можете заранее определить их количество или размер - минимальный - 16 МБ, а максимальный - до терабайта). Каждая группа распределения может рассматриваться как отдельная файловая система, которая самостоятельно контролирует использование собственного пространства. Несколько групп распределения позволяют XFS одновременно обрабатывать многочисленные операции, избегая ухудшения производительности. Для отслеживания свободного места в каждой группе распределения используется пара специальных структур, называемых деревьями B +, узлы которых содержат информацию об исходном блоке каждой свободной области и ее размере в блоках. Тот же подход используется для отслеживания блоков данных и inodes, принадлежащих каждому файлу.

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

The real-time section хранит данные файлов в реальном времени - файлы, которые необходимо немедленно записать или обновить, без каких-либо задержек.

Такая конструкция делает XFS особенно полезной при обработке больших файлов и хранилищ. Максимальный размер файла в настоящий момент составляет 9 экзабайт, а один том может составлять до 18 экзабайт. Общее количество файлов не ограничено. Среди других сильных сторон этой файловой системы:

Journaling . Использование журналирования для операций метаданных гарантирует согласованность XFS даже после сбоя или потери мощности.

Delayed allocation . Данные в XFS не сразу записываются на жесткий диск, а хранятся в ОЗУ в течение некоторого времени, в то время как необходимое количество блоков данных просто резервируется. В конце концов, может получиться, что нет необходимости писать его вообще. Таким образом, XFS оптимизирует производительность записи и уменьшает фрагментацию файлов.

Preallocation . XFS резервирует дисковое пространство до того, как будут записаны блоки данных. Это также помогает избежать фрагментации файлов, поскольку полный файл становится более вероятным для записи в непрерывный ряд блоков на диске.

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

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

Extended attributes . Расширенные атрибуты позволяют пользователю прикреплять произвольные метаданные (в виде пары имя-значение) к любому файлу или inode. В отличие от обычных атрибутов, которые строго определяются файловой системой, они могут содержать любую информацию, такую ​​как автор документа или цифровую подпись.

Advanced Input/Output . Использование нескольких групп распределения позволяет осуществлять высокоскоростные параллельные операции ввода-вывода.

Volume snapshots. Снимки позволяют создавать копию тома в определенный момент времени и при необходимости возвращать файловую систему обратно в это состояние.

Online defragmentation and resizing . Файловая система может быть дефрагментирована или увеличена при установке и активации.

Native backup/restore . XFS имеет встроенное резервное копирование и восстановление, которое может быть выполнено с помощью встроенных утилит xfsdump и xfsrestore. Более того, даже файлы, которые по какой-то причине не получили резервной копии, вопреки распространенному мнению, в случае потери данных имеют чрезвычайно высокие шансы на восстановление. Хотя некоторые специалисты утверждают, что потеря данных из XFS полностью невосстанавливается, многие средства восстановления данных, такие как UFS Explorer , Recovery Explorer и Raise Data Recovery , успешно справляются с этой задачей в течение многих лет.

Тем не менее, эта файловая система также имеет несколько недостатков. Прежде всего, раздел, отформатированный с помощью XFS, не может быть сокращен, хотя вы все равно можете сделать резервную копию, создать новую меньшую файловую систему и затем восстановить ее. Во-вторых, XFS не имеет встроенных методов сжатия данных. Более того, файловая система не использует контрольные суммы для обеспечения целостности сохраненных пользовательских данных и как можно скорее обнаруживает все гнилые биты, поэтому некоторые файлы могут бесшумно испортиться, и когда это наконец выйдет, возможно, уже слишком поздно для устранения проблемы, и огромная потеря данных будет неизбежной. Кроме того, XFS использует журналирование для метаданных, но не изменяет никаких изменений данных, поэтому в случае непредвиденного выключения системы вы, вероятно, потеряете данные из файлов, открытых в этот момент. Кроме того, если у вас есть система двойной загрузки Windows / Linux, Windows не сможет прочитать раздел в формате XFS без каких-либо дополнительных инструментов.

Чтобы узнать, поддерживает ли XFS ваш диск, используйте команду file с опцией -s, которая покажет информацию о типе файловой системы.

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

Недавно, на конференции linux.conf.au 2012 разработчик XFS Дэйв Чиннер (Dave Chinner) заметил, что, по его мнению, XFS привлечет большее количество пользователей в будущем. Его доклад касался решения проблем с масштабированием, а также дальнейшей работы по улучшению файловой системы. Если верить его словам, возможно в ближайшие несколько лет мы услышим значительно больше об XFS .
XFS часто рассматривают как файловую систему для тех, кто работает с файлами больших размеров. По словам Дэйва, с этой задачей она справляется прекрасно, кроме того, XFS традиционно хорошо работает при больших нагрузках. Но ситуация ухудшается при записи метаданных. Поддержка записи большого количества метаданных в течение долгого времени является слабым местом для этой файловой системы. Говоря коротко, метаданные записываются очень медленно, и практически не масштабируются, даже при работе на одном CPU.
Насколько медленно? Дэйв привел несколько слайдов, на которых показаны результаты теста fs-mark в сравнении с ext4. Результаты XFS значительно хуже (практически в два раза) даже на одном CPU. С увеличением числа потоков до восьми ситуация еще больше ухудшается, после чего производительность ext4 также резко падает. Для работ, связанных с высокой нагрузкой на систему ввода/вывода, где необходимо изменять большое количество метаданных (в качестве примера была приведена распаковка тарболла), ext4 показала производительность в 20 - 50 раз больше, чем XFS . Такое отставание представляет собой действительно серьезную проблему.

Отложенное журналирование

Проблема заключается в журнале ввода/вывода: XFS генерировала очень большое количество трафика для изменения метаданных. В худших случаях практически весь трафик ввода/вывода представлял собой данные для журнала, а не данные, которые пользователь пытался записать на диск. Попытки решения данной задачи в течение многих лет включали одно важное изменение алгоритма записи и множество других важных оптимизаций и настроек. Единственное, что не требовалось - любое изменение формата данных на диске, хотя оно может быть востребовано в будущем.
Нагрузки, связанные с изменением большого количества метаданных, могут в конечном итоге привести к тому, что один и тот же блок директории будет изменен много раз за короткий период времени, а каждое из этих изменений генерирует запись, которая должна быть сохранена в журнале. Это и есть источник огромного журнального трафика. Концепция решения этой проблемы очень проста: отложить обновление журнала и объединять изменения одного и того же блока в одной записи. На самом деле, для претворения в жизнь этой идеи в масштабируемой реализации потребовалось несколько лет тяжелой работы, но сейчас она уже работает. Отложенное журналирование для файловой системы XFS поддерживается в ядре версии 3.3.
Фактически технология отложенного журналирования была позаимствована у файловой системы ext3, поэтому алгоритм ее работы известен и требуется намного меньше времени для ее внедрения в XFS , чем если бы она разрабатывалась с нуля. Вместе с преимуществами в быстродействии это также значит значительное уменьшение объема кода. Если вы хотите более детально изучить, как работает эта технология, подробности можно найти в файле filesystems/xfs-delayed-logging.txt в дереве документации ядра.
Отложенное журналирование - это большое изменение, но не единственное. Быстрый способ резервирования места в журнале остается горячей темой в XFS . Сегодня он не требует блокировки, в то время как медленный способ все еще требует глобальной блокировки этой точки. Код асинхронной записи метаданных приводил к сильной фрагментации ввода/вывода, значительно уменьшая производительность. Теперь запись метаданных откладывается, а перед записью они сортируются. Это значит, что, по словам Дэйва, файловая система выполняет функции планировщика ввода/вывода. Но планировщик ввода/вывода работает с очередью запросов, которая, как правило, ограничивается 128 записями, в то время как очередь отложенных метаданных XFS может содержать многие тысячи записей, так что имеет смысл производить сортировку в файловой системе, до передачи метаданных системе ввода/вывода. "Активные элементы журнала (Active log items)" - это механизм, который повышает производительность при работе с большими сортированными списками элементов журнала путем накапливания изменений и применения их в пакетном режиме. Кроме того, кэшированные метаданные были удалены со страницы подкачки, так их наличие приводило к запросам на загрузку страниц в неподходящее время.

Сравнение файловых систем

Как же XFS масштабируется после всех изменений? При работе с одним или двумя потоками она все еще немного медленнее, чем ext4, но с увеличением числа потоков до восьми ее производительность линейно возрастает, в то время как у ext4 ухудшается, а у btrfs ухудшается еще больше. На сегодняшний день масштабируемость XFS ограничивается блокировкой слоя ядра, работающего с виртуальными файловыми системами, а не кодом, связанным непосредственно с файловой системой. Обход директорий теперь работает быстрее даже с одним потоком, и еще быстрее при использовании восьми потоков.
Масштабируемость выделения дискового пространства в настоящее время на несколько порядков быстрее, чем в ext4. Это положение немного изменится после введения в релизе 3.2 функции "bigalloc", которая повышает масштабируемость выделения дискового пространства в ext4 на два порядка, если используется достаточно большой размер блока. К сожалению, при этом пропорционально увеличивается место, занимаемое на диске файлами малых размеров. Например, для размещения исходного кода ядра Linux в этом случае потребуется 160 Гб дискового пространства. Bigalloc не очень хорошо совместим с некоторыми другими функциями ext4 и требует сложной настройки. По словам Дэйва ext4 страдает от архитектурных недостатков - такие вещи, как использование битовых карт для отслеживания дискового пространства, были типичны для восьмидесятых годов. Она просто не может масштабироваться на действительно большие файловые системы.
Выделение дискового пространства в Btrfs происходит еще медленнее, чем в ext4. По словам Дэйва, проблема в основном заключается в перемещении кэша свободного дискового пространства, на которое затрачивается слишком много ресурсов процессора. Однако это не архитектурная ошибка, поэтому она может быть достаточно легко исправлена.

Будущее файловых систем Linux

На сегодняшний день проблемы с производительностью и масштабируемостью можно считать решенными. Теперь узким местом является слой VFS, поэтому дальнейшие усилия должны быть направлены на этот участок работы. Но самым большим вызовом в будущем будет проблема надежности хранения данных, и это может потребовать значительных изменений в файловой системе XFS.
Надежность заключается не только в том, чтобы не потерять данные - в этом вопросе, надеемся, XFS уже достаточно надежна, проблема также связана с масштабируемостью. Просто непрактично отключать петабайтную файловую систему, чтобы запустить ее проверку, или утилиту восстановления данных. В будущем просто необходимо сделать возможным проводить такие операции на работающей файловой системе. Это потребует надежного инструмента для обнаружения сбоев, встроенного в файловую систему, чтобы проверять метаданные на лету. Некоторые другие файловые системы имеют подобные механизмы, но, по словам Дэйва, для XFS такую систему лучше будет реализовать на уровне массивов устройств для хранения данных, либо на уровне приложений.
"Проверка метаданных" означает разработку метаданных, которые защищали бы себя от неправильно адресованных запросов на запись на уровне устройств для хранения данных. Проверки контрольной суммы недостаточно - она показывает только, что данные были записаны правильно. Метаданные с такой защитой могли бы определять блоки, которые были записаны в неправильное место и помогать в восстановлении целостности файловой системы при серьезных сбоях. Это также может помочь решить известную проблему reiserfs, которая заключается в том, что утилита для восстановления файловой системы вводится в заблуждение устаревшими метаданными, или метаданными, найденными в образах файловой системы.
Разработка таких метаданных потребует большого количества изменений. Каждый блок метаданных будет включать UUID файловой системы, к которой он принадлежит, а также номера блока и индексного дескриптора, чтобы файловая система могла определить, что метаданные переданы из правильного источника. Также здесь будут контрольные суммы для определения поврежденных блоков метаданных и собственный идентификатор для связывания метаданных с собственным индексным дескриптором или директорией. Обратное отображение дерева распределения позволит файловой системе быстро идентифицировать, какому файлу принадлежит любой блок.
Разумеется, нынешний формат XFS не обеспечивает хранения всех этих дополнительных данных, поэтому его необходимо будет менять. При этом, по словам Дэйва, не планируется сохранять какую-либо обратную совместимость с текущим форматом файловой системы. Это делается для того, чтобы предоставить полную свободу разработчикам в создании нового формата файловой системы, который будет использоваться в течение многих лет. Кроме добавления описанных выше возможностей, разработчики также планируют добавить пространство для d_type в структуре директории, счетчики версии NFSv4, время создания индексного дескриптора и, вероятно, что-то еще. Максимальный размер директории, который сегодня составляет всего 32 Гб, также будет увеличен.
При реализации всех этих функций появятся новые возможности: проактивное обнаружение повреждений файловой системы, локализация и замена отключенных блоков, а также улучшенное исправление ошибок файловой системы "на лету". Это значит, как сказал Дэйв, что XFS останется лучшей файловой системой для работы с большими объемами данных под Linux в течение долгого времени.
Каковы последствия всего этого с точки зрения перспектив btrfs? По словам Дэйва, btrfs явно не оптимизирована для работы с большим количеством метаданных - имеются серьезные проблемы с масштабируемостью. Этого и следовало ожидать от файловой системы, находящейся на ранней стадии разработки. Потребуется определенное время для решения этих проблем, а некоторые из них, возможно, окажутся неразрешимыми. С другой стороны, надежность хранения данных в btrfs находится на высоте, и в течение ближайших нескольких лет она может использоваться в таком качестве.
Ext4, напротив, страдает от проблем масштабируемости, связанных с ошибками в инфраструктуре. В любом случае, согласно результатам тестов, приведенных Дэйвом, она не является самой быстрой. Сказывается почтенный возраст ее архитектуры, хотя имеются планы по повышению ее надежности. Ext4 в ближайшее время будет бороться, чтобы остаться на уровне конкурентов.
В конце своего выступления Дэйв затронул еще несколько вопросов. По его словам, btrfs, благодаря своим достоинствам, вскоре заменит ext4 как файловую систему по умолчанию во многих дистрибутивах. В то же время ext4 уступает XFS на большинстве рабочих операций, включая те, где она была традиционно сильна. Проблема масштабируемости проявляется уже на небольших серверах. Кроме того, она не так стабильна, как о ней думают пользователи. В конце он спросил: "Почему же мы все еще используем ext4?"
Можно предположить, что у разработчиков ext4 имеется хороший ответ на этот вопрос, но, к сожалению, никто из них не присутствовал в зале. Так что, похоже, что это обсуждение должно быть продолжено в другом месте. Послушать его будет интересно.