Btrfs (произносится как «better F S», [9] «butter F S», [13] [14] «b-tree F S», [14] или BTRFS) — это формат компьютерного хранения данных, который объединяет файловую систему , основанную на принципе копирования при записи (COW), с логическим менеджером томов (отличным от LVM в Linux ), разработанными совместно. Он был создан Крисом Мейсоном в 2007 году [15] для использования в Linux , а с ноября 2013 года формат файловой системы на диске был объявлен стабильным в ядре Linux . [16]
Btrfs призвана решить проблему отсутствия пулов , снимков , контрольных сумм и интегрального охвата нескольких устройств в файловых системах Linux . [9] Мейсон, главный автор Btrfs, заявил, что его цель — «позволить [Linux] масштабироваться для хранилища, которое будет доступно. Масштабирование — это не только адресация хранилища, но и возможность администрировать и управлять им с помощью понятного интерфейса, который позволяет людям видеть, что используется, и делает его более надежным». [17]
Основная структура данных Btrfs — B-дерево с функцией копирования при записи — была первоначально предложена исследователем IBM Охадом Родехом на конференции USENIX в 2007 году. [18] Мейсон, инженер, работавший в то время над ReiserFS для SUSE , присоединился к Oracle в том же году и начал работу над новой файловой системой на основе этих B-деревьев. [19]
В 2008 году главный разработчик файловых систем ext3 и ext4 Теодор Цо заявил, что хотя ext4 имеет улучшенные функции, это не является крупным шагом вперед; она использует старую технологию и является временной мерой. Цо сказал, что Btrfs — лучшее направление, поскольку «она предлагает улучшения в масштабируемости, надежности и простоте управления». [20] Btrfs также имеет «ряд тех же идей дизайна, что и reiser3 / 4 ». [21]
Btrfs 1.0 с финализированным форматом на диске изначально планировалось выпустить в конце 2008 года [22] и окончательно было принято в основную ветку ядра Linux в 2009 году [23]. Несколько дистрибутивов Linux начали предлагать Btrfs в качестве экспериментального выбора корневой файловой системы во время установки. [24] [25] [26]
В июле 2011 года функции автоматической дефрагментации и очистки Btrfs были объединены в версию 3.0 основной ветки ядра Linux . [27] Помимо Мейсона в Oracle, Мяо Се из Fujitsu внес вклад в улучшение производительности. [28] В июне 2012 года Мейсон покинул Oracle ради Fusion-io , которую он покинул год спустя вместе с Йозефом Бачиком, чтобы присоединиться к Facebook . Работая в обеих компаниях, Мейсон продолжал работать над Btrfs. [29] [19]
В 2012 году два дистрибутива Linux перевели Btrfs из экспериментального в производственный или поддерживаемый статус: Oracle Linux в марте [30] , а затем SUSE Linux Enterprise в августе [31] .
В 2015 году Btrfs была принята в качестве файловой системы по умолчанию для SUSE Linux Enterprise Server (SLE) 12. [32]
В августе 2017 года Red Hat объявила в примечаниях к выпуску Red Hat Enterprise Linux (RHEL) 7.4, что больше не планирует переводить Btrfs в полностью поддерживаемую функцию (она была включена в качестве «технологической предварительной версии» с момента выхода RHEL 6 beta), отметив, что она останется доступной в серии выпусков RHEL 7. [33] Btrfs была удалена из RHEL 8 в мае 2019 года . [34] RHEL перешла с ext4 в RHEL 6 на XFS в RHEL 7. [35]
В 2020 году Btrfs была выбрана в качестве файловой системы по умолчанию для Fedora 33 для настольных версий. [36]
Начиная с версии 5.0 ядра Linux, Btrfs реализует следующие функции: [37] [38]
cp --reflink <source file> <destination file>[44]Btrfs обеспечивает операцию клонирования , которая атомарно создает моментальный снимок файла с функцией копирования при записи . Такие клонированные файлы иногда называют рефлинками , в свете предлагаемого связанного системного вызова ядра Linux . [55]
При клонировании файловая система не создает новую ссылку, указывающую на существующий inode ; вместо этого она создает новый inode, который изначально разделяет те же блоки диска с исходным файлом. В результате клонирование работает только в пределах границ той же файловой системы Btrfs, но с версии 3.6 ядра Linux оно может пересекать границы подтомов при определенных обстоятельствах. [56] [57] Фактические блоки данных не дублируются; в то же время, из-за природы копирования при записи (CoW) Btrfs, изменения любого из клонированных файлов не видны в исходном файле и наоборот. [58]
Клонирование не следует путать с жесткими ссылками , которые являются записями каталога, которые связывают несколько имен файлов с одним файлом. В то время как жесткие ссылки могут восприниматься как разные имена для одного и того же файла, клонирование в Btrfs предоставляет независимые файлы, которые изначально совместно используют все свои дисковые блоки. [58] [59]
Поддержка этой функции Btrfs была добавлена в версии 7.5 GNU coreutils с помощью --reflinkопции команды cp. [60] [61]
В дополнение к клонированию данных ( FICLONE ), Btrfs также поддерживает внеполосную дедупликацию через FIDEDUPERANGE . Эта функциональность позволяет двум файлам с (даже частично) идентичными данными совместно использовать хранилище. [62] [10]
Подтом Btrfs можно рассматривать как отдельное пространство имен файлов POSIX , монтируемое отдельно путем передачи subvolили subvolidпараметров утилите . К нему также можно получить доступ, смонтировав подтом верхнего уровня, в этом случае подтома видны и доступны как его подкаталоги. [63]
Подтома могут быть созданы в любом месте в иерархии файловой системы, и они также могут быть вложенными. Вложенные подтома отображаются как подкаталоги внутри своих родительских подтомов, аналогично тому, как подтом верхнего уровня представляет свои подтома как подкаталоги. Удаление подтома невозможно, пока не будут удалены все подтома ниже его в иерархии вложенности; в результате подтома верхнего уровня не могут быть удалены. [64]
Любая файловая система Btrfs всегда имеет подтом по умолчанию, который изначально устанавливается как подтом верхнего уровня и монтируется по умолчанию, если не передана опция выбора подтома mount. Подтом по умолчанию можно изменить по мере необходимости. [64]
Снимок Btrfs — это подтом, который делится своими данными (и метаданными) с каким-либо другим подтомом, используя возможности копирования при записи Btrfs, и изменения в снимке не видны в исходном подтоме. После создания записываемого снимка его можно рассматривать как альтернативную версию исходной файловой системы. Например, чтобы вернуться к снимку, необходимо размонтировать измененный исходный подтом и смонтировать снимок на его место. В этот момент исходный подтом также может быть удален. [63]
Природа копирования при записи (CoW) Btrfs означает, что моментальные снимки создаются быстро, при этом изначально занимая очень мало места на диске. Поскольку моментальный снимок является подтомом, создание вложенных моментальных снимков также возможно. Создание моментальных снимков подтома не является рекурсивным процессом; таким образом, если создается моментальный снимок подтома, каждый подтом или моментальный снимок, который уже содержится в подтоме, сопоставляется с пустым каталогом с тем же именем внутри моментального снимка. [63] [64]
Снимки каталога невозможны, так как снимки могут быть только у подтомов. Однако есть обходной путь, который включает в себя распространение ссылок по подтомам: создается новый подтом, содержащий перекрестные ссылки на содержимое целевого каталога. Имея это в наличии, можно создать снимок этого нового тома. [56]
Подтом в Btrfs сильно отличается от традиционного логического тома Logical Volume Manager (LVM). В LVM логический том является отдельным блочным устройством , в то время как подтом Btrfs не является таковым, и его нельзя обрабатывать или использовать таким образом. [63] Создание снимков dd или LVM для btrfs приводит к потере данных, если оригинал или копия монтируются, когда оба находятся на одном компьютере. [65]
Учитывая любую пару подтомов (или снимков), Btrfs может сгенерировать двоичный diff между ними (используя btrfs sendкоманду), который может быть воспроизведен позже (используя btrfs receive), возможно, в другой файловой системе Btrfs. Функция отправки-получения эффективно создает (и применяет) набор изменений данных, необходимых для преобразования одного подтома в другой. [49] [66]
Функцию отправки/получения можно использовать с регулярно запланированными моментальными снимками для реализации простой формы репликации файловой системы или для выполнения инкрементного резервного копирования . [49] [66]
Группа квот (или qgroup ) устанавливает верхний предел пространства, которое может потреблять подтом или снимок. Новый снимок изначально не потребляет квоту, поскольку его данные используются совместно с его родителем, но впоследствии взимается плата за новые файлы и операции копирования при записи для существующих файлов. Когда квоты активны, группа квот автоматически создается с каждым новым подтомом или снимком. Эти начальные группы квот являются строительными блоками, которые можно сгруппировать (с помощью btrfs qgroupкоманды) в иерархии для реализации пулов квот. [51]
Группы квот применяются только к подтомам и снимкам, в то время как принудительное применение квот для отдельных подкаталогов, пользователей или групп пользователей невозможно. Однако возможны обходные пути с использованием разных подтомов для всех пользователей или групп пользователей, которым требуется принудительное применение квоты.
В результате того, что в фиксированных местах закреплено очень мало метаданных, Btrfs может деформироваться, чтобы соответствовать необычным пространственным макетам внутренних устройств хранения. btrfs-convertИнструмент использует эту способность для выполнения преобразования на месте файловой системы ext2/3/4 или ReiserFS , вложив эквивалентные метаданные Btrfs в ее нераспределенное пространство, сохраняя при этом неизмененную копию исходной файловой системы. [67]
Преобразование включает в себя создание копии всех метаданных ext2/3/4, в то время как файлы Btrfs просто указывают на те же блоки, которые используются файлами ext2/3/4. Это делает большую часть блоков общими для двух файловых систем до того, как преобразование станет постоянным. Благодаря природе копирования при записи Btrfs, исходные версии блоков данных файла сохраняются во время всех изменений файла. Пока преобразование не станет постоянным, только блоки, которые были помечены как свободные в ext2/3/4, используются для хранения новых изменений Btrfs, что означает, что преобразование может быть отменено в любое время (хотя это сотрет любые изменения, внесенные после преобразования в Btrfs). [67]
Все преобразованные файлы доступны и доступны для записи в подтоме по умолчанию Btrfs. Разреженный файл, содержащий все ссылки на исходную файловую систему ext2/3/4, создается в отдельном подтоме, который монтируется сам по себе как образ диска только для чтения, что позволяет получать доступ как к исходной, так и к преобразованной файловой системе одновременно. Удаление этого разреженного файла освобождает место и делает преобразование постоянным. [67]
В версиях 4.x основного ядра Linux преобразование ext3/4 на месте считалось непроверенным и редко использовалось. [67] Однако эта функция была переписана с нуля в 2016 году для btrfs-progsверсии 4.6. [47] и с тех пор считается стабильной.
Преобразование на месте из ReiserFS было представлено в сентябре 2017 года с ядром 4.13. [68]
При создании новой Btrfs существующая Btrfs может использоваться как файловая система «seed» только для чтения. [69] Новая файловая система затем будет действовать как наложение копирования-при-записи на seed, как форма монтирования объединения . Seed может быть позже отсоединен от Btrfs, в этот момент ребалансировщик просто скопирует все данные seed, на которые все еще ссылается новая файловая система перед отсоединением. Мейсон предположил, что это может быть полезно для установщика Live CD , который может загрузиться с Btrfs seed только для чтения на оптическом диске, перебалансировать себя на целевой раздел на установочном диске в фоновом режиме, пока пользователь продолжает работать, а затем извлечь диск, чтобы завершить установку без перезагрузки. [70]
В своем интервью 2009 года Мейсон заявил, что поддержка шифрования запланирована для Btrfs. [71] В то же время, обходным путем для объединения шифрования с Btrfs является использование механизма полного шифрования диска, такого как dm-crypt / LUKS, на базовых устройствах и создание файловой системы Btrfs поверх этого слоя.
По состоянию на 2020 год [обновлять]разработчики работали над добавлением хэш-функции с ключом, например HMAC ( SHA256 ). [72]
Системы Unix традиционно полагаются на программы " fsck " для проверки и восстановления файловых систем. Эта функциональность реализована через btrfs checkпрограмму. Начиная с версии 4.0 эта функциональность считается относительно стабильной. Однако по состоянию на декабрь 2022 года документация btrfs рекомендует --repairиспользовать эту опцию только в том случае, если вас посоветовал "разработчик или опытный пользователь". [73] По состоянию на август 2022 года документация SLE рекомендует использовать Live CD, выполнять резервное копирование и использовать опцию восстановления только в крайнем случае. [74]
Существует еще один инструмент, называемый btrfs-restore, который можно использовать для восстановления файлов из немонтируемой файловой системы, не изменяя саму сломанную файловую систему (т.е. неразрушающим образом). [75] [76]
При обычном использовании Btrfs в основном самовосстанавливается и может восстанавливаться после поломки корневых деревьев во время монтирования, благодаря периодическим сбросам данных в постоянное хранилище, по умолчанию каждые 30 секунд. Таким образом, отдельные ошибки приведут к потере максимум 30 секунд изменений файловой системы при следующем монтировании. [77] Этот период можно изменить, указав желаемое значение (в секундах) с помощью commitпараметра монтирования. [78] [79]
Первоначальное предложение Охада Родеха на USENIX 2007 отметило, что деревья B+ , которые широко используются в качестве структур данных на диске для баз данных, не могут эффективно разрешать моментальные снимки на основе копирования при записи, поскольку их листовые узлы связаны друг с другом: если лист копируется при записи, его братья и сестры и родители должны быть также скопированы, как и их братья и сестры и родители и так далее, пока не будет скопировано все дерево. Вместо этого он предложил модифицированное B-дерево (которое не имеет связи листьев), с refcount, связанным с каждым узлом дерева, но хранящимся в специальной свободной структуре карты и определенными послаблениями в алгоритмах балансировки дерева, чтобы сделать их дружественными к копированию при записи. Результатом будет структура данных, подходящая для высокопроизводительного объектного хранилища, которое может выполнять моментальные снимки копирования при записи, сохраняя при этом хорошую параллельность . [18]
В Oracle позднее в том же году Мейсон начал работу над файловой системой с возможностью моментальных снимков, которая использовала бы эту структуру данных почти исключительно — не только для метаданных и данных файлов, но и рекурсивно для отслеживания распределения пространства самих деревьев. Это позволило направить все обходы и изменения через единый путь кода, в отношении которого такие функции, как копирование при записи, контрольное суммирование и зеркалирование, требовалось реализовать только один раз, чтобы принести пользу всей файловой системе. [80]
Btrfs структурирована как несколько слоев таких деревьев, все из которых используют одну и ту же реализацию B-дерева. Деревья хранят общие элементы , отсортированные по 136-битному ключу. Наиболее значимые 64 бита ключа являются уникальным идентификатором объекта . Средние восемь бит являются полем типа элемента: его использование жестко запрограммировано в коде как фильтр элементов при поиске по дереву. Объекты могут иметь несколько элементов различных типов. Оставшиеся (наименее значимые) 64 бита используются способами, специфичными для типа. Таким образом, элементы для одного и того же объекта оказываются рядом друг с другом в дереве, сгруппированными по типу. Выбирая определенные значения ключей, объекты могут дополнительно размещать элементы одного и того же типа в определенном порядке. [80] [4]
Внутренние узлы дерева — это просто плоские списки пар ключ-указатель, где указатель — это логический номер блока дочернего узла. Листовые узлы содержат ключи элементов, упакованные в начало узла, и данные элементов, упакованные в конец, причем они растут друг к другу по мере заполнения листа. [80]
В каждом каталоге записи каталога отображаются как элементы каталога , чьи наименее значимые биты значений ключей являются хешем CRC32C их имени файла. Их данные являются ключом местоположения или ключом элемента inode , на который он указывает. Элементы каталога вместе могут, таким образом, действовать как индекс для поиска пути к inode, но не используются для итерации, поскольку они сортируются по своему хешу, фактически случайным образом переставляя их. Это означает, что пользовательские приложения, итерирующие и открывающие файлы в большом каталоге, таким образом, будут генерировать гораздо больше дисковых поисков между несмежными файлами — заметная утечка производительности в других файловых системах с упорядоченными по хэшу каталогами, такими как ReiserFS , [81] ext3 (с включенными индексами Htree [82] ) и ext4, все из которых имеют имена файлов, хэшированные с помощью TEA . Чтобы избежать этого, каждая запись каталога имеет элемент индекса каталога , чье значение ключа элемента установлено на счетчик для каждого каталога, который увеличивается с каждой новой записью каталога. Таким образом, итерация по этим элементам индекса возвращает записи примерно в том же порядке, в котором они хранятся на диске.
Файлы с жесткими ссылками в нескольких каталогах имеют несколько элементов ссылок, по одному для каждого родительского каталога. Файлы с несколькими жесткими ссылками в одном каталоге упаковывают все имена файлов ссылок в один элемент ссылки. Это был недостаток дизайна, который ограничивал количество жестких ссылок одного каталога до того количества, которое могло поместиться в одном блоке дерева. (При размере блока по умолчанию 4 КиБ, средней длине имени файла 8 байт и заголовке имени файла 4 байта это было бы меньше 350.) Приложения, которые интенсивно использовали несколько жестких ссылок одного каталога, такие как git , GNUS , GMame и BackupPC , как было замечено, терпели неудачу при достижении этого предела. [83] В конечном итоге ограничение было снято [84] (и по состоянию на октябрь 2012 года было объединено [85] в ожидании выпуска в Linux 3.7) путем введения дополнительных расширенных элементов ссылок для хранения имен файлов жестких ссылок, которые в противном случае не помещались.
Файловые данные хранятся вне дерева в экстентах , которые представляют собой непрерывные прогоны дисковых блоков данных. Блоки экстентов по умолчанию имеют размер 4 КиБ, не имеют заголовков и содержат только (возможно, сжатые) данные файлов. В сжатых экстентах отдельные блоки не сжимаются по отдельности; вместо этого поток сжатия охватывает весь экстент.
Файлы имеют элементы данных экстента для отслеживания экстентов, которые содержат их содержимое. Ключевое значение элемента — это начальное смещение байта экстента. Это обеспечивает эффективный поиск в больших файлах с большим количеством экстентов, поскольку правильный экстент для любого заданного смещения файла может быть вычислен всего одним поиском по дереву.
Снимки и клонированные файлы разделяют экстенты. Когда небольшая часть такого большого экстента перезаписывается, результирующее копирование при записи может создать три новых экстента: небольшой, содержащий перезаписанные данные, и два больших с немодифицированными данными по обе стороны от перезаписи. Чтобы избежать необходимости переписывать немодифицированные данные, копирование при записи может вместо этого создавать экстенты bookend или экстенты, которые являются просто срезами существующих экстентов. Элементы данных экстента позволяют это сделать, включая смещение в экстент, который они отслеживают: элементы для bookend — это те, у которых смещения не равны нулю. [4]
Дерево распределения экстентов действует как карта распределения для файловой системы. В отличие от других деревьев, элементы в этом дереве не имеют идентификаторов объектов. Они представляют регионы пространства: их ключевые значения содержат начальные смещения и длины регионов, которые они представляют.
Файловая система делит свое выделенное пространство на группы блоков , которые представляют собой области распределения переменного размера, которые попеременно предпочитают экстенты метаданных (узлы дерева) и экстенты данных (содержимое файла). Соотношение данных к группам блоков метаданных по умолчанию составляет 1:2. Они предназначены для использования концепций распределителя блоков Орлова для совместного выделения связанных файлов и предотвращения фрагментации путем оставления свободного пространства между группами. (Однако группы блоков Ext3 имеют фиксированные местоположения, вычисляемые на основе размера файловой системы, тогда как в Btrfs они являются динамическими и создаются по мере необходимости.) Каждая группа блоков связана с элементом группы блоков . Элементы inode в дереве файловой системы включают ссылку на свою текущую группу блоков. [4]
Элементы экстента содержат обратную ссылку на узел дерева или файл, занимающий этот экстент. Может быть несколько обратных ссылок, если экстент является общим для снимков. Если обратных ссылок слишком много для размещения в элементе, они выливаются в отдельные элементы ссылок на экстентные данные . Узлы дерева, в свою очередь, имеют обратные ссылки на содержащие их деревья. Это позволяет находить, какие экстенты или узлы дерева находятся в любой области пространства, выполняя поиск диапазона B-дерева по паре смещений, охватывающих эту область, а затем следуя обратным ссылкам. Для перемещения данных это позволяет эффективно проходить вверх от перемещенных блоков, чтобы быстро находить и исправлять все нисходящие ссылки на эти блоки, без необходимости сканирования всей файловой системы. Это, в свою очередь, позволяет файловой системе эффективно сжимать, переносить и дефрагментировать свое хранилище в режиме онлайн.
Дерево распределения экстентов, как и все остальные деревья в файловой системе, является копируемым при записи. Записи в файловую систему могут, таким образом, вызвать каскад, в котором измененные узлы дерева и данные файла приводят к выделению новых экстентов, что приводит к изменению самого дерева экстентов. Чтобы избежать создания петли обратной связи , узлы дерева экстентов, которые все еще находятся в памяти, но еще не зафиксированы на диске, могут быть обновлены на месте для отражения новых копируемых при записи экстентов.
Теоретически дерево распределения экстентов делает обычную битовую карту свободного пространства ненужной, поскольку дерево распределения экстентов действует как версия B-дерева дерева BSP . Однако на практике для ускорения распределения используется красно-черное дерево битовых карт размером со страницу в памяти . Эти битовые карты сохраняются на диске (начиная с Linux 2.6.37, через space_cacheопцию монтирования [86] ) как специальные экстенты, которые освобождены от контрольной суммы и копирования при записи.
Контрольные суммы CRC-32C вычисляются как для данных, так и для метаданных и хранятся как элементы контрольной суммы в дереве контрольных сумм . Имеется место для 256 бит контрольных сумм метаданных и до полного узла (примерно 4 КБ или более) для контрольных сумм данных. Btrfs имеет положения для дополнительных алгоритмов контрольных сумм, которые будут добавлены в будущих версиях файловой системы. [37] [87]
На непрерывный прогон выделенных блоков приходится один элемент контрольной суммы, при этом контрольные суммы по блокам упакованы в данные элемента от начала до конца. Если контрольных сумм больше, чем может поместиться, они переносятся в другой элемент контрольной суммы на новом листе. Если файловая система обнаруживает несоответствие контрольной суммы при чтении блока, она сначала пытается получить (или создать) хорошую копию этого блока с другого устройства — если используются методы внутреннего зеркалирования или RAID. [88] [89]
Btrfs может инициировать онлайн-проверку всей файловой системы, запустив задание по очистке файловой системы, которое выполняется в фоновом режиме. Задание по очистке сканирует всю файловую систему на целостность и автоматически пытается сообщить и исправить любые плохие блоки, которые он находит по пути. [88] [90]
Запрос fsync немедленно фиксирует измененные данные в стабильном хранилище. Нагрузки с высокой нагрузкой fsync (например, база данных или виртуальная машина , работающая ОС которой часто выполняет fsync ) потенциально могут генерировать большое количество избыточных операций ввода-вывода записи, заставляя файловую систему многократно копировать при записи и сбрасывать часто изменяемые части деревьев в хранилище. Чтобы избежать этого, создается временное дерево журнала для каждого подтома для ведения журнала копий, запускаемых fsync при записи. Деревья журналов являются автономными, отслеживают свои собственные экстенты и сохраняют собственные элементы контрольной суммы. Их элементы воспроизводятся и удаляются при следующей полной фиксации дерева или (если произошел сбой системы) при следующем перемонтировании.
Блочные устройства делятся на физические фрагменты размером 1 ГиБ для данных и 256 МиБ для метаданных. [91] Физические фрагменты на нескольких устройствах могут быть зеркально отражены или объединены в один логический фрагмент . Эти логические фрагменты объединяются в единое логическое адресное пространство, которое использует остальная часть файловой системы.
Дерево фрагментов отслеживает это, сохраняя каждое устройство в нем как элемент устройства и логические фрагменты как элементы карты фрагментов , которые обеспечивают прямое отображение от логических к физическим адресам, сохраняя их смещения в младших 64 битах их ключа. Элементы карты фрагментов могут быть одного из нескольких различных типов:
N — это число блочных устройств, на которых все еще есть свободное место при выделении фрагмента. Если N недостаточно для выбранного зеркалирования/отображения, то файловая система фактически исчерпала свое пространство.
Операции дефрагментации, сжатия и перебалансировки требуют перемещения экстентов. Однако выполнение простого копирования при записи перемещаемого экстента нарушит совместное использование между снимками и израсходует дисковое пространство. Для сохранения совместного использования используется алгоритм обновления и замены, при этом специальное дерево перемещения служит в качестве рабочего пространства для затронутых метаданных. Перемещаемый экстент сначала копируется в место назначения. Затем, следуя обратным ссылкам вверх по дереву файловой системы затронутого подтома, метаданные, указывающие на старый экстент, постепенно обновляются, чтобы указывать на новый; любые недавно обновленные элементы сохраняются в дереве перемещения. После завершения обновления элементы в дереве перемещения меняются местами со своими аналогами в затронутом подтоме, а дерево перемещения отбрасывается. [93]
Все деревья файловой системы, включая само дерево фрагментов, хранятся в фрагментах, что создает потенциальную проблему самозагрузки при монтировании файловой системы. Для самозагрузки в монтирование список физических адресов фрагментов, принадлежащих фрагменту и корневым деревьям, хранится в суперблоке . [94]
Зеркала суперблоков хранятся в фиксированных местах: [95] 64 КиБ в каждом блочном устройстве, с дополнительными копиями в 64 МиБ, 256 ГиБ и 1 ПиБ. Когда зеркало суперблока обновляется, его номер поколения увеличивается. Во время монтирования используется копия с самым высоким номером поколения. Все зеркала суперблоков обновляются в тандеме, за исключением режима SSD , который чередует обновления между зеркалами, чтобы обеспечить некоторое выравнивание износа .
CONFIG_LBDопция конфигурации ядра (доступная с версии ядра 2.6.x ), снимающая эти ограничения ядра. [103] [104]Это называется Butter FS или B-tree FS, но все крутые ребята говорят Butter FS
Мейсон — разработчик-основатель btrfs, над которой он начал работать в 2007 году, работая в Oracle. Это заставляет многих людей думать, что btrfs — проект Oracle, но это не так. Проект принадлежал Мейсону, а не его работодателю, и по сей день он остается общественным проектом, не обремененным корпоративной собственностью.
добавлена поддержка файловых систем ext4 и Btrfs...
будущих выпусках мы планируем добавить онлайн-fsck, дедупликацию, шифрование и другие функции, которые долгое время были в списках пожеланий администраторов.
Начиная с DSM 6.0, тома данных могут быть отформатированы как Btrfs
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}
