Btrfs, сокращение для b-treeфайловой системы, (произносится как «масляная суета», «лучше F S "," масло F S "," b-tree F S "или просто по буквам) - это файловая система, основанная на принципе копирования при записи (COW). Первоначально он был разработан в Oracle Corporation в 2007 году для использования в Linux, а с ноября 2013 года формат файловой системы на диске был объявлен стабильным в ядре Linux.
Btrfs предназначен для устранения недостатка пула, снимков, контрольных сумм и встроенного охвата нескольких устройств в файловых системах Linux. Крис Мейсон, главный автор Btrfs, заявил, что его цель состояла в том, чтобы «позволить [Linux] масштабироваться для доступного хранилища. Масштабирование - это не только обращение к хранилищу, но и возможность администрировать и управлять им с помощью чистого интерфейс, который позволяет людям видеть, что используется, и делает его более надежным ».
Содержание
1 История
2 Функции
2.1 Реализовано
2.2 Реализовано, но не рекомендуется для производственного использования
2.3 Планируется но еще не реализовано
2.4 Клонирование
2.5 Подтомы и моментальные снимки
2.6 Отправка-получение
2.7 Группы квот
2.8 Преобразование на месте из ext2 / 3/4 и ReiserFS
2.9 Объединение установка / раздача устройств
2.10 Шифрование
2.10.1 2020
2.11 Проверка и восстановление
3 Дизайн
3.1 Дерево файловой системы
3.1.1 Экстенты
3.2 Дерево распределения экстентов
3.3 Дерево контрольных сумм и очистка
3.4 Дерево журналов
3.5 Деревья фрагментов и устройств
3.6 Деревья перемещения
3.7 Суперблок
4 Коммерческая поддержка
4.1 Поддерживается
4.2 Больше не поддерживается
5 См. Также
6 Примечания
7 Ссылки
8 Внешние ссылки
История
Основная структура данных Btrfs - копирование при записи B-tree - было первоначально предложено исследователем IBM Охадом Родехом на презентации на USENIX 2007. Крис Мейсон, в то время инженер, работавший над ReiserFS для SUSE, присоединился к Oracle позже в том же году и начал работу над новой файловой системой, основанной на этих B-деревьях.
В 2008 году главный разработчик файловых систем ext3 и ext4, Теодор Ц'о, заявил, что, хотя ext4 имеет улучшенные функции, он не крупный прогресс; он использует старую технологию и является временной остановкой. Ц'о сказал, что Btrfs - лучшее направление, потому что «предлагает улучшения в масштабируемости, надежности и простоте управления». Btrfs также имеет «ряд тех же дизайнерских идей, что и reiser3 /4 had".
Btrfs 1.0, с финальным дисковым форматом, изначально планировалось выпустить в конце 2008 года и был окончательно принят в основную ветку ядра Linux в 2009 году. Несколько дистрибутивов Linux начали предлагать Btrfs в качестве экспериментального варианта корневой файловой системы во время установки.
В июле 2011 года функции автоматической дефрагментации и очистки Btrfs были объединены в версию 3.0 основной ветки ядра Linux. Помимо Мэйсона из Oracle, Мяо Се из Fujitsu внесла вклад в повышение производительности. В июне 2012 года Крис Мейсон ушел из Oracle в Fusion-io, которую он покинул год спустя вместе с Йозефом Бачиком, чтобы присоединиться к Facebook. Находясь в обеих компаниях, Мейсон продолжал свою работу над Btrfs.
В 2012 году два дистрибутива Linux перевели Btrfs из экспериментального в производственный или поддерживаемый статус: Oracle Linux в марте, а затем SUSE Linux Enterprise в августе.
В августе 2017 года Red Hat объявил в примечаниях к выпуску для Red Hat Enterprise Linux (RHEL) 7.4, что больше не планируется переводить Btrfs, который был включен как «предварительная версия технологии» с бета-версии RHEL 6, в полностью поддерживаемую функцию, отмечая, что он останется доступным в серии выпусков RHEL 7. Btrfs был удален из RHEL 8 в мае 2019 года.
В 2020 году Btrfs был выбран в качестве файловой системы по умолчанию для Fedora 33.
Возможности
Реализовано
Начиная с версии 5.0 ядра Linux, Btrfs реализует следующие функции:
В некоторых конфигурациях в основном самовосстановление из-за характера копирования при записи
Оперативная дефрагментация и опция монтирования autodefrag
Преобразование на месте из ext3 / 4 в Btrfs (с откатом). Эта функция регрессировала по сравнению с btrfs-progs версии 4.0, переписанной с нуля в 4.6.
Объединенное монтирование хранилища только для чтения, известное как заполнение файловой системы (хранилище только для чтения, используемое как резервное копирование при записи для Btrfs с возможностью записи)
В 2009 году ожидалось, что Btrfs предложит набор функций, сопоставимый с ZFS, разработанный Sun Microsystems. После приобретения Oracle компании Sun в 2009 году Мейсон и Oracle решили продолжить разработку Btrfs.
Клонирование
Btrfs обеспечивает операцию клонирования, которая атомарно создает копию на- записать снимок файла . Такие клонированные файлы иногда называют ссылками в свете предлагаемого связанного с ядром Linux системного вызова.
. При клонировании файловая система не создает новую ссылку, указывающую на существующую индексный дескриптор ; вместо этого он создает новый inode, который изначально использует те же блоки диска, что и исходный файл. В результате клонирование работает только в пределах одной и той же файловой системы Btrfs, но, начиная с версии ядра Linux 3.6, при определенных обстоятельствах оно может пересекать границы субтомов. Фактические блоки данных не дублируются; в то же время, из-за того, что Btrfs использует копирование при записи (CoW), изменения любого из клонированных файлов не видны в исходном файле и наоборот.
Клонирование не следует путать с жесткие ссылки, которые представляют собой записи каталога, которые связывают несколько имен файлов с реальными файлами в файловой системе. Хотя жесткие ссылки можно рассматривать как разные имена для одного и того же файла, клонирование в Btrfs предоставляет независимые файлы, которые изначально разделяют все свои дисковые блоки.
Поддержка этой функции Btrfs была добавлена в версии 7.5 GNU coreutils с помощью параметра --reflinkкоманды cp.
Помимо клонирования данных (FICLONE), Btrfs также поддерживает внеполосную дедупликацию с помощью FIDEDUPERANGE. Эта функция позволяет двум файлам с (даже частично) идентичными данными совместно использовать хранилище.
Подтомы и снимки
Подтом Btrfs можно рассматривать как отдельный файл POSIX пространство имен, mountable отдельно, передав параметры subvolили subvolidв утилиту mount(8). К нему также можно получить доступ, смонтировав вложенный том верхнего уровня, и в этом случае подобтомы видны и доступны как его подкаталоги.
Подтомы могут быть созданы в любом месте в иерархии файловой системы, и они также могут быть вложенными. Вложенные подобтомы появляются как подкаталоги в своих родительских подтомах, аналогично тому, как подтома верхнего уровня представляет свои подтомы как подкаталоги. Удаление подобтома невозможно, пока не будут удалены все подчиненные тома в иерархии вложенности; в результате субтомы верхнего уровня не могут быть удалены.
Любая файловая система Btrfs всегда имеет вложенный объем по умолчанию, который изначально установлен как вложенный том верхнего уровня, и монтируется по умолчанию, если нет опции выбора вложенного тома передается в mount. Вложенный объем по умолчанию может быть изменен при необходимости.
Btrfs снимок - это вложенный объем, который делится своими данными (и метаданными) с некоторым другим вложенным объемом, используя возможности копирования при записи Btrfs, а изменения снимка не отображаются в исходном подобтоме. После создания снимка с возможностью записи его можно рассматривать как альтернативную версию исходной файловой системы. Например, чтобы выполнить откат к моментальному снимку, необходимо размонтировать измененный исходный подобъем и смонтировать моментальный снимок на его месте. В этот момент исходный подобтом также может быть удален.
Природа Btrfs с копированием при записи (CoW) означает, что моментальные снимки создаются быстро, при этом изначально потребляя очень мало места на диске. Поскольку моментальный снимок представляет собой подобъем, также возможно создание вложенных снимков. Создание снимков подобъема не является рекурсивным процессом; таким образом, если создается моментальный снимок подобтома, каждый подобтом или моментальный снимок, который уже содержится в подобоме, отображается в пустой каталог с тем же именем внутри моментального снимка.
Создание моментальных снимков каталога невозможно, поскольку только подтомы могут иметь снимки. Однако существует обходной путь, который включает в себя ссылки, распределенные по подтомам: создается новый подтом, содержащий перекрестные ссылки на содержимое целевого каталога. Имея это в наличии, можно создать моментальный снимок этого нового тома.
Подтом в Btrfs сильно отличается от традиционного логического тома Logical Volume Manager (LVM). В LVM логический том представляет собой отдельное блочное устройство , а подобъем Btrfs - нет, и его нельзя обрабатывать или использовать таким образом. Создание снимков dd или LVM для btrfs приводит к потере данных, если либо оригинал, либо копия монтируются, когда оба находятся на одном компьютере.
Отправка – получение
Для любой пары подобъемов (или снимков)), Btrfs может сгенерировать двоичный файл diff между ними (с помощью команды btrfs send), который можно воспроизвести позже (с помощью btrfs receive), возможно, на другая файловая система Btrfs. Функция отправки-получения эффективно создает (и применяет) набор модификаций данных, необходимых для преобразования одного субтома в другой.
Функция отправки / получения может использоваться с регулярно запланированными моментальными снимками для реализации простой формы файловой системы репликация или с целью выполнения инкрементного резервного копирования.
Группы квот
Группа квот (или qgroup) накладывает верхний предел на пространство, которое может занимать подобъем или моментальный снимок. Новый моментальный снимок изначально не требует квоты, поскольку его данные используются совместно с его родительским моментом, но после этого взимается плата за новые файлы и операции копирования при записи для существующих файлов. Когда квоты активны, группа квот автоматически создается для каждого нового подтома или моментального снимка. Эти исходные группы квот представляют собой строительные блоки, которые можно сгруппировать (с помощью команды btrfs qgroup) в иерархии для реализации пулов квот.
Группы квот применяются только к подобъемам и моментальным снимкам, при этом квоты применяются для отдельных подкаталогов, пользователей или групп пользователей невозможно. Однако обходные пути возможны, если использовать разные подтомы для всех пользователей или групп пользователей, для которых требуется принудительная квота.
Преобразование на месте из 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, создается в отдельном подтоме, который монтируется сам по себе как образ диска только для чтения, что позволяет обращаться к исходной и преобразованной файловой системе с то же время. Удаление этого разреженного файла освобождает место и делает преобразование постоянным.
По состоянию на июнь 2015 г. и версии 4.x основной ветки ядра Linux преобразование в ext3 / 4 на месте считалось непроверенным и использовалось редко. Однако эта функция была переписана с нуля в 2016 году для btrfs-progs4.6. и с тех пор считается стабильным.
Преобразование на месте из ReiserFS было введено в сентябре 2017 года с ядром 4.13.
Union mount / seed devices
При создании новых Btrfs можно использовать существующие Btrfs. как "начальная" файловая система только для чтения. Затем новая файловая система будет действовать как наложение копирования при записи на начальное число, как форма монтирования объединения. Семя может быть позже отсоединено от Btrfs, после чего ребалансировщик просто скопирует любые начальные данные, на которые еще ссылается новая файловая система, перед отсоединением. Мейсон предположил, что это может быть полезно для установщика Live CD, который может загружаться с начального числа Btrfs только для чтения на оптическом диске, перенастраивая себя на целевой раздел на установочном диске в фоновом режиме, пока пользователь продолжает работать, затем извлеките диск для завершения установки без перезагрузки.
Шифрование
В своем интервью 2009 года Крис Мейсон заявил, что поддержка шифрования была запланирована для Btrfs. Тем временем обходным путем для объединения шифрования с Btrfs является использование механизма шифрования всего диска, такого как dm-crypt / LUKS на базовых устройствах и создание файловой системы Btrfs на верх этого слоя.
Поскольку команды SMART не проходят через уровень LUKS, RAID на основе Btrfs не может надежно работать поверх, так как любая обработка ошибок, требующая связи с диском, не удастся. На самом деле любой программный RAID должен иметь возможность передавать команды SMART на диск для надежной работы, и это может быть проблемой, поскольку ряд контроллеров SATA не обрабатывает SMART должным образом, особенно внешние корпуса, и даже внешние корпуса, которые это делают, должны убедитесь, что ядро и связанные с ним инструменты достаточно актуальны для правильного взаимодействия SMART с этим контроллером, а также для обеспечения прямого доступа Btrfs к дискам.
2020
В настоящее время разработчики работают над добавлением ключевой хеш, например HMAC (SHA256 ). Ключевой хеш - это шаг к шифрованию.
Проверка и восстановление
Системы Unix традиционно полагаются на программы "fsck " для проверки и восстановления файловых систем. Эта функция реализована с помощью программы btrfs check. Начиная с версии 4.0 эта функциональность считается относительно стабильной. Однако по состоянию на август 2017 года в документации по btrfs предлагается использовать его только после того, как попробовали другие методы восстановления.
Существует еще один инструмент с именем btrfs-restore, который можно использовать для восстанавливать файлы из не монтируемой файловой системы без изменения самой сломанной файловой системы (т. е. неразрушающим образом).
При нормальном использовании Btrfs в основном самовосстанавливается и может восстанавливаться из сломанных корневых деревьев во время монтирования благодаря выполнение периодических сбросов данных в постоянное хранилище, по умолчанию каждые 30 секунд. Таким образом, изолированные ошибки приведут к потере максимум 30 секунд изменений файловой системы при следующем монтировании. Этот период можно изменить, указав желаемое значение (в секундах) для параметра монтирования commit.
Design
В первоначальном предложении Охада Родеха на USENIX 2007 отмечалось, что B + деревья, которые широко используются в качестве структур данных на диске для баз данных, не могли эффективно разрешать создание моментальных снимков на основе копирования при записи, потому что его конечные узлы были связаны вместе: если лист был копируемым при записи, его братья, сестры и родители должны быть такими же, как и их братья и сестры, родители и так далее, пока не будет скопировано все дерево. Вместо этого он предложил модифицированное B-дерево (которое не имеет связи листьев) с refcount, связанным с каждым узлом дерева, но сохраненным в специальной свободной структуре карты, и определенными упрощениями для алгоритмы балансировки дерева, чтобы сделать их удобными для копирования при записи. В результате получилась бы структура данных, подходящая для высокопроизводительного объектного хранилища, которое могло бы выполнять моментальные снимки копирования при записи, сохраняя при этом хороший параллелизм.
Позднее в том же году в Oracle начал работу Крис Мейсон над созданием моментальных снимков. файловая система, которая будет использовать эту структуру данных почти исключительно - не только для метаданных и файловых данных, но также рекурсивно для отслеживания распределения пространства самих деревьев. Это позволило направлять все обходы и модификации через единый путь кода, в котором такие функции, как копирование при записи, контрольная сумма и зеркалирование, необходимо было реализовать только один раз, чтобы принести пользу всей файловой системе.
Btrfs структурированы как несколько слоев таких деревьев, использующих одну и ту же реализацию B-дерева. В деревьях хранятся общие элементы, отсортированные по 136-битному ключу. Первые 64 бита ключа представляют собой уникальный идентификатор объекта. Средние 8 бит - это поле типа элемента; его использование встроено в код как фильтр элементов припоиске в дереве. Объекты могут иметь несколько элементов разного типа. Остальные правые 64 бита используются в зависимости от типа. Таким образом, элементы для одного и того же объекта оказываются рядом друг с другом в дереве, отсортированные по типу. Выбирая значения правого ключа, функции также размещать элементы одного и того же типа в определенном порядке.
Узлы внутреннего дерева представляют собой просто плоские списки пар ключ-указатель, где указатель номер логического блока дочернего узла. Листовые узлы содержат ключи элементов, упакованные в переднюю часть узла, и данные элементов, упакованные в конец, причем два элемента растут друг к другу по мере заполнения листа.
Дерево файловой системы
Внутри каждого каталога, записанного как элементы каталога, значения правого ключа которых являются хешем CRC32C их имени файла. Их данные указывают собой ключ местоположения или ключ элемента inode, на который он указывает. Таким образом, элементы каталога могут действовать как индекс для поиска по пути к индексному узлу, но не используются для итерации, потому что они сортируются по их хешам, эффективно произвольно переставляя их. Это означает, что пользовательские приложения, создаваемые таким образом, создают больше дисковых поисковых систем между несмежными файлами - заметное снижение производительности в других файловых системах с каталогами с упорядоченным хешем, такими как ReiserFS, ext3 (с включенными Htree-индексами) и ext4, все из которых имеют хешированные файлы TEA. Чтобы избежать этого, каждая запись каталога имеет индекс каталога, значение правого ключа которого установлено равным счетчиком каталога, который увеличивается с каждой новой записью каталога. Таким образом, итерация по этому элементу возвращает записи примерно в том же порядке, в каком они хранятся на диске.
Файлы с жесткими ссылками в нескольких каталогах имеют несколько ссылочных элементов, по одному для каждого родительского каталога. Файлы с использованием жестких ссылок в одном каталоге упаковывают все имена файлов ссылок в один и тот же элемент ссылки. Это был недостаток дизайна, который ограничивал количество жестких ссылок на один и тот же каталог до того количества, которое могло уместиться в одном блоке дерева. (При размере блока по умолчанию 4 КиБ, средней длине имени файла 4 байта это будет меньше 350.) Приложения, которые интенсивно использовали несколько жестких ссылок на один каталог, такие как Позже были обнаружены ошибки git, GNUS, GMame и BackupPC после достижений этого предела. В конечном итоге ограничение было снято (и с октября 2012 года оно было объединено в ожидании выпуска в Linux 3.7) путем введения дополнительных справочных элементов для хранения имен файлов жестких ссылок.
Экстенты
Данные файла хранятся вне дерева в экстентах, которые предоставляют собой непрерывные серии дисковых блоков. Блоки экстентов по умолчанию имеют размер 4 КиБ, не имеют заголовков и содержат только (возможно, блокирующие) данные файла. В сжатых экстентах отдельные блоки не сжимаются отдельно; скорее, поток охватывает весь экстент.
Файлы элементов данных экстентов для экстентов, которые содержат их содержимое. Значение правой клавиши элемента - это смещение начального байта экстента. Это обеспечивает эффективный поиск в больших файлах с множеством экстентов, поскольку правильный экстент для любого заданного с ущербом может быть вычислен с помощью всего лишь одного поиска в дереве.
Моментальные снимки и клонированные файлы имеют общие экстенты. Когда небольшая часть такого большого экстента перезаписывается, в результате копирования при записи может быть создано три новых: маленький, перезаписанные данные, и два больших, с сохраненными данными по обе стороны от перезаписи. Чтобы избежать перезаписи немодифицированных данных, копирование при записи может вместо этого создать экстенты книжных концов или экстенты, которые являются просто фрагментами использования экстентов. Элементы данных экстента позволяют это сделать, включая смещение в отслеживаемый экстент: элементы для подставок для книг - это элементы с ненулевым смещением.
Если данные файла достаточно малы, чтобы поместиться внутри узла дерева, они вместо этого извлекается из дерева и сохраняется в элементах данных экстента. Каждый узел дерева хранится в своем собственном блоке дерева - единственном несжатом блоке с заголовком. Древовидный блок считается отдельно стоящим моноблочным экстентом.
Дерево распределения экстентов
Дерево распределения экстентов действует как карта распределения файлов экстентов системы. В отличие от других деревьев, элементы в этом дереве не имеют области пространства: их значения левого и правого ключей являются начальными смещениями и длинами регионов, которые они имеют.
Файловая система разделяет свое выделенное пространство на группы блоков, которые предоставляют собой области распределения различных размеров, которые последовательно чередуются между предпочтительными экстентами метаданных (узлы дерева) и экстентами данных (содержимое файла). По умолчанию соотношение данных к группам блоков метаданных составляет 1: 2. Они предназначены для работы распределителю блоков Орлова и группам блоков в ext3 в распределении файлов вместе и противодействии фрагментации, оставляя промежутки в распределении между группами. (Группы ext блоков3, однако, имеют фиксированные фиксированные местоположения, вычисленные на основе размера файловой системы, тогда как группы в Btrfs являются динамическими и размерными блоками по мере необходимости.) Каждая группа блоков связана с элементами группы блоков. Элементы Inode в дереве файловой системы включают ссылку на свою текущую группу блоков.
Элементы экстента содержат обратную ссылку на узел дерева или файл, занимающий этот экстент. Это экстентальный общий для снимков, может быть несколько обратных ссылок. Если обратных ссылок слишком много для размещения в элементах, они перетекают в отдельные элементы ссылок на данные экстента. Узлы дерева, в свою очередь, имеют обратные ссылки на нихся в них деревья. Это позволяет найти какие экстенты или узлы дерева находятся в любой области пространства, выполнив поиск диапазона B-дерева по паре смещений, заключенных в скобки этой области, а следуя обратным ссылкам. Для перемещения это позволяет эффективно перемещаться в перемещенных блоках, чтобы быстро находить и исправлять все нисходящие ссылки на эти блоки без необходимости обхода всей файловой системы. Это, в свою очередь, позволяет файловой системе эффективно сжимать, переносить и дефрагментировать свое хранилище онлайн.
Дерево распределения экстентов, как и все другие деревья в файловой системе, является копией при записи. Таким образом, записи в файловой системе могут вызвать каскад, в результате которого измененные узлы дерева и данные файла вызывают выделение новых экстентов, вызывая изменение самого дерева экстентов. Чтобы избежать создания цикла обратной связи, узлы дерева экстентов, которые все еще находятся в памяти, но еще не зафиксированы на диске, могут быть обновлены на месте, чтобы отразить новые экстенты с копированием при записи.
Теоретически дерево распределения экстентов делает ненужным обычную битовую карту свободного пространства, поскольку дерево распределения экстентов действует как версия B-дерева для BSP-дерева. На практике, однако, в памяти красно-черное дерево растровых изображений размером страницы используется для ускорения выделения. Эти растровые изображения сохраняются на диске (начиная с Linux 2.6.37 с помощью программы монтирования space_cache) в виде специальных экстентов, которые не подлежат контрольной сумме и копированию при записи. Элементы экстентов, отслеживающие эти экстенты, хранятся в корневом дереве.
Дерево контрольных сумм и очистка
Контрольные суммы CRC-32C вычисляются как для данных, так и для метаданных и сохраняются как элементы контрольной суммы в дереве контрольных сумм. Существует место для 256 бит контрольных сумм метаданных и до целого листового блока (примерно 4 КБ или более) для контрольных сумм данных. В запланированные дополнительные параметры алгоритма контрольной суммы.
Существует один элемент контрольной суммы на непрерывный прогон выделенных блоков, при этом контрольные суммы для каждого блока последовательно упаковываются в данные элемента. Если контрольных сумм больше, чем может поместиться, они перетекают вправо в другой элемент контрольной суммы на новом листе. Она сначала пытается получить (или создать) хорошую копию этого блока с другого устройства - если используются методы внутреннего зеркалирования или RAID.
Btrfs может инициировать онлайн-проверку всей файловой системы, запустив задание очистки файловой системы, которое выполняется в фоновом режиме. Задание очистки сканирует всю файловую систему на предметности и автоматически пытается сообщать и восстанавливать любые сбойные блоки, которые обнаруживает по пути.
Дерево журнала
fsync - это запрос на немедленную фиксацию измененных данных в стабильном хранилище. Рабочие нагрузки с большим количеством fsync (например, база данных или виртуальная машина, на которой интенсивно работает fsync в ОС), запускает большое количество избыточных операций ввода-вывода при записи, заставляя файловую система многократно копировать -при записи и сбрасывать часто изменяемые части деревьев на хранение. Чтобы избежать этого, создается временное дерево журнала для каждого субтома в journal запускаемое fsync копирование при записи. Деревья журналов являются самодостаточными, отслеживая свои собственные размеры и сохраняя свои собственные элементы контрольной суммы. При повторном подключении происходит их последующая фиксация полного цикла.
Дерево фрагментов и устройств
Блочные устройства делятся на физические фрагменты размером 256 МБ или более. Физические блоки на нескольких устройствах могут быть зеркально отражены или разделены вместе в один логический блок. Эти логические блоки объединены в единое логическое адресное пространство, использует остальную файловую систему.
Дерево фрагментов отслеживает это, сохраняет каждое устройство в нем как элемент устройства, а логические фрагменты - как элементы карты фрагментов, которые обеспечивают прямое отображение логических адресов к физическим, сохраняя их повреждение в правых 64 битах их ключ. Элементы карты могут быть одного из нескольких типов:
одиночный
1 логический к 1 физическому фрагменту
dup
1 логический фрагмент к 2 физическому фрагменту в 1 блоке устройства
raid0
N логических блоков на N≥2 физических блоков на N≥2 блочных устройств
raid1
1 логический блок на 2 физических блока на 2 из N≥2 блочных устройств, в отличие от обычного 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, однако многие блочные устройства все еще имеют свободный sp ace при выделении фрагмента. Если N недостаточно велик для выбранного зеркального отображения / отображения, тогда в файловой системе фактически не хватает места.
Дерево устройств является инверсией дерева фрагментов и имеет элементы экстентов устройства, которые обеспечивают обратное отображение диапазонов байтов блочных устройств обратно в логические фрагменты путем сохранения номера устройства в левом 64-битном и физическое смещение в правых 64 битах ключа.
Эти два дерева вместе позволяют Btrfs увеличивать, уменьшать и даже изменять уровни RAID без размонтирования, поскольку они позволяют эффективно находить блоки, затронутые операциями сжатия / перемещения, а затем перемещать их содержимое на лету.
Файловой системе, фрагментам и устройствам назначается универсальный уникальный идентификатор (UUID). Заголовок каждого узла дерева содержит как UUID содержащего его фрагмента, так и UUID файловой системы. Деревья фрагментов и устройств относятся к устройствам и фрагментам с UUID. В файловых системах с одним блочным устройством «dup» также является профилем по умолчанию для метаданных. Все это предназначено для повышения шансов на успешное восстановление данных в случае ошибок носителя ).
Деревья перемещения
Операции дефрагментации, сжатия и ребалансировки требуют перемещения экстентов. Однако выполнение простого копирования и записи перемещаемого экстента нарушит совместное использование снимков и займет дисковое пространство. Чтобы сохранить совместное использование, используется алгоритм обновления и замены со специальным деревом перемещения, служащим временным пространством для затронутых метаданных. Перемещаемый экстент сначала копируется в место назначения. Затем, следуя обратным ссылкам вверх по дереву файловой системы затронутого субтома, метаданные, указывающие на старый экстент, постепенно обновляются, чтобы указывать на новый; любые недавно обновленные элементы сохраняются в дереве перемещения. После завершения обновления элементы в дереве перемещения меняются местами со своими аналогами в затронутом подобтоме, а дерево перемещения отбрасывается.
Суперблок
Все деревья файловой системы, включая фрагмент само дерево - хранятся в кусках, что создает потенциальную проблему начальной загрузки при монтировании файловой системы. Для начальной загрузки в монтирование, список физических адресов блоков, принадлежащих чанку, и корневые деревья должны быть сохранены в суперблоке.
Зеркала суперблока хранятся в фиксированных местах: по 64 КБ на каждое блочное устройство с дополнительными копиями размером 64, 256 и 1 ПиБ. При обновлении зеркала суперблока увеличивается номер его поколения. Во время монтирования используется копия с наивысшим номером поколения. Все зеркала суперблока обновляются в тандеме, за исключением режима SSD, в котором обновления между зеркалами чередуются для обеспечения некоторого выравнивания износа.
HAMMER - файловая система DragonFly BSD, в которой используются B-деревья в сочетании с контрольными суммами в качестве меры противодействия повреждению данных
