Btrfs (произносится как «better FS», [9] «butter FS», [13] [14] «b-tree FS», [14] или BTRFS) — это компьютерный формат хранения данных, сочетающий в себе файловую систему на основе копии. Принцип -on-write (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), отметив, что он останется доступным в серии выпусков 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]
При клонировании файловая система не создает новую ссылку, указывающую на существующий индексный дескриптор ; вместо этого он создает новый индексный дескриптор, который изначально использует те же дисковые блоки, что и исходный файл. В результате клонирование работает только в пределах одной файловой системы Btrfs, но начиная с версии 3.6 ядра Linux при определенных обстоятельствах может выходить за границы подтомов. [56] [57] Фактические блоки данных не дублируются; в то же время из-за особенностей Btrfs копирования при записи (CoW) изменения любого из клонированных файлов не видны в исходном файле, и наоборот. [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 сильно отличается от традиционного логического тома диспетчера логических томов (LVM). В LVM логический том представляет собой отдельное блочное устройство , а субтом Btrfs — нет, и с ним нельзя обращаться или использовать таким образом. [63] Создание снимков btrfs в формате dd или LVM приводит к потере данных, если оригинал или копия монтируются, когда оба находятся на одном компьютере. [65]
Учитывая любую пару субтомов (или снимков), Btrfs может генерировать двоичную разницу между ними (с помощью 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 можно использовать как начальную файловую систему только для чтения. [69] Новая файловая система затем будет действовать как наложение копирования при записи на начальное число, как форма монтирования объединения . Позднее начальное число можно отсоединить от Btrfs, после чего ребалансировщик просто скопирует любые исходные данные, на которые все еще ссылается новая файловая система, перед отсоединением. Мейсон предположил, что это может быть полезно для установщика Live CD , который может загружаться с начального числа Btrfs только для чтения на оптическом диске, перебалансировать себя в целевой раздел на установочном диске в фоновом режиме, пока пользователь продолжает работать, а затем извлечь диск для завершения установки без перезагрузки. [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-дерево (которое не имеет связей между листьями) со счетчиком ссылок , связанным с каждым узлом дерева, но хранящимся в специальной свободной структуре карты, и с некоторыми послаблениями в алгоритмах балансировки дерева, чтобы сделать их удобными для копирования при записи. . Результатом будет структура данных, подходящая для высокопроизводительного хранилища объектов, которое сможет выполнять снимки с копированием при записи, сохраняя при этом хороший параллелизм . [18]
Позже в том же году Мейсон в Oracle начал работу над файловой системой с возможностью создания моментальных снимков, которая будет использовать почти исключительно эту структуру данных — не только для метаданных и файловых данных, но также рекурсивно для отслеживания распределения пространства самих деревьев. Это позволило провести все обходы и модификации по одному пути кода, а такие функции, как копирование при записи, контрольное суммирование и зеркалирование, нужно было реализовать только один раз, чтобы принести пользу всей файловой системе. [80]
Btrfs структурирован как несколько уровней таких деревьев, использующих одну и ту же реализацию B-дерева. В деревьях хранятся общие элементы , отсортированные по 136-битному ключу. Старшие 64 бита ключа представляют собой уникальный идентификатор объекта . Средние восемь битов представляют собой поле типа элемента: его использование жестко запрограммировано в коде в качестве фильтра элемента при поиске в дереве. Объекты могут иметь несколько элементов разных типов. Остальные (наименее значимые) 64 бита используются в зависимости от типа. Таким образом, элементы одного и того же объекта оказываются рядом друг с другом в дереве, сгруппированные по типу. Выбирая определенные значения ключей, объекты могут дополнительно размещать элементы одного типа в определенном порядке. [80] [4]
Внутренние узлы дерева представляют собой просто плоские списки пар ключ-указатель, где указатель — это номер логического блока дочернего узла. Листовые узлы содержат ключи элементов, упакованные в переднюю часть узла, и данные элемента, упакованные в конец, причем эти два элемента растут друг к другу по мере заполнения листа. [80]
Внутри каждого каталога записи каталога отображаются как элементы каталога , младшие биты значений ключей которых представляют собой хэш CRC32C их имени файла. Их данные — это ключ местоположения или ключ элемента индексного дескриптора , на который он указывает. Таким образом, элементы каталога вместе могут выступать в качестве индекса для поиска пути к индексному узлу, но не используются для итерации, поскольку они сортируются по хешу, фактически переставляя их случайным образом. Это означает, что пользовательские приложения, перебирающие и открывающие файлы в большом каталоге, таким образом, будут генерировать гораздо больше дисковых операций поиска между несмежными файлами - заметное снижение производительности в других файловых системах с каталогами с хеш-упорядочением, таких как ReiserFS , [81] ext3 (с Htree -indexes включен [82] ) и ext4, все из которых имеют имена файлов, хешированные TEA . Чтобы избежать этого, каждая запись каталога имеет элемент индекса каталога , ключевое значение которого установлено в счетчик для каждого каталога, который увеличивается с каждой новой записью каталога. Таким образом, итерация по этим элементам индекса возвращает записи примерно в том же порядке, в котором они хранятся на диске.
Файлы с жесткими ссылками в нескольких каталогах имеют несколько элементов ссылки, по одному для каждого родительского каталога. Файлы с несколькими жесткими ссылками в одном каталоге упаковывают все имена файлов ссылок в один и тот же ссылочный элемент. Это был недостаток дизайна, из-за которого количество жестких ссылок на один и тот же каталог ограничивалось настолько, насколько их можно было уместить в одном блоке дерева. (При размере блока по умолчанию 4 КиБ, средней длине имени файла 8 байт и заголовке каждого имени файла 4 байта это будет меньше 350.) Приложения, которые интенсивно используют несколько жестких ссылок на один и тот же каталог, такие как При этом пределе наблюдались сбои git , GNUS , GMame и BackupPC . [83] В конечном итоге это ограничение было снято [84] (и по состоянию на октябрь 2012 года оно было объединено [85] в ожидании выпуска в Linux 3.7) путем введения дополнительных расширенных ссылочных элементов для хранения имен файлов с жесткими ссылками, которые в противном случае не подходят.
Данные файла хранятся вне дерева в экстентах , которые представляют собой последовательные фрагменты дисковых блоков данных. Блоки экстента по умолчанию имеют размер 4 КиБ, не имеют заголовков и содержат только (возможно, сжатые) данные файла. В сжатых экстентах отдельные блоки не сжимаются отдельно; скорее, поток сжатия охватывает весь экстент.
Файлы имеют элементы данных экстентов для отслеживания экстентов, в которых хранится их содержимое. Ключевое значение элемента — это начальное смещение байта экстента. Это обеспечивает эффективный поиск в больших файлах с множеством экстентов, поскольку правильный экстент для любого заданного смещения файла можно вычислить всего за один поиск в дереве.
Снимки и клонированные файлы имеют общие экстенты. Когда небольшая часть большого такого экстента перезаписывается, в результате копирования при записи могут быть созданы три новых экстента: маленький, содержащий перезаписанные данные, и два больших с неизмененными данными по обе стороны от перезаписанной области. Чтобы избежать необходимости перезаписывать неизмененные данные, копирование при записи может вместо этого создавать экстенты форзаца или экстенты, которые являются просто фрагментами существующих экстентов. Элементы данных экстента позволяют это сделать, включая смещение в отслеживаемый экстент: элементы для подставок — это элементы со смещением, отличным от нуля. [4]
Дерево распределения экстентов действует как карта распределения для файловой системы. В отличие от других деревьев, элементы в этом дереве не имеют идентификаторов объектов. Они представляют регионы пространства: их ключевые значения содержат начальные смещения и длины регионов, которые они представляют.
Файловая система делит выделенное пространство на группы блоков , которые представляют собой области выделения переменного размера, в которых поочередно используются экстенты метаданных (узлы дерева) и экстенты данных (содержимое файла). Соотношение групп блоков данных и метаданных по умолчанию составляет 1:2. Они предназначены для использования концепции распределителя блоков Орлова для размещения связанных файлов вместе и предотвращения фрагментации, оставляя свободное пространство между группами. (Однако группы блоков Ext3 имеют фиксированное расположение, рассчитанное на основе размера файловой системы, тогда как в Btrfs они являются динамическими и создаются по мере необходимости.) Каждая группа блоков связана с элементом группы блоков . Элементы индексного дескриптора в дереве файловой системы включают ссылку на свою текущую группу блоков. [4]
Элементы экстента содержат обратную ссылку на узел дерева или файл, занимающий этот экстент. Может быть несколько обратных ссылок, если экстент является общим для нескольких снимков. Если обратных ссылок слишком много, чтобы поместиться в элементе, они распределяются по отдельным элементам ссылок на данные экстента . Узлы дерева, в свою очередь, имеют обратные ссылки на содержащие их деревья. Это позволяет определить, какие экстенты или узлы дерева находятся в любой области пространства, выполняя поиск диапазона B-дерева по паре смещений, заключающих эту область в скобки, а затем следуя обратным ссылкам. При перемещении данных это позволяет эффективно перемещаться вверх от перемещенных блоков для быстрого поиска и исправления всех нисходящих ссылок на эти блоки без необходимости сканирования всей файловой системы. Это, в свою очередь, позволяет файловой системе эффективно сжимать, мигрировать и дефрагментировать свое хранилище в режиме онлайн.
Дерево распределения экстентов, как и все другие деревья в файловой системе, копируется при записи. Таким образом, запись в файловую систему может вызвать каскад, в результате которого измененные узлы дерева и данные файла приводят к выделению новых экстентов, что приводит к изменению самого дерева экстентов. Чтобы избежать создания цикла обратной связи , узлы дерева экстентов, которые все еще находятся в памяти, но еще не зафиксированы на диске, могут быть обновлены на месте, чтобы отразить новые экстенты, скопированные при записи.
Теоретически дерево распределения экстентов делает ненужным традиционное растровое изображение свободного пространства, поскольку дерево распределения экстентов действует как версия BSP-дерева в виде B- дерева . Однако на практике для ускорения распределения используется красно-черное дерево растровых изображений размером со страницу , находящееся в памяти . Эти растровые изображения сохраняются на диске (начиная с 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 в 64-битных системах и до 2 EiB в 32-битных системах из-за внутренних ограничений ядра Linux, если только опция конфигурации ядра (доступная начиная с серии ядра 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}
