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

XFS — файловая система будущего?

Оригинал: XFS: the filesystem of the future?
Автор: Jonathan Corbet
Дата публикации: 20 января 2012 года
Перевод: А. Кривошей
Дата перевода: февраль 2012 г.

Linux работает на большом количестве файловых систем, но две из них (ext4 и btrfs) привлекают к себе больше всего внимания. Недавно, на конференции 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 имеется хороший ответ на этот вопрос, но, к сожалению, никто из них не присутствовал в зале. Так что, похоже, что это обсуждение должно быть продолжено в другом месте. Послушать его будет интересно.

Если вам понравилась статья, поделитесь ею с друзьями:


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

Если вы не специалист, то выбор файловой системы не совсем понятен. Мы вкратце рассмотрим несколько современных файловых систем, доступных в Mandriva Linux.

Second Extended Filesystem (сокращенно звучит как ext2FS или просто ext2) много лет была файловой системой GNU/Linux по умолчанию. Она заменила Extended File System (вот откуда в названии появилось «Second»). ext2 устраняет определенные проблемы и ограничения своего предка.

ext2 соблюдает обычные стандарты для файловых систем UNIX®-типа. С самого начала она была предназначена для дальнейшего развития, сохраняя при этом высокую отказоустойчивость и хорошую производительность.

Замечание

Предупреждение: перед изменением размера раздела, он должен быть размонтирован.

Как видно из названия, Third Extended File System является наследником ext2. Она совместима с последней, но была улучшена за счет добавления журналирования

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

Это разрушение могло бы привести к частичной или полной потере хранимых данных.

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

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

Замечание

Как и для ext2, перед изменением размера такого раздела, он должен быть размонтирован.

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

Замечание

Размер такого раздела может быть изменен «на лету», без размонтирования файловой системы.

JFS — это журналируемая файловая система, разработанная и используемая в IBM. Изначально она была собственнической и закрытой, но потом корпорация IBM решила открыть к ней доступ движению за свободное программное обеспечение. Ее внутренняя структура близка к структуре reiserfs.

Внимание

В GNU/Linux размер такого раздела не может быть изменен.

XFS — это журналируемая файловая система, разработанная в SGI, и также используемая в операционной системе Irix. Изначально она была собственнической и закрытой, но потом в SGI также решили открыть к ней доступ для движения за свободное программное обеспечение. Ее внутренняя структура имеет много разнообразных возможностей, таких как поддержка пропускной способности реального времени, экстенты (непрерывные области с прямым доступом, резервируемые для определенного набора данных) и кластерные файловые системы (но не в свободной версии).

Внимание

В GNU/Linux размер такого раздела может быть изменен только в сторону увеличения. Вы не можете уменьшить его. Изменение размера может быть выполнено только для примонтированной файловой системы.

1.1.

XFS — файловая система будущего?

Различные используемые файловые системы

Таблица 36.1. Характеристики файловой системы

Ext2 Ext3 ReiserFS JFS XFS
Стабильность Отличная Очень хорошее Хорошая Среднее Хорошая
Утилиты для восстановления удаленных файлов Есть (комплекс) Есть (комплекс) Нет Нет Нет
Скорость перезагрузки после падения системы Долго, даже очень долго Быстро Очень быстро Очень быстро Очень быстро
Состояние данных в случае падения системы Вообще говоря, хорошее, но высок риск частичной или полной потери данных Очень хорошее Среднее[a] Очень хорошее Очень хорошее
Поддержка ACL Да Да Нет Нет Да

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

В ядре 2.6.X этот предел блочного устройства может быть увеличен при использовании ядра, скомпилированного с включенной поддержкой Large Block Device (). За дополнительной информацией обращайтесь к сайтам Adding Support for Arbitrary File Sizes to the Single UNIX Specification, Large File Support in Linux и Large Block Devices. С помощью этой функции и поддерживающей ее файловой системы вы можете достичь ёмкости в многие ТБ без специальных без специальных «примочек» файловой системы, как это сделано в JFS для размера файловой системы.

1.2. Различия между файловыми системами

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

Каждая из систем обладает своими преимуществами и недостатками. В действительности все зависит от того, как вы используете свою машину. Для простой настольной машины вполне хватит ext2. Для сервера предпочтение следует отдать журналируемой файловой системе типа ext3. reiserfs, возможно из-за ее происхождения, больше подходит для сервера баз данных. JFS более предпочтительна в случаях, где на первом месте стоит производительность файловой системы. XFS интересна в том случае, если вам нужны ее расширенные возможности. При «обычном» использовании, все эти четыре файловые системы дают приблизительно одинаковые результаты и все они обладают различными опциями для настройки под определённые задачи. Пожалуйста, обратитесь к соответствующей документации по файловым системам.

1.3. А как насчёт производительности?

Иллюстрированный самоучитель по Microsoft Windows 2003 → ГЛАВА 1. Планирование и установка системы → Выбор файловой системы

Выбор файловой системы

Данный раздел содержит некоторые общие рекомендации относительно выбора файловых систем: FAT, FAT32 или NTFS. Подробно свойства этих систем рассматриваются в главе 4 "Дисковые тома и файловые системы" (рекомендуется предварительно ознакомиться с этой главой, если вы не уверены в своем выборе).
На компьютере, работающем под управлением Windows 2000, Windows XP или одной из операционных систем семейства Windows Server 2003, можно применять любую из упомянутых выше файловых систем. Кроме того, разные файловые системы можно использовать одновременно на разных дисках или в разных разделах.

Обзор файловых систем: Ext4, Btrfs и Xfs

На выбор файловой системы оказывают влияние следующие факторы:

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

NTFS по сравнению с FAT предоставляет целый ряд преимуществ. Однако, если вашей целью является создание системы с двойной загрузкой, необходимо помнить о том, что доступ к файлам, расположенным в разделах NTFS, можно будет получить только из Windows Server 2003, Windows 2000 или Windows XP; для доступа из других систем необходимо использовать специальные драйверы. Поэтому, если вам требуется обеспечить двойную загрузку компьютера с использованием таких операционных систем, как Windows 9x/Millennium Edition (ME), то и системный раздел, и раздел, на котором установлена альтернативная операционная система, должны использовать файловую систему FAT (или FAT32) (иначе эта операционная система просто не сможет загрузиться).
В целом, рекомендации по выбору файловой системы для раздела, на который будет выполняться установка Windows Server 2003, сводятся к следующему.

  • Файловую систему FAT следует выбирать, если объем используемого раздела жесткого диска не превышает 2 Гбайт, и при этом требуется обеспечить возможности доступа к файлам на этом разделе при загрузке компьютера под управлением таких операционных систем, как MS-DOS, Windows 3.x, Windows 95 и OS/2.
  • Систему FAT следует выбирать и в том случае, когда необходимо обеспечить двойную загрузку компьютера с использованием таких операционных систем, как Windows 95 версии OSR2, Windows 98 или Windows ME, и при этом размер диска превышает 2 Гбайт. В этом случае диск будет отформатирован под файловую систему FAT32.
  • Для семейства Windows Server 2003 файловая система NTFS является предпочтительной, и ее рекомендуется использовать на всех разделах для всех серверов. Это связано с тем, что NTFS позволяет в полной мере воспользоваться преимуществами, предоставляемыми системой безопасности Windows 2000/XP/Windows Server 2003, в то время как FAT и FAT32 лишены многих функциональных возможностей по обеспечению безопасности. При выборе файловой системы NTFS программа Setup отформатирует жесткий диск с использованием NTFS 5.0. Контроллеры домена могут устанавливаться только в разделы NTFS.

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

НазадВперед

Актуально для всех версий Ubuntu.
Структура файловой системы в Linux отличается от Windows.

В Windows диски c: d:, в Linux это просто папка.
Всё, включая устройства, есть файлы.

Корень файловой системы обозначается /, в котором находится множество папок, доступ к которым, есть только у администратора (root).
Единственная папка доступная простому пользователю — это папка /home/user, которая содержит все файлы и папки пользователя, включая пользовательские фалы конфигураций.
Чтобы разделить системные файлы и пользовательские, обычно, /home выносят на отдельный раздел. Получается, аналог windows диска d:.
При переустановках системы, в том числе обновлении на новую версию, можно спокойно форматировать системный раздел и оставить нетронутым пользовательский.

Жесткие диски в Ubuntu именуются /dev/sda, /dev/sdb и т. д.

Разделы на жестких диска /dev/sda1, /dev/sda2 и т. д.

Для Ubuntu я создаю три раздела:

/dev/sda1 — /  ~15Гб корень, системный раздел;
/dev/sda2 — swap ~4Гб, по размеру оперативной памяти, раздел подкачки;
/dev/sda3 — /home все оставшееся место, пользовательский раздел.

Все манипуляции с диском, также удобно проводить в программе GParted, доступной на live диске Ubuntu.
Просто нажимаем клавишу WIN и в поиске вводим gparted. А при установке останется только выбрать точки монтирования и файловые системы.

Нажимаем «Новая таблица разделов», потом плюсик создаем раздел,

указываем размер, как договаривались 15 Гб. Использовать как Журналируемая файловая система Ext4. Точка монтирования / слэш.
Это корневой раздел.

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

 

Выбираем раздел подкачки.

И раздел под home. Где будут храниться файлы пользователя.

Если Ubuntu вы ставите рядом с Windows, то скорее всего первые разделы будут использованы под windows, тогда наши разделы будут именоваться /dev/sda3 и так далее.

Файловую систему будем использовать журналируемую ext4.
Более подробно можно почитать тут.

Стоит отметить, что Ubuntu из коробки прекрасно работает с ntfs, правда медленнее.
Поэтому если вы ставите Ubuntu рядом с Windows и планируете часто ей пользоваться, то можно оставить диск d: большим и всю информацию хранить на нем.

При установке нужно выбрать диск с ntfs

и выбрать точку монтирования, папку в которой будет доступен диск, выбираем /home/имя_пользователя/название_папки, например, /home/goodigy/disk_d

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

Напомню что, таблица разделов MBR, может содеражать только 4 первичных раздела, если нужно больше, то нужно создать расширенный, и в нем сколько угодно логических.
В случае установки рядом с Widows, так и получится. Подробнее.

Ubuntu можно ставить в логические разделы, и в любое место диска.  

Теперь можно вернуться, и продолжить установку.

Особенности установки Ubuntu 16.04/16.10 и Ubuntu 14.04 рядом с Windows.

Для установки Ubuntu рядом с Windows, нам понадобится свободное дисковое пространство. Чтобы освободить дисковое пространство в Windows 7 нужно,
нажать «Пуск», и в поиске написать «Управление».
Слева в меню выбрать «Управление дисками», правой кнопкой, на диске, который мы будем сжимать, «Сжать том», указать размер освобождаемого пространства.
В Windows 8 в поиске нужно писать «Управление дисками».

Теперь можно вернуться, и продолжить установку.

Особенности установки на системы с UEFI.

Установка на системы с UEFI, дополнительных действий не требует.
Если мы ставим Ubuntu рядом с Windows, то раздел для uefi занимающий примерно 100 Мб и отформатированный в FAT32, уже создан.
Просто устанавливаем, разбиваем диск, как показано выше.

Стоит отметить, что при использовании таблицы разделов GPT, можно создавать неограниченное количество разделов, и не нужно использовать расширенные и логические разделы.

Если же мы, устанавливаем Ubuntu единственной системой, первым нужно создать, тот самый, раздел для UEFI.

Самый первый раздел, 100 Мб, отформатированный в FAT32.

Выглядеть должно так:

/dev/sda1 — 100 Мб, раздел для UEFI,
/dev/sda2 /  ~15Гб корень, системный раздел;
/dev/sda3 — swap  ~4Гб, по размеру оперативной памяти, раздел подкачки;
/dev/sda4/home —все оставшееся место, пользовательский раздел.

Остальное Ubuntu сделает сама.

Теперь можно вернуться, и продолжить установку.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *