Btrfs (произносится как «масляная суета», [11] «лучше F S», [8] «масло F S», [12] «b-tree F S», [12] или просто по буквам) - это компьютерный формат хранения который объединяет файловую систему, основанную на принципе копирования при записи (COW), с менеджером логических томов (не путать с LVM Linux ), разработанным совместно. Первоначально он был разработан в Oracle Corporation в 2007 году для использования в Linux , а с ноября 2013 года формат файловой системы на диске был объявлен стабильным в ядре Linux. [13] Согласно Oracle, Btrfs «не является настоящей аббревиатурой».[14]
Разработчики) | Facebook , Fujitsu , Fusion-IO , Intel , Linux Foundation , Netgear , Oracle Corporation , Red Hat , STRATO AG и openSUSE [1] |
---|---|
ФИО | Файловая система B-tree |
Введено | Ядро Linux 2.6.29, март 2009 г . |
Структуры | |
Содержимое каталога | B-дерево |
Размещение файлов | Экстенты |
Пределы | |
Максимум. размер тома | 16 EiB [2] [a] |
Максимум. размер файла | 16 EiB [2] [a] |
Максимум. количество файлов | 2 64 [b] [3] |
Максимум. длина имени файла | 255 символов ASCII (меньше для многобайтовых кодировок символов, таких как Unicode ) |
Допустимые символы в именах файлов | Все, кроме '/' и NUL ( '\0' ) |
Функции | |
Даты записаны | Создание (otime), [4] модификация (mtime), модификация атрибутов (ctime) и доступ (atime) |
Диапазон дат | 64-битное подписанное int смещение от 1970-01-01T00: 00: 00Z [5] |
Разрешение даты | Наносекунда |
Атрибуты | POSIX и расширенные атрибуты |
Разрешения файловой системы | POSIX и ACL |
Прозрачное сжатие | Да ( zlib , LZO [6] и (начиная с 4.14) ZSTD [7] ) |
Прозрачное шифрование | Запланировано [8] |
Дедупликация данных | Да [9] |
Копирование при записи | да |
Другой | |
Поддерживаемые операционные системы | Linux , ReactOS [10] |
Веб-сайт | Btrfs |
Btrfs предназначен для решения проблемы отсутствия пулов , моментальных снимков , контрольных сумм и интегрированного охвата нескольких устройств в файловых системах Linux . [8] Крис Мейсон, главный автор Btrfs, заявил, что его цель состояла в том, чтобы «позволить [Linux] масштабироваться для доступного хранилища. Масштабирование - это не только обращение к хранилищу, но также означает возможность администрировать и управлять им. с чистым интерфейсом, который позволяет людям видеть, что используется, и делает его более надежным ». [15]
История
Основная структура данных Btrfs - « B-дерево копирования при записи» - была первоначально предложена исследователем IBM Охадом Роде на презентации на USENIX 2007. [16] Крис Мейсон, инженер, работавший в то время над ReiserFS для SUSE , позже в том же году присоединился к Oracle и начал работу над новой файловой системой, основанной на этих B-деревьях. [17]
В 2008 году главный разработчик файловых систем ext3 и ext4 Теодор Ц'о заявил, что, хотя ext4 имеет улучшенные функции, это не является большим достижением; он использует старую технологию и является временным препятствием. Ц'о сказал, что Btrfs - лучшее направление, потому что «предлагает улучшения в масштабируемости, надежности и простоте управления». [18] Btrfs также имеет «ряд тех же дизайнерских идей, что и у reiser3 / 4 ». [19]
Btrfs 1.0 с завершенным дисковым форматом изначально планировалось выпустить в конце 2008 года [20] и, наконец, был принят в основную линию ядра Linux в 2009 году. [21] Несколько дистрибутивов Linux начали предлагать Btrfs в качестве экспериментального варианта корневого доступа. файловая система во время установки. [22] [23] [24]
В июле 2011 года функции автоматической дефрагментации и очистки Btrfs были объединены в версию 3.0 основной ветки ядра Linux . [25] Помимо Мэйсона из Oracle, Мяо Се из Fujitsu внесла вклад в повышение производительности. [26] В июне 2012 года Крис Мейсон ушел из Oracle в Fusion-io , которую он покинул год спустя вместе с Йозефом Бачиком, чтобы присоединиться к Facebook . Находясь в обеих компаниях, Мейсон продолжал работать над Btrfs. [27] [17]
В 2012 году два дистрибутива Linux перевели Btrfs из экспериментального в производственный или поддерживаемый статус: Oracle Linux в марте [28], а затем SUSE Linux Enterprise в августе. [29]
В 2015 году Btrfs была принята в качестве файловой системы по умолчанию для SUSE Linux Enterprise Server 12. [30]
В августе 2017 года Red Hat объявила в примечаниях к выпуску Red Hat Enterprise Linux (RHEL) 7.4, что больше не планирует переводить Btrfs, который был включен как «предварительная версия технологии» с бета-версии RHEL 6, в полностью поддерживаемую функцию. отмечая, что он останется доступным в серии выпусков RHEL 7. [31] Btrfs был удален из RHEL 8 в мае 2019 года. [32]
В 2020 году Btrfs был выбран в качестве файловой системы по умолчанию для Fedora 33. [33]
Функции
Реализовано
Начиная с версии 5.0 ядра Linux, Btrfs реализует следующие функции: [34] [35]
- В основном самовосстановление в некоторых конфигурациях из-за характера копирования при записи
- Оперативная дефрагментация и опция монтирования autodefrag [25]
- Рост и сокращение объема онлайн-продаж
- Добавление и удаление онлайн- блочных устройств
- Онлайн-балансировка (перемещение объектов между блочными устройствами для балансировки нагрузки)
- Автономная проверка файловой системы [36]
- Онлайн- очистка данных для поиска ошибок и их автоматического исправления для файлов с избыточными копиями
- RAID 0 , RAID 1 и RAID 10 [37]
- Подтомы (один или несколько отдельно монтируемых корней файловой системы в каждом разделе диска )
- Прозрачный сжатия с помощью Zlib , LZO [6] , и (с 4.14) ZSTD , [7] настраивается для каждого файла или объема [38] [39]
- Атомарная запись (через копирование при записи) или только для чтения [40] Снимки подобъемов
- Клонирование файла ( ссылка , копирование при записи) через
cp --reflink
[41] - Контрольные суммы данных и метаданных ( CRC-32C [42] ). Начиная с 5.5 реализованы новые хэш-функции: [43] xxHash , SHA256 , BLAKE2B .
- Конвертация на месте из ext3 / 4 в Btrfs (с откатом). Эта функция регрессировала по сравнению с версией btrfs-progs 4.0, переписанной с нуля в 4.6. [44]
- Объединенное монтирование хранилища только для чтения, известное как заполнение файловой системы (хранилище только для чтения, используемое как резервное копирование при записи для записываемых Btrfs) [45]
- Отмена блока (освобождает место в некоторых виртуализированных настройках и улучшает выравнивание износа твердотельных накопителей с помощью TRIM )
- Отправка / получение (сохранение различий между снимками в двоичный поток) [46]
- Инкрементное резервное копирование [47]
- Внеполосная дедупликация данных (требуются инструменты пользовательского пространства) [9]
- Возможность обрабатывать файлы подкачки и разделы подкачки
Реализовано, но не рекомендуется для производственного использования
- Иерархические квоты для отдельных объемов [48]
- RAID 5 , RAID 6 [49]
Планируется, но еще не реализовано
- Внутриполосная дедупликация данных [34]
- Онлайн- проверка файловой системы [50]
- RAID с шестью устройствами контроля четности, превосходящими по надежности RAID 5 и RAID 6 [51]
- Объектный уровень RAID 0, RAID 1 и RAID 10
- Шифрование [8] [52]
- Постоянный кеш чтения и записи ( L2ARC + ZIL , lvmcache и т. Д.)
В 2009 году ожидалось, что Btrfs предложит набор функций, сопоставимый с ZFS , разработанный Sun Microsystems . [53] После приобретения Oracle компании Sun в 2009 году Мейсон и Oracle решили продолжить разработку Btrfs. [54]
Клонирование
Btrfs предоставляет операцию клонирования, которая атомарно создает моментальный снимок файла для копирования при записи . Такие клонированные файлы иногда называют ссылками в свете предложенного системного вызова ядра Linux . [55]
При клонировании файловая система не создает новую ссылку, указывающую на существующий индексный дескриптор ; вместо этого он создает новый индексный дескриптор, который изначально использует те же блоки диска, что и исходный файл. В результате клонирование работает только в пределах одной и той же файловой системы Btrfs, но, начиная с версии 3.6 ядра Linux, при определенных обстоятельствах оно может пересекать границы подобъемов. [56] [57] Фактические блоки данных не дублируются; в то же время, из-за того, что Btrfs использует копирование при записи (CoW), изменения любого из клонированных файлов не видны в исходном файле и наоборот. [58]
Клонирование не следует путать с жесткими ссылками , которые представляют собой записи каталога, которые связывают несколько имен файлов с реальными файлами в файловой системе. Хотя жесткие ссылки можно рассматривать как разные имена для одного и того же файла, клонирование в Btrfs предоставляет независимые файлы, которые изначально используют все свои дисковые блоки. [58] [59]
Поддержка этой функции Btrfs была добавлена в GNU coreutils версии 7.5 через --reflink
параметр cp
команды. [60] [61]
Помимо клонирования данных ( FICLONE ), Btrfs также поддерживает внеполосную дедупликацию через FIDEDUPERANGE . Эта функция позволяет двум файлам с (даже частично) идентичными данными совместно использовать хранилище. [62] [9]
Подтомы и снимки
Подтом 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 может генерировать двоичный диф между ними (с помощью btrfs send
команды) , которые могут быть воспроизведены позже (с помощью btrfs receive
), возможно , в другой файловой системе Btrfs. Функция отправки-получения эффективно создает (и применяет) набор модификаций данных, необходимых для преобразования одного подобъема в другой. [46] [66]
Функцию отправки / получения можно использовать с регулярно запланированными моментальными снимками для реализации простой формы репликации файловой системы или для выполнения добавочных резервных копий . [46] [66]
Группы квот
Группа квот (или qgroup ) накладывает верхний предел на пространство, которое может занимать подобъем или моментальный снимок. Новый моментальный снимок изначально не требует квоты, потому что его данные используются совместно с его родительским элементом, но после этого взимается плата за новые файлы и операции копирования при записи для существующих файлов. Когда квоты активны, группа квот автоматически создается для каждого нового подтома или моментального снимка. Эти начальные группы квот представляют собой строительные блоки, которые можно сгруппировать (с помощью btrfs qgroup
команды) в иерархии для реализации пулов квот. [48]
Группы квот применяются только к вложенным объемам и моментальным снимкам, в то время как принудительное применение квот для отдельных подкаталогов, пользователей или групп пользователей невозможно. Однако обходные пути возможны, если использовать разные подтомы для всех пользователей или групп пользователей, для которых требуется принудительная квота.
Преобразование на месте из ext2 / 3/4 и ReiserFS
В результате очень небольшого количества метаданных, закрепленных в фиксированных местах, 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]
По состоянию на июнь 2015 года и версии 4.x основной ветки ядра Linux преобразование в ext3 / 4 на месте считалось непроверенным и использовалось редко. [67] Однако эта функция была переписана с нуля в 2016 году для btrfs-progs
версии 4.6. [44] и с тех пор считается стабильным.
Преобразование на месте из 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 эта функциональность считается относительно стабильной. Однако по состоянию на август 2017 года в документации по btrfs предлагается использовать его только после того, как вы попробовали другие методы восстановления. [73]
Существует еще один инструмент с именем btrfs-restore
, который можно использовать для восстановления файлов из не монтируемой файловой системы без изменения самой поврежденной файловой системы (т. Е. Неразрушающим образом). [74]
При нормальном использовании Btrfs в основном самовосстанавливается и может восстанавливаться после сломанных корневых деревьев во время монтирования благодаря периодическому сбросу данных в постоянное хранилище, по умолчанию каждые 30 секунд. Таким образом, изолированные ошибки приведут к потере максимум 30 секунд изменений файловой системы при следующем монтировании. [75] Этот период можно изменить, указав желаемое значение (в секундах) для commit
опции монтирования. [76] [77]
Дизайн
В первоначальном предложении Охада Родеха на USENIX 2007 отмечалось, что деревья B + , которые широко используются в качестве структур данных на диске для баз данных, не могут эффективно разрешать создание моментальных снимков на основе копирования при записи, потому что их конечные узлы были связаны между собой: если лист был копией - в письменном виде его братья, сестры и родители должны быть такими же, как и их братья и сестры, родители и так далее, пока все дерево не будет скопировано. Вместо этого он предложил модифицированное B-дерево (которое не имеет привязки к листу) с счетчиком ссылок, связанным с каждым узлом дерева, но хранящимся в специальной свободной структуре карты, и определенными изменениями в алгоритмах балансировки дерева, чтобы сделать их удобными для копирования при записи. . В результате получилась бы структура данных, подходящая для высокопроизводительного объектного хранилища, которое могло бы выполнять моментальные снимки копирования при записи, сохраняя при этом хороший параллелизм . [16]
Позднее в том же году в Oracle начал работу над файловой системой с возможностью создания моментальных снимков, которая будет использовать эту структуру данных почти исключительно - не только для метаданных и файловых данных, но и рекурсивно для отслеживания распределения пространства самих деревьев. Это позволяло осуществлять все обходы и модификации по единому пути кода, в котором такие функции, как копирование при записи, контрольная сумма и зеркальное отображение, должны были быть реализованы только один раз, чтобы принести пользу всей файловой системе. [53]
Btrfs структурирован как несколько уровней таких деревьев, использующих одну и ту же реализацию B-дерева. В деревьях хранятся общие элементы, отсортированные по 136-битному ключу. Старшие 64 бита ключа являются уникальным идентификатором объекта . Средние восемь битов представляют собой поле типа элемента: его использование встроено в код в качестве фильтра элементов при поиске в дереве. Объекты могут иметь несколько элементов разных типов. Остальные (наименее значимые) 64 бита используются в зависимости от типа. Таким образом, элементы одного и того же объекта оказываются рядом друг с другом в дереве, сгруппированными по типу. Выбирая определенные ключевые значения, объекты могут размещать элементы одного и того же типа в определенном порядке. [53] [3]
Узлы внутреннего дерева - это просто плоские списки пар ключ-указатель, где указатель - это номер логического блока дочернего узла. Узлы-листы содержат ключи элементов, упакованные в переднюю часть узла, и данные элементов, упакованные в конец, причем два элемента растут друг к другу по мере заполнения листа. [53]
Дерево файловой системы
Внутри каждого каталога записи каталога отображаются как элементы каталога , младшие значащие биты значений ключей которых представляют собой хэш CRC32C их имени файла. Их данные - это ключ местоположения или ключ элемента inode, на который он указывает. Таким образом, элементы каталога вместе могут действовать как индекс для поиска пути к индексному узлу, но не используются для итерации, потому что они сортируются по их хэшам, эффективно переставляя их случайным образом . Это означает , что пользовательские приложения Перебор и открытие файлы в большом каталоге, таким образом , генерировать много больше дисковога ищет между несмежными файлами, заметная дренажными производительностями в других файловых системах с хэш-упорядоченными каталогами , такими как ReiserFS , [78] ext3 (с HTree -indexes enabled [79] ) и ext4, все из которых имеют TEA- хешированные имена файлов. Чтобы избежать этого, каждая запись каталога имеет элемент индекса каталога , значение ключа которого устанавливается равным счетчику для каждого каталога, который увеличивается с каждой новой записью каталога. Таким образом, итерация по этим элементам индекса возвращает записи примерно в том же порядке, в каком они хранятся на диске.
Файлы с жесткими ссылками в нескольких каталогах имеют несколько ссылочных элементов, по одному для каждого родительского каталога. Файлы с несколькими жесткими ссылками в одном каталоге упаковывают все имена файлов ссылок в один и тот же элемент ссылки. Это был недостаток дизайна, который ограничивал количество жестких ссылок на один и тот же каталог до того количества, которое могло уместиться в одном блоке дерева. (При размере блока по умолчанию 4 КиБ, средней длине имени файла 8 байтов и заголовке для каждого имени файла 4 байта это будет меньше 350.) Приложения, которые интенсивно использовали несколько жестких ссылок на один и тот же каталог, такие как git , GNUS , GMame и BackupPC не смогли достичь этого предела. [80] В конечном итоге ограничение было снято [81] (и по состоянию на октябрь 2012 года оно было объединено [82] в ожидании выпуска в Linux 3.7) путем введения дополнительных дополнительных справочных элементов для хранения жестких ссылок на имена файлов, которые в противном случае не подходят.
Экстенты
Данные файла хранятся вне дерева в экстентах , которые представляют собой непрерывные серии блоков данных на диске. По умолчанию блоки экстентов имеют размер 4 КиБ, не имеют заголовков и содержат только (возможно, сжатые) данные файла. В сжатых экстентах отдельные блоки по отдельности не сжимаются; скорее, поток сжатия охватывает весь экстент.
Файлы имеют элементы данных экстентов для отслеживания экстентов, в которых содержится их содержимое. Ключевое значение элемента - это начальное байтовое смещение экстента. Это обеспечивает эффективный поиск в больших файлах с множеством экстентов, потому что правильный экстент для любого заданного смещения файла может быть вычислен с помощью всего лишь одного поиска в дереве.
Экстенты снимков и клонированных файлов имеют общий доступ. Когда небольшая часть такого большого экстента перезаписывается, в результате копирования при записи может быть создано три новых экстента: маленький, содержащий перезаписанные данные, и два больших, с неизмененными данными по обе стороны от перезаписи. Чтобы избежать перезаписи немодифицированных данных, копирование при записи может вместо этого создавать экстенты книжных концов или экстенты, которые являются просто фрагментами существующих экстентов. Элементы данных экстента позволяют это сделать, включая смещение в отслеживаемый экстент: элементы для подставок - это элементы с ненулевым смещением. [3]
Дерево распределения экстентов
Дерево распределения степени действует как карта распределения для файловой системы. В отличие от других деревьев, элементы в этом дереве не имеют идентификаторов объектов. Они представляют регионы пространства: их ключевые значения содержат начальные смещения и длины регионов, которые они представляют.
Файловая система делит выделенное пространство на группы блоков, которые представляют собой области распределения переменного размера, которые чередуются между предпочтительными экстентами метаданных (узлами дерева) и экстентами данных (содержимым файла). По умолчанию соотношение данных к группам блоков метаданных составляет 1: 2. Они предназначены для использования концепции распределителя блоков Орлова для распределения связанных файлов вместе и противодействия фрагментации, оставляя свободное пространство между группами. (Группы блоков Ext3, однако, имеют фиксированные местоположения, вычисленные из размера файловой системы, тогда как группы в Btrfs являются динамическими и создаются по мере необходимости.) Каждая группа блоков связана с элементом группы блоков . Элементы Inode в дереве файловой системы включают ссылку на свою текущую группу блоков. [3]
Элементы экстента содержат обратную ссылку на узел дерева или файл, занимающий этот экстент. Если экстент является общим для снимков, может быть несколько обратных ссылок. Если обратных ссылок слишком много, чтобы уместиться в элементе, они перетекают в отдельные элементы ссылок на данные экстента . Узлы дерева, в свою очередь, имеют обратные ссылки на содержащиеся в них деревья. Это позволяет найти, какие экстенты или узлы дерева находятся в любой области пространства, выполнив поиск диапазона B-дерева по паре смещений, ограничивающих эту область, а затем следуя обратным ссылкам. Для перемещения данных это позволяет эффективно перемещаться вверх от перемещенных блоков для быстрого поиска и исправления всех нисходящих ссылок на эти блоки без необходимости сканирования всей файловой системы. Это, в свою очередь, позволяет файловой системе эффективно сжимать, переносить и дефрагментировать свое хранилище в оперативном режиме.
Дерево распределения экстентов, как и все другие деревья в файловой системе, копирует при записи. Таким образом, записи в файловую систему могут вызвать каскад, в результате которого измененные узлы дерева и данные файла приводят к выделению новых экстентов, вызывая изменение самого дерева экстентов. Чтобы избежать создания петли обратной связи , узлы дерева экстентов, которые все еще находятся в памяти, но еще не зафиксированы на диске, могут быть обновлены на месте, чтобы отразить новые экстенты, копируемые при записи.
Теоретически, дерево распределения экстентов делает ненужным обычную битовую карту свободного пространства, потому что дерево распределения экстентов действует как версия B-дерева для BSP-дерева . На практике, однако, красно-черное дерево растровых изображений размером со страницу используется в памяти для ускорения выделения. Эти растровые изображения сохраняются на диске (начиная с Linux 2.6.37 с помощью параметра space_cache
монтирования [83] ) в виде специальных экстентов, которые не подлежат подсчету контрольной суммы и копированию при записи.
Контрольная сумма и чистка
CRC-32C контрольных суммы вычисляются как для данных и метаданных и хранятся в виде элементов контрольной суммы в контрольной сумме дерева . Существует место для 256 бит контрольных сумм метаданных и до полного узла (примерно 4 КБ или более) для контрольных сумм данных. Btrfs предусматривает добавление дополнительных алгоритмов контрольной суммы в будущих версиях файловой системы. [34] [84]
На каждый непрерывный прогон выделенных блоков приходится один элемент контрольной суммы, при этом контрольные суммы каждого блока непрерывно упаковываются в данные элемента. Если контрольных сумм больше, чем может поместиться, они переносятся в другой элемент контрольной суммы на новом листе. Если файловая система обнаруживает несоответствие контрольной суммы при чтении блока, она сначала пытается получить (или создать) хорошую копию этого блока с другого устройства - если используются методы внутреннего зеркалирования или RAID. [85] [86]
Btrfs может инициировать онлайн-проверку всей файловой системы, запустив задание очистки файловой системы, которое выполняется в фоновом режиме. Задание очистки сканирует всю файловую систему на предмет целостности и автоматически пытается сообщить и исправить любые сбойные блоки, которые оно обнаружит. [85] [87]
Бревенчатое дерево
An FSYNC запрос фиксации модифицированы данные немедленно в постоянное хранилище. Рабочие нагрузки с большим количеством fsync (например, база данных или виртуальная машина , на которой часто работает fsyncs ОС ) потенциально могут генерировать большое количество избыточных операций ввода-вывода при записи, вынуждая файловую систему многократно копировать при записи и сбрасывать часто изменяемые части деревьев в место хранения. Чтобы избежать этого, создается временное дерево журнала для каждого подтома, в котором ведется журнал операций копирования при записи, запускаемых fsync. Деревья журналов являются самодостаточными, отслеживая свои собственные размеры и сохраняя свои собственные элементы контрольной суммы. Их элементы воспроизводятся и удаляются при следующей фиксации полного дерева или (если произошел сбой системы) при следующем повторном подключении.
Деревья чанков и устройств
Блочные устройства делятся на физические блоки размером 256 МБ и более. Физические фрагменты на нескольких устройствах можно зеркально отображать или объединять в один логический фрагмент . Эти логические блоки объединены в единое логическое адресное пространство, которое использует остальная файловая система.
Дерева куска отслеживает это путем сохранения каждого устройства в нем в качестве элемента устройства и логических кусков в качестве элементов куска карты , которые обеспечивают отображение вперед от логического к физическим адресам, сохраняя их смещение в наименее значимых 64 битых их ключе. Элементы карты фрагментов могут быть одного из нескольких типов:
- Один
- 1 логический к 1 физическому блоку
- обман
- От 1 логического фрагмента до 2 физических фрагментов на 1 блочном устройстве
- raid0
- От N логических блоков до N≥2 физических блоков на N≥2 блочных устройствах
- raid1
- 1 логический фрагмент на 2 физических фрагмента на 2 из N≥2 блочных устройств [88], в отличие от обычного RAID 1, который имеет N физических фрагментов
- raid1c3
- От 1 логического блока до 3 физических блоков из N≥3 блочных устройств
- raid1c4
- От 1 логического блока до 4 физических блоков из N≥4 блочных устройств
- рейд5
- От N (для N≥2) логических фрагментов до N + 1 физических фрагментов на N + 1 блочных устройствах, с 1 физическим фрагментом, используемым для контроля четности
- рейд6
- От N (для N≥2) логических фрагментов до N + 2 физических фрагментов на N + 2 блочных устройствах, при этом 2 физических фрагмента используются для контроля четности
N - количество блочных устройств, у которых все еще остается свободное пространство, когда фрагмент выделен. Если N недостаточно велик для выбранного зеркального отображения / отображения, тогда в файловой системе фактически не хватает места.
Деревья переселения
Операции дефрагментации, сжатия и перебалансировки требуют перемещения экстентов. Однако выполнение простого копирования и записи перемещаемого экстента нарушит совместное использование снимков и займет дисковое пространство. Чтобы сохранить совместное использование, используется алгоритм обновления и замены со специальным деревом перемещения, которое служит временным пространством для затронутых метаданных. Перемещаемый экстент сначала копируется в место назначения. Затем, следуя обратным ссылкам вверх по дереву файловой системы затронутого подобтома, метаданные, указывающие на старый экстент, постепенно обновляются, чтобы указывать на новый; любые недавно обновленные элементы сохраняются в дереве перемещения. После завершения обновления элементы в дереве перемещения меняются местами со своими аналогами в затронутом подобтоме, а дерево перемещения отбрасывается. [89]
Суперблок
Все деревья файловой системы, включая само дерево фрагментов, хранятся фрагментами, что создает потенциальную проблему начальной загрузки при монтировании файловой системы. Для начальной загрузки при монтировании в суперблоке сохраняется список физических адресов фрагментов, принадлежащих фрагментам и корневым деревьям . [90]
Зеркала суперблока хранятся в фиксированных местах: [91] 64 КиБ в каждое блочное устройство, с дополнительными копиями в 64 МиБ, 256 ГиБ и 1 ПиБ. При обновлении зеркала суперблока увеличивается номер его поколения . Во время монтирования используется копия с наивысшим номером поколения. Все зеркала суперблока обновляются в тандеме, за исключением режима SSD, в котором обновления зеркал чередуются для обеспечения некоторого выравнивания износа .
Коммерческая поддержка
Поддерживается
- Fedora Workstation, начиная с версии 33 [92]
- Oracle Linux, начиная с версии 7 [93] [94]
- SUSE Linux Enterprise Server, начиная с версии 12 [95] [96]
- Synology DiskStation Manager (DSM), начиная с версии 6.0 [97]
- ReactOS с версии 0.4.10 [98]
Больше не поддерживается
- Btrfs был включен в качестве «предварительной версии технологии» в Red Hat Enterprise Linux 6 и 7; [22] [31] он был удален в RHEL 8 в 2018 году. [32] [99] [100]
Смотрите также
- APFS - файловая система с копированием при записи для macOS, iOS, tvOS, watchOS и audioOS
- Bcachefs
- Сравнение файловых систем
- HAMMER - файловая система DragonFly BSD, которая использует B-деревья в сочетании с контрольными суммами в качестве меры противодействия повреждению данных.
- Список файловых систем
- ReFS - файловая система с копированием при записи для Windows Server 2012
- ZFS
Заметки
- ^ a b Это собственный лимит Btrfs на размер диска. Предел снижен до 8 EiB в 64-битных системах и 2 EiB в 32-битных системах из-за внутренних ограничений ядра Linux, если только
CONFIG_LBD
опция конфигурации ядра (доступная с версии ядра 2.6.x ) не включена для снятия этих ограничений ядра. [101] [102] - ^ Каждый элемент в Btrfs имеет 64-битный идентификатор, что означает, что максимальное количество файлов в файловой системе Btrfs составляет 2 64 .
Рекомендации
- ^ «Авторы Btrfs на kernel.org» . kernel.org. 18 января 2016 . Проверено 20 января +2016 .
- ^ а б «Документация Suse: Руководство по администрированию хранилищ - Поддержка больших файлов в Linux» . SUSE . Проверено 12 августа 2015 года .
- ^ а б в г Мейсон, Крис. «БТРФС дизайн» . Btrfs вики . Проверено 8 ноября 2011 года .
- ^ Джонатан Корбет (26 июля 2010 г.). «Время создания файла» . LWN.net . Проверено 15 августа 2015 года .
- ^ «Формат на диске - btrfs Wiki» . btrfs.wiki.kernel.org .
- ^ а б "btrfs Wiki" . kernel.org . Проверено 19 апреля 2015 года .
- ^ а б «Linux_4.14 - новички в ядре Linux» . kernelnewbies.org .
- ^ а б в г Макферсон, Аманда (22 июня 2009 г.). «Беседа с Крисом Мейсоном о BTRfs: файловой системе нового поколения для Linux» . Linux Foundation . Архивировано из оригинального 27 июня 2012 года . Проверено 1 сентября 2009 .
- ^ а б в «Дедупликация» . kernel.org . Проверено 19 апреля 2015 года .
- ^ «Выпущена ReactOS 0.4.1» . reactos.org . Проверено 11 августа +2016 .
- ^ http://streaming.oracle.com/ebn/podcasts/media/20209545_Oracle-Linux-7.mp4
- ^ а б Хенсон, Валери (31 января 2008 г.). Chunkfs: быстрая проверка и восстановление файловой системы . Мельбурн , Австралия. Событие происходит в 18:49 . Проверено 5 февраля 2008 года .
Это называется Butter FS или B-tree FS, но все крутые ребята говорят, что Butter FS
- ^ «Ядро Linux фиксирует изменение статуса стабильности в fs / btrfs / Kconfig» . Проверено 8 февраля 2019 .
- ^ «22.2 О файловой системе Btrfs» . Docs.Oracle.com . Oracle . 2018. Архивировано из оригинального 28 апреля 2018 года . Проверено 27 января 2021 года .
- ^ Кернер, Шон Майкл (30 октября 2008 г.). "Лучшая файловая система для Linux?" . InternetNews.com . Архивировано 8 апреля 2011 года . Проверено 27 августа 2020 .
- ^ а б Родех, Охад (2007). B-деревья, затенение и клоны (PDF) . USENIX Linux Storage & Filesystem Workshop. Также Родех, Охад (2008). «B-деревья, затенение и клоны». ACM-транзакции в хранилище . 3 (4): 1-27. DOI : 10.1145 / 1326542.1326544 .
- ^ а б «Ведущие разработчики файловой системы Btrfs присоединяются к Facebook» . phoronix.com . Проверено 19 апреля 2015 года .
- ^ Пол, Райан (13 апреля 2009 г.). «Участники дискуссии обдумывают ядро на Linux Collaboration Summit» . Ars Technica. Архивировано из оригинального 17 июня 2012 года . Проверено 22 августа 2009 . Цитировать журнал требует
|journal=
( помощь ) - ^ Ц'О, Теодор (1 августа 2008 г.). "Re: reiser4 для 2.6.27-rc1" . linux-kernel (список рассылки) . Проверено 31 декабря 2010 года .
- ^ «График разработки» . Btrfs вики . 11 декабря 2008 года Архивировано из оригинала 20 декабря 2008 года . Проверено 5 ноября 2011 года .
- ^ Вуэльфинг, Бритта (12 января 2009 г.). «Ядро 2.6.29: Корбет говорит, что файловая система нового поколения Btrfs» . Журнал Linux . Проверено 5 ноября 2011 года .
- ^ а б «Документация по Red Hat Enterprise Linux 6: предварительные версии технологий» . Архивировано из оригинального 28 мая 2011 года . Проверено 21 января 2011 года .
- ^ «Выпуск 276 еженедельных новостей Fedora» . 25 мая 2011г.
- ^ "Выпущен Debian 6.0" Squeeze " (пресс-релиз). Debian . 6 февраля 2011 . Проверено 8 февраля 2011 года .
Также была добавлена поддержка файловых систем ext4 и Btrfs ...
- ^ а б «Ядро Linux 3.0, раздел 1.1. Btrfs: автоматическая дефрагментация, очистка, улучшения производительности» . kernelnewbies.org . 21 июля 2011 . Проверено 5 апреля 2016 года .
- ^ Leemhuis, Thorsten (21 июня 2011 г.). «Журнал ядра: появится в версии 3.0 (Часть 2) - Файловые системы» . The H Open . Проверено 8 ноября 2011 года .
- ^ Варгезе, Сэм. «iTWire» . ITWire.com . Проверено 19 апреля 2015 года .
- ^ «Выпущен Unbreakable Enterprise Kernel Release 2» . Дата обращения 8 мая 2019 .
- ^ «Примечания к выпуску SLES 11 SP2» . 21 августа 2012 . Проверено 29 августа 2012 года .
- ^ «Примечания к выпуску SUSE Linux Enterprise Server 12» . 5 ноября 2015 . Проверено 20 января +2016 .
- ^ а б «Примечания к выпуску Red Hat Enterprise Linux 7.4, Глава 53: Устаревшие функции» . 1 августа 2017. Архивировано из оригинала 8 -го августа 2017 года . Проверено 15 августа 2017 года .
- ^ а б «Соображения при принятии RHEL 8» . Документация по продукту для Red Hat Enterprise Linux 8 . Красная шляпа . Дата обращения 9 мая 2019 .
- ^ «Btrfs приходит в Fedora 33» . Журнал Fedora . 24 августа 2020 . Проверено 25 августа 2020 .
- ^ а б в «Btrfs Wiki: особенности» . btrfs.wiki.kernel.org . 27 ноября 2013 . Проверено 27 ноября 2013 года .
- ^ "Btrfs Wiki: Список изменений" . btrfs.wiki.kernel.org . 29 мая 2019 . Проверено 27 ноября 2013 года .
- ^ "Manpage btrfs-check" .
- ^ «Использование Btrfs с несколькими устройствами» . kernel.org . 7 ноября 2013 . Проверено 20 ноября 2013 года .
- ^ «Сжатие» . kernel.org . 25 июня 2013 . Проверено 1 апреля 2014 года .
- ^ «Btrfs: добавить поддержку свойств inode» . kernel.org . 28 января 2014 . Проверено 1 апреля 2014 года .
- ^ «btrfs: снимки только для чтения» . Проверено 12 декабря 2011 года .
- ^ «Экономьте дисковое пространство в Linux, клонируя файлы на Btrfs и OCFS2» . Проверено 1 августа 2017 года .
- ^ "Wiki FAQ: Какую функцию контрольной суммы использует Btrfs?" . Btrfs вики . Проверено 15 июня 2009 года .
- ^ "Btrfs hilights в 5.5: новые хеши" . Проверено 29 августа 2020 .
- ^ а б "Проги btrfs релиз 4.6" . Проверено 1 августа 2017 года .
- ^ Мейсон, Крис (12 января 2009 г.). "Журнал изменений Btrfs" . Архивировано из оригинального 29 февраля 2012 года . Проверено 12 февраля 2012 года .
- ^ а б в Корбет, Джонатан (11 июля 2012 г.), Btrfs send / receive , LWN.net , получено 14 ноября 2012 г.
- ^ «Btrfs Wiki: инкрементное резервное копирование» . 27 мая 2013 . Проверено 27 ноября 2013 года .
- ^ а б Янсен, Арне (2011), Btrfs Subvolume Quota Groups (PDF) , Strato AG , получено 14 ноября 2012 г.
- ^ btrfs (16 июля 2016 г.). «RAID 5/6» . kernel.org . Проверено 1 октября +2016 .
- ^ Корбет, Джонатан (2 ноября 2011 г.). «Обновление btrfs на LinuxCon Europe» . Проверено 12 февраля 2012 года .
- ^ Маццолени, Андреа. «btrfs: lib: raid: Новая библиотека RAID, поддерживающая до шести четностей» . Проверено 16 марта 2014 года .
- ^ «Идеи проекта БТРФС» . 21 февраля 2013 . Проверено 21 февраля 2013 года .
- ^ а б в г Аврора, Валери (22 июля 2009 г.). «Краткая история БТРФС» . LWN.net . Проверено 5 ноября 2011 года .
- ^ Хильцингер, Марсель (22 апреля 2009 г.). «Будущее BTRFS обеспечено» . Журнал Linux . Проверено 5 ноября 2011 года .
- ^ Корбет, Джонатан (5 мая 2009 г.). «Две стороны reflink ()» . LWN.net . Проверено 17 октября 2013 года .
- ^ а б «Варианты использования - документация по btrfs» . kernel.org . Проверено 4 ноября 2013 года .
- ^ "btrfs: разрешить клонирование файла из одного тома" . github.com . Проверено 4 ноября 2013 года .
- ^ а б Ленц Гриммер (31 августа 2011 г.). «Экономьте дисковое пространство в Linux, клонируя файлы на Btrfs и OCFS2» . oracle.com . Проверено 17 октября 2013 года .
- ^ «Символьные ссылки ссылаются на имена, жесткие ссылки ссылаются на метаданные и ссылаются на справочные данные» . pixelbeat.org . 27 октября 2010 . Проверено 17 октября 2013 года .
- ^ Мейеринг, Джим (20 августа 2009 г.). «НОВОСТИ GNU coreutils: важные изменения в версии 7.5» . savannah.gnu.org . Проверено 30 августа 2009 года .
- ^ Скривано, Джузеппе (1 августа 2009 г.). "cp: примите параметр --reflink" . savannah.gnu.org . Проверено 2 ноября 2009 года .
- ^ - Руководство программиста Linux - Системные вызовы
- ^ а б в г "SysadminGuide - документация Btrfs" . kernel.org . Проверено 31 октября 2013 года .
- ^ а б в «5.6 Создание вложенных томов и моментальных снимков [требуется обновление]» . oracle.com . 2013 . Проверено 31 октября 2013 года .
- ^ "Попался - btrfs Wiki" . btrfs.wiki.kernel.org .
- ^ а б «5.7 Использование функции отправки / получения» . oracle.com . 2013 . Проверено 31 октября 2013 года .
- ^ а б в г Мейсон, Крис (25 июня 2015 г.). «Конвертация из Ext3 (документация по Btrfs)» . kernel.org . Проверено 22 апреля 2016 года .
- ^ "Справочная страница btrfs-convert (8)" . Проверено 24 апреля 2018 года .
- ^ «Посевной аппарат» .
- ^ Мейсон, Крис (5 апреля 2012 г.), Файловая система Btrfs: состояние и новые возможности , Linux Foundation , получено 16 ноября 2012 г.[ постоянная мертвая ссылка ]
- ^ Макферсон, Аманда (22 июня 2009 г.). «Беседа с Крисом Мейсоном о BTRfs: файловой системе нового поколения для Linux» . Linux Foundation . Архивировано из оригинального 27 июня 2012 года . Проверено 9 октября 2014 года .
В будущих выпусках мы планируем добавить онлайн-утилиту fsck, дедупликацию, шифрование и другие функции, которые уже давно были в списках желаний администратора.
- ^ Стерба, Дэвид. "аутентифицированные файловые системы с использованием HMAC (SHA256)" . Lore.Kernel.org . Проверено 25 апреля 2020 года .
- ^ "Btrfsck - btrfs Wiki" . btrfs.wiki.kernel.org .
- ^ «Восстановление - btrfs Wiki» . btrfs.wiki.kernel.org .
- ^ «FAQ по проблемам - btrfs Wiki» . kernel.org . 31 июля 2013 . Проверено 16 января 2014 года .
- ^ "kernel / git / torvalds / linux.git: Документация: файловые системы: добавить новые параметры монтирования btrfs (дерево исходных текстов ядра Linux)" . kernel.org . 21 ноября 2013 . Проверено 6 февраля 2014 года .
- ^ «Параметры монтирования - btrfs Wiki» . kernel.org . 12 ноября 2013 . Проверено 16 января 2014 года .
- ^ Райзер, Ганс (7 декабря 2001 г.). «Re: Индекс каталога Ext2: бумага и тесты ALS» . Список рассылки разработчиков ReiserFS . Проверено 28 августа 2009 года .
- ^ Мейсон, Крис. «Acp» . Персональная веб-страница Oracle . Проверено 5 ноября 2011 года .
- ^ «Ограничение жестких ссылок» . kerneltrap.org . 8 августа 2010 . Проверено 14 ноября 2011 года .
- ^ Фашех, Марк (9 октября 2012 г.). "btrfs: расширенные ссылки на индексные дескрипторы" . Архивировано из оригинального 15 апреля 2013 года . Проверено 7 ноября 2012 года .
- ^ Торвальдс, Линус (10 октября 2012 г.). "Получите обновление btrfs от Криса Мэйсона" . git.kernel.org . Архивировано из оригинального 15 апреля 2013 года . Проверено 7 ноября 2012 года .
- ^ Ларабель, Майкл (24 декабря 2010 г.). «Контрольные показатели опции Btrfs Space Cache» . Фороникс . Проверено 16 ноября 2012 года .
- ^ "FAQ - btrfs Wiki: Какую функцию контрольной суммы использует Btrfs?" . Проект btrfs . Дата обращения 22 ноября 2020 .
- ^ а б Бирман, Маргарет; Гриммер, Ленц (август 2012 г.). «Как я использую расширенные возможности Btrfs» . Проверено 20 сентября 2013 года .
- ^ Солтер, Джим (15 января 2014 г.). "Bitrot и Atomic COWs: Внутри файловых систем" следующего поколения " . Ars Technica . Проверено 15 января 2014 года .
- ^ Коэкартс, Вим (28 сентября 2011 г.). "Btrfs Scrub - Исправьте повреждения с помощью зеркальных копий, пожалуйста!" . Проверено 20 сентября 2013 года .
- ^ "Manpage / MKFS.BTRFS - BTRFS Wiki" .
- ^ Мейсон, Крис; Родех, Охад; Бачик, Йозеф (9 июля 2012 г.), BTRFS: Linux B-tree Filesystem (PDF) , IBM Research , получено 12 ноября 2012 г.
- ^ Мейсон, Крис (30 апреля 2008 г.). «Поддержка нескольких устройств» . Btrfs вики . Архивировано из оригинала 20 июля 2011 года . Проверено 5 ноября 2011 года .
- ^ Бартелл, Шон (20 апреля 2010 г.). «Re: Восстановление раздела BTRFS» . linux-btrfs (список рассылки).
- ^ "Fedora 33 официально здесь!" . 27 октября 2020 . Проверено 28 октября 2020 года .
- ^ «Oracle теперь поддерживает Btrfs RAID5 / 6 на своем нерушимом корпоративном ядре - Phoronix» . Phoronix.com .
- ^ «Управление Btrfs в Oracle Linux 8» . docs.oracle.com .
- ^ «SUSE подтверждает поддержку Btrfs» . LWN.net .
- ^ «Примечания к выпуску SUSE Linux Enterprise Server 12» . SUSE.com . Проверено 28 февраля 2021 года .
- ^ «Белая книга Cloud Station» (PDF) . Synology.com . Synology . п. 11 . Проверено 2 апреля 2021 года .
Начиная с DSM 6.0, тома данных можно форматировать как Btrfs.
- ^ «Файловые системы» . ReactOS.org . Проверено 28 февраля 2021 года .
- ^ «Btrfs устарел в RHEL | Hacker News» . News.YCombinator.com .
- ^ "Red Hat, похоже, оставляет свои надежды на Btrfs - Phoronix" . Phoronix.com .
- ^ Андреас Йегер (15 февраля 2005 г.). «Поддержка больших файлов в Linux» . users.suse.com . Проверено 12 августа 2015 года .
- ^ «Справка по настройке ядра Linux для CONFIG_LBD в 2.6.29 на x86» . kernel.xc.net . Архивировано из оригинального 6 -го сентября 2015 года . Проверено 12 августа 2015 года .
Внешние ссылки
- Официальный веб-сайт
- Не могу поверить, что это масло! Экскурсия по btrfs на YouTube - презентация на конференции Ави Миллера, инженера Oracle
- Btrfs: Работа с несколькими устройствами - LWN.net , декабрь 2013 г., Джонатан Корбет
- Сообщения Марка о Linux Btrfs - подробные сведения о различных функциях Btrfs
- Обзор Btrfs , LinuxCon 2014, Марк Мерлин
- Евангелист файловой системы и идейный лидер: интервью с Валери Аврора , Linux Magazine , 14 июля 2009 г., Джеффри Б. Лейтон