Btrfs

Btrfs (произносится как "better F S", "butter F S", "b-tree F S", или просто по буквам) - это компьютерный формат хранения данных, который сочетает в себе файловую систему, основанную на принципе копирования при записи (COW), с менеджером логических томов (не путать с LVM от Linux), разработанные совместно. Она была основана Крисом Мейсоном в 2007 году для использования в Linux, а с ноября 2013 года формат файловой системы на диске был объявлен стабильным в ядре Linux.

Btrfs предназначена для устранения нехватки пулов, моментальных снимков, контрольных сумм и комплексного охвата нескольких устройств в файловых системах Linux.[8] Крис Мейсон, главный автор Btrfs, заявил, что его целью было "позволить [Linux] масштабироваться для хранилища, которое будет доступно. Масштабирование - это не только обращение к хранилищу, но и возможность администрирования и управления им с помощью понятного интерфейса, который позволяет людям видеть, что используется, и делает его более надежным ".

Пример групп квот Btrfs

История

Скриншот информации об использовании файловой системы Btrfs Базовая структура данных Btrfs — B-дерево копирования при записи - была первоначально предложена исследователем IBM Охадом Роде на презентации в USENIX 2007.[16] Крис Мейсон, инженер, работавший в то время над ReiserFS для SUSE, позже в том же году присоединился к Oracle и начал работу над новой файловой системой, основанной на этих B-деревьях.

В 2008 году главный разработчик файловых систем ext3 и ext4, Теодор Тс'о, заявил, что, хотя ext4 обладает улучшенными функциями, это не является значительным достижением; он использует старую технологию и является промежуточным звеном. Тс'о сказал, что Btrfs - лучшее направление, потому что "оно предлагает улучшения в масштабируемости, надежности и простоте управления". У Btrfs также есть "ряд тех же дизайнерских идей, что и у reiser3 /4".

Btrfs 1.0 с окончательным форматом на диске первоначально планировалась к выпуску в конце 2008 года, и, наконец, была принята в состав основной линейки ядра Linux в 2009 году. Несколько дистрибутивов Linux начали предлагать Btrfs в качестве экспериментального варианта корневой файловой системы во время установки. В некоторых дистрибутивах Linux.

В июле 2011 года функции автоматической дефрагментации и очистки Btrfs были объединены в версию 3.0 основной версии ядра Linux. Помимо Мейсона из Oracle, Мяо Се из Fujitsu внес свой вклад в повышение производительности.В июне 2012 года Крис Мейсон ушел из Oracle в Fusion-io, которую он покинул год спустя вместе с Джозефом Бациком, чтобы присоединиться к Facebook. Работая в обеих компаниях, Мейсон продолжал свою работу над Btrfs.

В 2012 году два дистрибутива Linux перевели Btrfs из экспериментального в производственный или поддерживаемый статус: Oracle Linux в марте, за которыми в августе последовал SUSE Linux Enterprise.

В 2015 году Btrfs была принята в качестве файловой системы по умолчанию для SUSE Linux Enterprise Server (SLE) 12.

В августе 2017 года Red Hat объявила в примечаниях к выпуску для Red Hat Enterprise Linux (RHEL) 7.4, что больше не планирует переводить Btrfs на полностью поддерживаемую функцию (она была включена в качестве "предварительного просмотра технологии" после бета-версии RHEL 6), отметив, что она останется доступной в серии выпусков RHEL 7. Btrfs была удалена из RHEL 8 в мае 2019 года. RHEL перешел с ext4 в RHEL 6 на XFS в RHEL 7.

В 2020 году Btrfs была выбрана в качестве файловой системы по умолчанию для Fedora 33 для настольных вариантов.

Характеристики

Список функций

Реализовано

Начиная с версии 5.0 ядра Linux, Btrfs реализует следующие функции:

В некоторых конфигурациях в основном самовосстанавливается из-за характера копирования при записи

• Оперативная дефрагментация и опция монтирования с автоматической дефрагментацией
• Рост и сокращение онлайн-объема
• Добавление и удаление онлайн-блочного устройства
• Балансировка в режиме онлайн (перемещение объектов между блочными устройствами для балансировки нагрузки)
• Автономная проверка файловой системы
• Оперативная очистка данных для поиска ошибок и автоматического их исправления для файлов с избыточными копиями
• RAID 0, РЕЙД 1, и РЕЙД 10
• Вложенные разделы (один или несколько отдельно монтируемых корней файловой системы в каждом разделе диска)
• Прозрачное сжатие с помощью zlib, LZO[6] и (начиная с 4.14) ZSTD, настраивается для каждого файла или тома
• Атомарные записываемые (через копирование при записи) или доступные только для чтения снимки вложенных объемов
• Клонирование файлов (повторная ссылка, копирование при записи) с помощью cp --reflink <source file> <destination file>
• Контрольные суммы для данных и метаданных (CRC-32C). Новые хэш-функции реализованы начиная с версии 5.5: xxHash, SHA256, BLAKE2B.
• Преобразование на месте из ext3 / 4 в Btrfs (с откатом). Эта функция регрессировала в btrfs-progs версии 4.0, переписанная с нуля в версии 4.6.
• Объединенное монтирование хранилища, доступного только для чтения, известное как заполнение файловой системы (хранилище, доступное только для чтения, используемое в качестве резервной копии при записи для Btrfs с возможностью записи)
• Удаление блоков (освобождает место в некоторых виртуализированных установках и улучшает выравнивание износа на твердотельных накопителях с TRIM)
• Отправка / получение (сохранение различий между моментальными снимками в двоичный поток)
• Инкрементное резервное копирование
• Внеполосная дедупликация данных (требует пользовательских инструментов)
• Возможность обработки файлов подкачки и разделов подкачки

Реализовано, но не рекомендуется для производственного использования

• Иерархические квоты для каждого подтомника
• РЕЙД 5, RAID 6

Планируется, но еще не реализовано

• Дедупликация внутриполосных данных
• Онлайн-проверка файловой системы
• RAID с поддержкой до шести устройств четности, превосходящий по надежности RAID 5 и RAID 6
• RAID 0, RAID 1 и RAID 10 уровня объекта
• Шифрование
• Постоянный кэш чтения и записи (L2ARC + ZIL, lvmcache и т.д.)

Ожидалось, что в 2009 году Btrfs предложит набор функций, сопоставимый с ZFS, разработанной Sun Microsystems. После приобретения Oracle Sun в 2009 году Мейсон и Oracle решили продолжить разработку Btrfs.

Клонирование

Btrfs предоставляет операцию клонирования, которая атомарно создает моментальный снимок файла с копированием при записи. Такие клонированные файлы иногда называют повторными ссылками, в свете предлагаемого связанного с ними системного вызова ядра Linux.

При клонировании файловая система не создает новую ссылку, указывающую на существующий индекс; вместо этого она создает новый индекс, который изначально использует те же блоки диска, что и исходный файл. В результате клонирование работает только в пределах одной и той же файловой системы Btrfs, но начиная с версии 3.6 ядра Linux при определенных обстоятельствах оно может выходить за границы вложенных объемов. Фактические блоки данных не дублируются; в то же время, из-за характера копирования при записи (CoW) Btrfs, модификации любого из клонированных файлов не видны в исходном файле и наоборот.

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

Поддержка этой функции Btrfs была добавлена в версии 7.5 GNU coreutils с помощью --reflink опции в cp команде.

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

Вложенные файлы и моментальные снимки

Вложенный объем Btrfs можно рассматривать как отдельное пространство имен файлов POSIX, которое можносмонтироватьsubvol отдельно, передав subvolid опции mount(8) или, и,, которые можно смонтировать, передав в и ,, утилиту. К нему также можно получить доступ, смонтировав вложенный том верхнего уровня, и в этом случае вложенные тома видны и доступны как его подкаталоги.

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

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

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

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

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

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

Отправка–получение

Учитывая любую пару вложенных объемов (или снимков), Btrfs может сгенерировать двоичную разницу между ними (с помощью btrfs send команды), которая может быть воспроизведена позже (с помощью btrfs receive), возможно, в другой файловой системе Btrfs. Функция отправки–получения эффективно создает (и применяет) набор изменений данных, необходимых для преобразования одного подобъема в другой.

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

Группы квот==

Группа квот (или qgroup) устанавливает верхний предел пространства, которое может занимать вложенный том или снимок. Новый снимок изначально не использует квоту, поскольку его данные совместно используются с родительским файлом, но впоследствии за новые файлы и операции копирования при записи с существующими файлами взимается плата. Когда квоты активны, группа квот автоматически создается с каждым новым вложенным томом или моментальным снимком. Эти начальные группы квот являются строительными блоками, которые могут быть сгруппированы (с помощью btrfs qgroup команды) в иерархии для реализации пулов квот.[49]

Группы квот применяются только к вложенным каталогам и моментальным снимкам, в то время как применение квот к отдельным подкаталогам, пользователям или группам пользователей невозможно. Однако возможны обходные пути путем использования разных вложенных объемов для всех пользователей или групп пользователей, для которых требуется применение квоты.

Преобразование на месте из ext2 / 3 / 4 и ReiserFS

В результате того, что очень мало метаданных привязано к фиксированным местоположениям, Btrfs могут деформироваться, приспосабливаясь к необычным пространственным макетам внутренних устройств хранения. btrfs-convert Инструмент использует эту способность для преобразования файловой системы ext2 / 3 / 4 или ReiserFS на месте, путем вложения эквивалентных метаданных Btrfs в ее нераспределенное пространство - при сохранении неизмененной копии исходной файловой системы.

Преобразование включает в себя создание копии всех метаданных ext2 / 3 / 4, в то время как файлы Btrfs просто указывают на те же блоки, которые используются файлами ext2 / 3 / 4. Таким образом, основная часть блоков распределяется между двумя файловыми системами до того, как преобразование станет постоянным. Благодаря принципу копирования при записи в Btrfs исходные версии блоков данных файла сохраняются при всех модификациях файла. Пока преобразование не станет постоянным, только блоки, которые были помечены как свободные в ext2 / 3 / 4, используются для хранения новых модификаций Btrfs, что означает, что преобразование может быть отменено в любое время (хотя это приведет к удалению любых изменений, внесенных после преобразования в Btrfs).

Все преобразованные файлы доступны для записи в вложенном томе Btrfs по умолчанию. Разреженный файл, содержащий все ссылки на исходную файловую систему ext2 / 3 / 4, создается в отдельном вложенном томе, который может быть смонтирован сам по себе как образ диска, доступный только для чтения, что позволяет одновременно получать доступ к исходной и преобразованной файловым системам. Удаление этого разреженного файла освобождает место и делает преобразование постоянным.

В версиях 4.x основного ядра Linux преобразование ext3 / 4 на месте считалось непроверенным и редко использовалось. Однако функция была переписана с нуля в 2016 году для btrfs-progs версии 4.6. и с тех пор считается стабильной.

Преобразование на месте из ReiserFS было введено в сентябре 2017 года с ядром 4.13.

Соединительные монтажные / затравочные устройства

При создании новой Btrfs существующую Btrfs можно использовать в качестве "начальной" файловой системы, доступной только для чтения. Затем новая файловая система будет действовать как наложение копирования при записи на начальный файл, как форма объединительного монтирования. Начальный файл может быть позже отсоединен от Btrfs, после чего балансировщик просто скопирует все начальные данные, на которые все еще ссылается новая файловая система, перед отсоединением. Мейсон предположил, что это может быть полезно для установщика с Live CD, который может загружаться с начального файла Btrfs, доступного только для чтения, на оптическом диске, выполнять перебалансировку на целевой раздел установочного диска в фоновом режиме, пока пользователь продолжает работать, затем извлекать диск для завершения установки без перезагрузки.

Шифрование

В своем интервью 2009 года Крис Мейсон заявил, что поддержка шифрования была запланирована для Btrfs. В то же время обходным путем для объединения шифрования с Btrfs является использование механизма шифрования на весь диск, такого как dm-crypt / LUKS, на базовых устройствах и создание файловой системы Btrfs поверх этого уровня.

По состоянию на 2020 год, разработчики работали над добавлением ключевого хэша, такого как HMAC (SHA256).

Проверка и восстановление

Системы Unix традиционно полагаются на программы "fsck" для проверки и восстановления файловых систем. Эта функциональность реализована с помощью btrfs check программы. Начиная с версии 4.0 эта функциональность считается относительно стабильной. Однако по состоянию на декабрь 2022 года документация btrfs предполагает, что ее --repair опцию можно использовать только в том случае, если вам посоветовал "разработчик или опытный пользователь" По состоянию на август 2022 года документация SLE рекомендует использовать Live CD, выполнять резервное копирование и использовать опцию восстановления только в качестве последнего средства.[78]

Существует другой инструмент с именем btrfs-restore, который можно использовать для восстановления файлов из размонтируемой файловой системы без изменения самой поврежденной файловой системы (т. Е. неразрушающим образом).

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

Дизайн

В первоначальном предложении Охада Рода на USENIX 2007 отмечалось, что B +-деревья, которые широко используются в качестве структур данных на диске для баз данных, не могут эффективно разрешать моментальные снимки на основе копирования при записи, потому что его конечные узлы были связаны друг с другом: если лист был скопирован при записи, его братья, сестры и родители должны были бы быть такими же, как и их братья, сестры и родители, и так далее, пока не будет скопировано все дерево. Вместо этого он предложил модифицированное B-дерево (у которого нет привязки к листу), с пересчетом, связанным с каждым узлом дерева, но хранящимся в специальной структуре свободной карты, и некоторыми изменениями алгоритмов балансировки дерева, чтобы сделать их удобными для копирования при записи. Результатом была бы структура данных, подходящая для высокопроизводительного хранилища объектов, которое могло бы выполнять моментальные снимки копирования при записи, сохраняя при этом хороший параллелизм.

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

Btrfs структурирована как несколько слоев таких деревьев, все с использованием одной и той же реализации B-tree. В деревьях хранятся общие элементы, отсортированные по 136-битному ключу. Наиболее значимые 64 бита ключа представляют собой уникальный идентификатор объекта. Средние восемь битов представляют собой поле типа элемента: его использование встроено в код в качестве фильтра элемента при поиске по дереву. Объекты могут содержать несколько элементов нескольких типов. Остальные (наименее значимые) 64 бита используются способами, зависящими от типа. Таким образом, элементы для одного и того же объекта в конечном итоге располагаются рядом друг с другом в дереве, сгруппированные по типу. Выбирая определенные значения ключа, объекты могут дополнительно размещать элементы того же типа в определенном порядке.

Узлы внутреннего дерева - это просто плоские списки пар ключ-указатель, где указатель является номером логического блока дочернего узла. Конечные узлы содержат ключи элементов, помещенные в переднюю часть узла, и данные элементов, помещенные в конец, причем они растут навстречу друг другу по мере заполнения листа.[57]

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

В каждом каталоге записи каталога отображаются как элементы каталога, младшие значащие биты ключевых значений которых являются CRC32C хэшем их имени файла. Их данные представляют собой ключ местоположения или ключ элемента inode, на который он указывает. Таким образом, элементы каталога вместе могут выступать в качестве индекса для поиска по пути к индексному индексу, но не используются для итерации, поскольку они сортируются по своему хэшу, эффективно случайным образом переставляя их. Это означает, что пользовательские приложения, перебирающие и открывающие файлы в большом каталоге, будут, таким образом, генерировать гораздо больше запросов к диску между несмежными файлами - заметное снижение производительности в других файловых системах с каталогами, упорядоченными по хэшу, такими как ReiserFS, ext3 (с включенными индексами Htree) и ext4, все из которых имеют имена файлов с хэшем TEA. Чтобы избежать этого, каждая запись каталога имеет элемент индекса каталога, ключевое значение элемента которого устанавливается в счетчик для каждого каталога, который увеличивается с каждой новой записью каталога. Таким образом, итерация по этим элементам индекса возвращает записи примерно в том же порядке, что и сохраненные на диске.

Файлы с жесткими ссылками в нескольких каталогах содержат несколько элементов ссылок, по одному для каждого родительского каталога. Файлы с несколькими жесткими ссылками в одном каталоге объединяют имена файлов всех ссылок в один элемент reference. Это был недостаток дизайна, который ограничивал количество жестких ссылок в одном каталоге до того, сколько их могло поместиться в одном древовидном блоке. (При размере блока по умолчанию в 4 кб, средней длине имени файла в 8 байт и заголовке для каждого имени файла в 4 байта это будет меньше 350.) Было замечено, что приложения, которые интенсивно использовали несколько жестких ссылок в одном каталоге, такие как git, GNUS, GMame и BackupPC, не достигли этого предела.[86] В конечном итоге ограничение было снято (и по состоянию на октябрь 2012 года было объединено в ожидании выпуска в Linux 3.7) путем введения дополнительных расширенных ссылочных элементов для хранения имен файлов с жесткими ссылками, которые иначе не подходят.

Экстенты

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

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

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

Дерево распределения экстентов

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

Файловая система делит выделенное пространство на группы блоков, которые представляют собой области выделения переменного размера, которые чередуются между предпочтительными экстентами метаданных (узлы дерева) и экстентами данных (содержимое файла). Соотношение данных к группам блоков метаданных по умолчанию равно 1:2. Они предназначены для использования концепций распределителя блоков Орлова для совместного размещения связанных файлов и предотвращения фрагментации, оставляя свободное пространство между группами. (Однако группы блоков Ext3 имеют фиксированное расположение, вычисляемое исходя из размера файловой системы, тогда как группы блоков в Btrfs являются динамическими и создаются по мере необходимости.) Каждая группа блоков связана с элементом группы блоков. Элементы Inode в дереве файловой системы содержат ссылку на их текущую группу блоков.

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

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

Теоретически, дерево распределения экстентов делает ненужным обычное растровое изображение в свободном пространстве, поскольку дерево распределения экстентов действует как B-tree версия дерева BSP. Однако на практике для ускорения выделения используется красно-черное дерево растровых изображений размером с страницу в памяти. Эти растровые изображения сохраняются на диске (начиная с Linux 2.6.37, с помощью space_cache опции монтирования[89]) в виде специальных экстентов, которые освобождены от проверки суммы и копирования при записи.

Дерево контрольных сумм и очистка

Смотрите также: Незаметное повреждение данных

Контрольные суммы CRC-32C вычисляются как для данных, так и для метаданных и хранятся в виде элементов контрольной суммы в дереве контрольных сумм. Имеется место для 256 бит контрольных сумм метаданных и до полного узла (примерно 4 КБ или более) для контрольных сумм данных. В Btrfs предусмотрены дополнительные алгоритмы проверки сумм, которые будут добавлены в будущих версиях файловой системы.

На непрерывный прогон выделенных блоков приходится один элемент контрольной суммы, причем контрольные суммы для каждого блока последовательно упакованы в данные элемента. Если контрольных сумм больше, чем может поместиться, они переносятся в другой элемент контрольной суммы на новом листе. Если файловая система обнаруживает несоответствие контрольной суммы при чтении блока, она сначала пытается получить (или создать) точную копию этого блока с другого устройства – если используются методы внутреннего зеркалирования или RAID.

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

Дерево журналов

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

Деревья блоков и устройств

Блочные устройства разделены на физические блоки объемом 1 гигабайт для данных и 256 Мбайт для метаданных.[94] Физические блоки на нескольких устройствах могут быть зеркально отражены или объединены в один логический блок. Эти логические блоки объединены в единое логическое адресное пространство, которое использует остальная часть файловой системы.

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

сингл

от 1 логического до 1 физического фрагмента

dup

от 1 логического блока до 2 физических блоков на 1 блочном устройстве

raid0

От N логических блоков до N≥ 2 физических блоков на N≥ 2 блочных устройствах

raid1

от 1 логического блока до 2 физических блоков на 2 из N≥2 блочных устройств,[95] в отличие от обычного RAID 1, который имеет N физических блоков

raid1c3

от 1 логического блока до 3 физических блоков из N≥ 3 блочных устройств

raid1c4

от 1 логического блока до 4 физических блоков из N≥ 4 блочных устройств

raid5

От N (для N≥2) логических блоков до N + 1 физического блока на N + 1 блочных устройствах, при этом 1 физический блок используется для обеспечения четности

raid6 От N (для N≥2) логических блоков до N + 2 физических блоков на N + 2 блочных устройствах, причем 2 физических блока используются в качестве четности N - это количество блочных устройств, на которых все еще остается свободное место, когда блок выделен. Если N недостаточно велико для выбранного зеркального отображения, то в файловой системе фактически не хватает места.

Деревья перемещения

Операции дефрагментации, сжатия и перебалансировки требуют перемещения экстентов. Однако выполнение простого копирования перемещаемого экстента при записи приведет к нарушению совместного использования между моментальными снимками и потреблению дискового пространства. Для сохранения общего доступа используется алгоритм обновления и подкачки, при этом специальное дерево перемещения служит пустым местом для затронутых метаданных. Перемещаемый экстент сначала копируется в пункт назначения. Затем, следуя обратным ссылкам вверх по дереву файловой системы затронутого подраздела, метаданные, указывающие на старый экстент, постепенно обновляются, указывая на новый; все вновь обновленные элементы сохраняются в дереве перемещения. После завершения обновления элементы в дереве перемещения заменяются на их аналоги в затронутом вложенном объеме, а дерево перемещения отбрасывается.[96]

Суперблок

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

Зеркала суперблоков хранятся в фиксированных местах: 64 КБ в каждом блочном устройстве, с дополнительными копиями объемом 64 мбайт, 256 гигабайт и 1 пибайт. При обновлении зеркала суперблока увеличивается его номер поколения. Во время монтирования используется копия с наибольшим номером поколения. Все зеркала superblock обновляются одновременно, за исключением режима SSD, в котором обновления между зеркалами чередуются для обеспечения некоторого выравнивания износа.

Коммерческая поддержка

Поддерживается

• Oracle Linux начиная с версии 7
• Корпоративный сервер SUSE Linux версии 12
• Synology DiskStation Manager (DSM) от версии 6.0

Больше не поддерживается

Btrfs была включена в качестве "предварительного просмотра технологии" в Red Hat Enterprise Linux 6 и 7; она была удалена в RHEL 8 в 2018 году.

Btrfs была наложена поверх массивов mdadm-raid в Netgear ReadyNAS 1xx на базе arm и 3xx на базе Intel примерно в 2013 году (вероятно, чтобы использовать контрольные суммы и моментальные снимки btrfs, избегая все еще нестабильных функций btrfs-raid). Обновления для OS6 на базе Debian Jessie все еще предлагались примерно в 2022 году (возможно, считалось, что они все еще поддерживаются?).

Смотри также

APFS – файловая система копирования при записи для macOS, iPadOS, iOS, tvOS и watchOS

• Bcachefs
• Сравнение файловых систем
• HAMMER – файловая система DragonFly BSD, использующая B-деревья в сочетании с контрольными суммами в качестве меры противодействия повреждению данных
• Список файловых систем
• ReFS – файловая система копирования при записи для Windows Server 2012
• ZFS

Пруф

archive.kernel.org/oldwiki/btrfs.wiki.kernel.org/

• youtube.com/watch?v=hxWuaozpe2I
• lwn.net/Articles/577961/
• marc.merlins.org/linux/talks/Btrfs-LC2014-JP/Btrfs.pdf
• web.archive.org/web/.linux-mag.com/id/7416/