✖


Jump to content

Бтрфс

(Перенаправлено с BtrFS )

Бтрфс
Разработчик(и) SUSE , Meta , Western Digital , Oracle Corporation , Fujitsu , Fusion-io , Intel , The Linux Foundation , Red Hat и Strato AG [1]
Полное имя Файловая система B-дерева
Представлено 23 марта 2009 г .; 15 лет назад ( 23 марта 2009 г. ) с ядром Linux 2.6.29
Идентификаторы разделов
  • MBR : 0x83: собственная файловая система Linux.
  • GPT : 0FC63DAF-8483-4772-8E79-3D69D8477DE4: собственная файловая система Linux. [2]
Структуры
Содержимое каталога B-дерево
Распределение файлов Экстенты
Плохие блоки Ничего не записано
Пределы
Максимальный размер тома 16 ЭйБ [3] [а]
Максимальный размер файла 16 ЭйБ [3] [а]
Макс нет. файлов 2 64 [б] [4]
Максимальная длина имени файла 255 символов ASCII (меньше для многобайтовых кодировок символов, таких как Unicode )
Разрешенное имя файла
персонажи 		Все кроме '/' и NUL ( '\0')
Функции
Даты записи Творение (отайм), [5] модификация (mtime), модификация атрибута (ctime) и доступ (atime)
Диапазон дат 64-битное целое число со знаком, смещение от 1970-01-01T00:00:00Z [6]
Разрешение даты наносекунда
Атрибуты POSIX и расширенные атрибуты
Файловая система
разрешения 		Разрешения Unix, списки ACL POSIX
Прозрачный
сжатие 		Да ( злиб , ЛЗО [7] и (начиная с версии 4.14) ЗСТД [8] )
Прозрачный
шифрование 		Планируется [9]
Дедупликация данных Да [10]
Копирование при записи Да
Другой
Поддерживается
операционные системы 		Линукс , Винда , [11] РеактОС [12]
Веб-сайт документы .ядро .org /файловые системы /btrfs .html Отредактируйте это в Викиданных

Btrfs (произносится как «better F S», [9] «масло Ф С», [13] [14] "b-дерево F S", [14] или BTRFS) — компьютерный формат хранения данных, сочетающий в себе файловую систему , основанную на принципе копирования при записи (COW), с менеджером логических томов (не путать с Linux LVM ), разработанными совместно. Основана Крисом Мейсоном в 2007 году. [15] для использования в Linux , а с ноября 2013 года формат файловой системы на диске объявлен стабильным в ядре Linux . [16]

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

История

[ редактировать ]
Снимок экрана с информацией об использовании файловой системы Btrfs.

копирования при записи Базовая структура данных 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]

[ редактировать ]

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

[ редактировать ]

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 также поддерживает внеполосную дедупликацию через ФИДЕДЮПЕРАНЖ . Эта функциональность позволяет двум файлам с (даже частично) идентичными данными совместно использовать хранилище. [62] [10]

Подтома и снимки

[ редактировать ]
Пример снимков файловой системы Btrfs, управляемой с помощью Snapper

Подтом Btrfs можно рассматривать как отдельное пространство имен файлов POSIX , которое можно монтировать отдельно, передав subvol или subvolid варианты для mount(8) полезность. Доступ к нему также можно получить, смонтировав субтом верхнего уровня, и в этом случае субтома видны и доступны как его подкаталоги. [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]

Группы квот

[ редактировать ]
Пример групп квот Btrfs

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

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

Преобразование на месте из 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]

В версиях 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-индексами) [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 битах своего ключа. Элементы карты фрагментов могут относиться к одному из нескольких типов:

одинокий
1 логический к 1 физическому чану
обман
От 1 логического блока до 2 физических блоков на 1 блочном устройстве
трансляция0
От N логических фрагментов до N≥2 физических фрагментов на N≥2 блочных устройствах
трансляция1
От 1 логического фрагмента до 2 физических фрагментов на 2 блочных устройствах из N≥2, [92] в отличие от обычного RAID 1, который имеет N физических блоков
рейд1c3
От 1 логического фрагмента до 3 физических фрагментов из N≥3 блочных устройств
рейд1c4
От 1 логического фрагмента до 4 физических фрагментов из N≥4 блочных устройств
рейд5
От N (для N≥2) логических фрагментов до N+1 физических фрагментов на блочных устройствах N+1, при этом 1 физический фрагмент используется в качестве четности
рейд6
От N (для N≥2) логических фрагментов до N+2 физических фрагментов на блочных устройствах N+2, при этом 2 физических фрагмента используются в качестве четности

N — количество блочных устройств, оставшихся свободными при выделении фрагмента. Если N недостаточно велико для выбранного зеркалирования/отображения, то в файловой системе фактически не хватает места.

Перемещение деревьев

[ редактировать ]

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

Суперблок

[ редактировать ]

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

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

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

[ редактировать ]

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

[ редактировать ]
См. также: Список файловых систем по умолчанию.

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

[ редактировать ]

См. также

[ редактировать ]

Примечания

[ редактировать ]
  1. ^ Jump up to: а б Это собственный предел размера Btrfs на диске. Предел уменьшен до 8 EiB в 64-битных системах и до 2 EiB в 32-битных системах из-за внутренних ограничений ядра Linux, если только ядро ​​не CONFIG_LBD опция конфигурации (доступная начиная с серии ядра 2.6.x ) включена для снятия этих ограничений ядра. [103] [104]
  2. ^ Каждый элемент в Btrfs имеет 64-битный идентификатор, что означает, что максимальное количество файлов, которые можно иметь в файловой системе Btrfs, равно 2. 64 .

Ссылки

[ редактировать ]
  1. ^ «Соавторы документации BTRFS» . ядро.org. 15 июня 2022 г. Проверено 5 декабря 2022 г.
  2. ^ «GPT fdisk — ArchWiki» .
  3. ^ Jump up to: а б «Документация Suse: Руководство по администрированию хранилища – Поддержка больших файлов в Linux» . СУЗЕ . Проверено 12 августа 2015 г.
  4. ^ Jump up to: а б с д Мейсон, Крис. «Дизайн Btrfs» . Btrfs вики . Проверено 8 ноября 2011 г.
  5. ^ Джонатан Корбет (26 июля 2010 г.). «Время создания файла» . LWN.net . Проверено 15 августа 2015 г.
  6. ^ «Формат на диске — btrfs Wiki» . btrfs.wiki.kernel.org .
  7. ^ Jump up to: а б «btrfs вики» . ядро.орг . Проверено 19 апреля 2015 г.
  8. ^ Jump up to: а б «Linux_4.14 — новички в ядре Linux» . kernelnewbies.org .
  9. ^ Jump up to: а б с Макферсон, Аманда (22 июня 2009 г.). «Разговор с Крисом Мейсоном о BTRfs: файловой системе следующего поколения для Linux» . Фонд Linux . Архивировано из оригинала 27 июня 2012 года . Проверено 1 сентября 2009 г.
  10. ^ Jump up to: а б с «Дедупликация» . ядро.орг . Проверено 19 апреля 2015 г.
  11. ^ «Драйвер Windows на GitHub.com» . Гитхаб . Проверено 10 января 2023 г.
  12. ^ «Выпущена ReactOS 0.4.1» . http://reactos.org . Проверено 11 августа 2016 г.
  13. ^ «Вопросы и ответы по Oracle Linux 7 с Вимом Кукертсом» . Оракул . Событие происходит в 1:15. Архивировано из оригинала 18 августа 2016 года . Проверено 6 февраля 2016 г.
  14. ^ Jump up to: а б Хенсон, Валери (31 января 2008 г.). Chunkfs: Быстрая проверка и восстановление файловой системы . Мельбурн , Австралия. Событие происходит в 18:49 . Проверено 5 февраля 2008 г. Это называется Butter FS или B-tree FS, но все крутые ребята говорят Butter FS.
  15. ^ Солтер, Джим (24 сентября 2021 г.). «Исследование btrfs, вечно недоделанной файловой системы Linux» . Арс Техника . Проверено 11 июня 2023 г. Крис Мейсон — основатель-разработчик btrfs, над которым он начал работать в 2007 году, работая в Oracle. Это заставляет многих людей думать, что btrfs — это проект Oracle, но это не так. Проект принадлежал Мэйсону, а не его работодателю, и по сей день он остается общественным проектом, не обремененным корпоративной собственностью.
  16. ^ «Ядро Linux фиксирует изменение статуса стабильности в fs/btrfs/Kconfig» . Проверено 8 февраля 2019 г.
  17. ^ Кернер, Шон Майкл (30 октября 2008 г.). «Лучшая файловая система для Linux?» . ИнтернетНьюс.com . Архивировано из оригинала 8 апреля 2011 года . Проверено 27 августа 2020 г.
  18. ^ Jump up to: а б Роде, Охад (2007). B-деревья, затенение и клоны (PDF) . Семинар USENIX по хранению и файловой системе Linux. Также Роде, Охад (2008). «B-деревья, затенение и клоны». Транзакции ACM в хранилище . 3 (4): 1–27. дои : 10.1145/1326542.1326544 . S2CID   207166167 .
  19. ^ Jump up to: а б «Ведущие разработчики файловой системы Btrfs присоединяются к Facebook» . phoronix.com . Проверено 19 апреля 2015 г.
  20. ^ Пол, Райан (13 апреля 2009 г.). «Участники дискуссии размышляют о ядре на саммите Linux Collaboration Summit» . Арс Техника . Архивировано из оригинала 17 июня 2012 года . Проверено 22 августа 2009 г.
  21. ^ Цо, Теодор (1 августа 2008 г.). «Re: reiser4 для 2.6.27-rc1» . linux-kernel (список рассылки) . Проверено 31 декабря 2010 г.
  22. ^ «Хронология разработки» . Btrfs вики . 11 декабря 2008 г. Архивировано из оригинала 20 декабря 2008 г. Проверено 5 ноября 2011 г.
  23. ^ Вельфинг, Бритта (12 января 2009 г.). «Ядро 2.6.29: Корбет заявляет о файловой системе нового поколения Btrfs» . Журнал Линукс . Проверено 5 ноября 2011 г.
  24. ^ Jump up to: а б «Документация Red Hat Enterprise Linux 6: обзор технологий» . Архивировано из оригинала 28 мая 2011 года . Проверено 21 января 2011 г.
  25. ^ «Еженедельные новости Fedora, выпуск 276» . 25 мая 2011 г.
  26. ^ «Выпущен Debian 6.0 «Squeeze»» (Пресс-релиз). Дебиан . 6 февраля 2011 года . Проверено 8 февраля 2011 г. Также добавлена ​​поддержка файловых систем ext4 и Btrfs...
  27. ^ Jump up to: а б «Ядро Linux 3.0, раздел 1.1. Btrfs: автоматическая дефрагментация, очистка, повышение производительности» . kernelnewbies.org . 21 июля 2011 года . Проверено 5 апреля 2016 г.
  28. ^ Лемхейс, Торстен (21 июня 2011 г.). «Журнал ядра: появление версии 3.0 (часть 2) — Файловые системы» . H Открыть . Проверено 8 ноября 2011 г.
  29. ^ Варгезе, Сэм. «АйтиВайр» . ITWire.com . Проверено 19 апреля 2015 г.
  30. ^ «Выпущен Unbreakable Enterprise Kernel Release 2» . Проверено 8 мая 2019 г.
  31. ^ «Примечания к выпуску SLES 11 SP2» . 21 августа 2012 года . Проверено 29 августа 2012 г.
  32. ^ «Примечания к выпуску SUSE Linux Enterprise Server 12» . 5 ноября 2015 года . Проверено 20 января 2016 г.
  33. ^ Jump up to: а б «Примечания к выпуску Red Hat Enterprise Linux 7.4, глава 53: Устаревшие функции» . 1 августа 2017 года. Архивировано из оригинала 8 августа 2017 года . Проверено 15 августа 2017 г.
  34. ^ Jump up to: а б «Аспекты внедрения RHEL 8» . Документация продукта для Red Hat Enterprise Linux 8 . Красная шляпа . Проверено 9 мая 2019 г.
  35. ^ «Как выбрать файловую систему Red Hat Enterprise Linux» . 4 сентября 2020 г. Проверено 3 января 2022 г.
  36. ^ «Btrfs появится в Fedora 33» . Журнал Федора . 24 августа 2020 г. Проверено 25 августа 2020 г.
  37. ^ Jump up to: а б «Btrfs Wiki: Возможности» . btrfs.wiki.kernel.org . 27 ноября 2013 года . Проверено 27 ноября 2013 г.
  38. ^ «Btrfs Wiki: Журнал изменений» . btrfs.wiki.kernel.org . 29 мая 2019 года . Проверено 27 ноября 2013 г.
  39. ^ «Manpage btrfs-check» .
  40. ^ «Использование Btrfs на нескольких устройствах» . ядро.орг . 7 ноября 2013 года . Проверено 20 ноября 2013 г.
  41. ^ «Сжатие» . ядро.орг . 25 июня 2013 года . Проверено 1 апреля 2014 г.
  42. ^ «Btrfs: добавить поддержку свойств индексного дескриптора» . ядро.орг . 28 января 2014 года . Проверено 1 апреля 2014 г.
  43. ^ «btrfs: снимки только для чтения» . Проверено 12 декабря 2011 г.
  44. ^ «Экономьте дисковое пространство в Linux, клонируя файлы в Btrfs и OCFS2» . Проверено 1 августа 2017 г.
  45. ^ «Часто задаваемые вопросы Wiki: какую функцию контрольной суммы использует Btrfs?» . Btrfs вики . Проверено 15 июня 2009 г.
  46. ^ «Основные моменты Btrfs в версии 5.5: новые хеши» . Проверено 29 августа 2020 г.
  47. ^ Jump up to: а б "Проги Btrfs релиз 4.6" . Проверено 1 августа 2017 г.
  48. ^ Мейсон, Крис (12 января 2009 г.). «Журнал изменений Btrfs» . Архивировано из оригинала 29 февраля 2012 года . Проверено 12 февраля 2012 г.
  49. ^ Jump up to: а б с Корбет, Джонатан (11 июля 2012 г.), отправка/получение Btrfs , LWN.net , получено 14 ноября 2012 г.
  50. ^ «Btrfs Wiki: добавочное резервное копирование» . 27 мая 2013 года . Проверено 27 ноября 2013 г.
  51. ^ Jump up to: а б Янсен, Арне (2011), Btrfs Subvolume Quota Groups (PDF) , Strato AG , получено 14 ноября 2012 г.
  52. ^ btrfs (16 июля 2016 г.). «РЕЙД 5/6» . ядро.орг . Проверено 1 октября 2016 г.
  53. ^ Зиго Блэкселл. «Как успешно использовать btrfs RAID5 (иш)» . lore.kernel.org . Проверено 26 июня 2022 г.
  54. ^ Зиго Блэкселл. «Текущие ошибки, влияющие на работу btrfs RAID5» . lore.kernel.org . Проверено 26 июня 2022 г.
  55. ^ Корбет, Джонатан (5 мая 2009 г.). «Две стороны reflink()» . LWN.net . Проверено 17 октября 2013 г.
  56. ^ Jump up to: а б «Случаи использования — документация по btrfs» . ядро.орг . Проверено 4 ноября 2013 г.
  57. ^ «btrfs: разрешить клонирование файлов между подтомами» . github.com . Проверено 4 ноября 2013 г.
  58. ^ «Имена ссылок на символические ссылки, метаданные ссылок на жесткие ссылки и справочные данные ссылок» . Pixelbeat.org . 27 октября 2010 г. Проверено 17 октября 2013 г.
  59. ^ Мейеринг, Джим (20 августа 2009 г.). «НОВОСТИ GNU coreutils: заслуживающие внимания изменения в версии 7.5» . savannah.gnu.org . Проверено 30 августа 2009 г.
  60. ^ Скривано, Джузеппе (1 августа 2009 г.). «cp: принять опцию --reflink» . savannah.gnu.org . Проверено 2 ноября 2009 г.
  61. ^ ioctl_fideduperange(2) – Linux программиста Руководство – Системные вызовы
  62. ^ Jump up to: а б с д «Руководство системного администратора — документация Btrfs» . ядро.орг . Проверено 31 октября 2013 г.
  63. ^ Jump up to: а б с «5.6 Создание подтомов и снимков [требует обновления]» . oracle.com . 2013 . Проверено 31 октября 2013 г.
  64. ^ «Ошибки — btrfs Wiki» . btrfs.wiki.kernel.org .
  65. ^ Jump up to: а б «5.7 Использование функции отправки/получения» . oracle.com . 2013 . Проверено 31 октября 2013 г.
  66. ^ Jump up to: а б с д Мейсон, Крис (25 июня 2015 г.). «Преобразование из Ext3 (документация Btrfs)» . ядро.орг . Проверено 22 апреля 2016 г.
  67. ^ «btrfs-convert(8) — Документация BTRFS» . Проверено 16 октября 2022 г.
  68. ^ «Семенное устройство» . Архивировано из оригинала 12 июня 2017 года . Проверено 1 августа 2017 г.
  69. ^ Мейсон, Крис (5 апреля 2012 г.), Файловая система Btrfs: состояние и новые возможности , Linux Foundation , получено 16 ноября 2012 г. [ постоянная мертвая ссылка ]
  70. ^ Макферсон, Аманда (22 июня 2009 г.). «Разговор с Крисом Мейсоном о BTRfs: файловой системе следующего поколения для Linux» . Фонд Linux . Архивировано из оригинала 27 июня 2012 года . Проверено 9 октября 2014 г. В будущих выпусках мы планируем добавить онлайн-fsck, дедупликацию, шифрование и другие функции, которые уже давно были в списках пожеланий администраторов.
  71. ^ Стерба, Дэвид. «файловые системы с аутентификацией с использованием HMAC(SHA256)» . Лор.Kernel.org . Проверено 25 апреля 2020 г.
  72. ^ "btrfs-check(8)" . btrfs.readthedocs.io .
  73. ^ «Как восстановить ошибки BTRFS | Поддержка | SUSE» . www.suse.com . Проверено 28 января 2023 г.
  74. ^ «Восстановить — btrfs Wiki» . btrfs.wiki.kernel.org .
  75. ^ «btrfs-restore(8) — страница руководства Linux» . man7.org . Проверено 28 января 2023 г.
  76. ^ «Часто задаваемые вопросы по проблемам — btrfs Wiki» . ядро.орг . 31 июля 2013 года . Проверено 16 января 2014 г.
  77. ^ «kernel/git/torvalds/linux.git: Документация: файловые системы: добавить новые параметры монтирования btrfs (дерево исходного кода ядра Linux)» . ядро.орг . 21 ноября 2013 года . Проверено 6 февраля 2014 г.
  78. ^ «Параметры монтирования — btrfs Wiki» . ядро.орг . 12 ноября 2013 года . Проверено 16 января 2014 г.
  79. ^ Jump up to: а б с Аврора, Валери (22 июля 2009 г.). «Краткая история btrfs» . LWN.net . Проверено 5 ноября 2011 г.
  80. ^ Райзер, Ганс (7 декабря 2001 г.). «Re: Индекс каталога Ext2: документ ALS и тесты» . Список рассылки разработчиков ReiserFS . Проверено 28 августа 2009 г.
  81. ^ Мейсон, Крис. «Акп» . Персональная веб-страница Oracle . Архивировано из оригинала 16 мая 2021 года . Проверено 5 ноября 2011 г.
  82. ^ Фаше, Марк (9 октября 2012 г.). «btrfs: расширенные ссылки на индексные дескрипторы» . Архивировано из оригинала 15 апреля 2013 года . Проверено 7 ноября 2012 г.
  83. ^ Торвальдс, Линус (10 октября 2012 г.). «Получить обновление btrfs от Криса Мейсона» . git.kernel.org . Архивировано из оригинала 15 апреля 2013 года . Проверено 7 ноября 2012 г.
  84. ^ Ларабель, Майкл (24 декабря 2010 г.). «Эталоны опции пространственного кэша Btrfs» . Фороникс . Проверено 16 ноября 2012 г.
  85. ^ «Часто задаваемые вопросы — btrfs Wiki: Какую функцию контрольной суммы использует Btrfs?» . Проект btrfs . Проверено 22 ноября 2020 г.
  86. ^ Jump up to: а б Бирман, Маргарет; Гриммер, Ленц (август 2012 г.). «Как я использую расширенные возможности Btrfs» . Проверено 20 сентября 2013 г.
  87. ^ Солтер, Джим (15 января 2014 г.). «Битро и атомные коровы: внутри файловых систем следующего поколения» . Арс Техника . Проверено 15 января 2014 г.
  88. ^ Кукартс, Вим (28 сентября 2011 г.). «Btrfs Scrub – исправьте повреждения с помощью зеркальных копий, пожалуйста!» . Оракул . Проверено 20 сентября 2013 г.
  89. ^ «Глоссарий» . Btrfs вики . Архивировано из оригинала 31 июля 2021 года . Проверено 31 июля 2021 г.
  90. ^ «Manpage/mkfs.btrfs» . Btrfs вики . Профили . Проверено 31 июля 2021 г.
  91. ^ Мейсон, Крис; Роде, Охад; Бачик, Йозеф (9 июля 2012 г.), BTRFS: Файловая система B-дерева Linux (PDF) , IBM Research , получено 12 ноября 2012 г.
  92. ^ Мейсон, Крис (30 апреля 2008 г.). «Поддержка нескольких устройств» . Btrfs вики . Архивировано из оригинала 20 июля 2011 года . Проверено 5 ноября 2011 г.
  93. ^ Бартелл, Шон (20 апреля 2010 г.). «Re: Восстановление раздела BTRFS» . linux-btrfs (список рассылки).
  94. ^ «Oracle теперь поддерживает Btrfs RAID5/6 в своем нерушимом корпоративном ядре — Phoronix» . Фороникс.com .
  95. ^ «Управление Btrfs в Oracle Linux 8» . docs.oracle.com . Проверено 6 июня 2020 г. [ мертвая ссылка ]
  96. ^ «SUSE подтверждает поддержку Btrfs» . LWN.net .
  97. ^ «Примечания к выпуску SUSE Linux Enterprise Server 12» . SUSE.com . Проверено 28 февраля 2021 г.
  98. ^ «Белая книга облачной станции» (PDF) . Synology.com . Синология . п. 11. Архивировано из оригинала (PDF) 11 ноября 2020 года . Проверено 2 апреля 2021 г. Начиная с DSM 6.0, тома данных можно форматировать как Btrfs.
  99. ^ «Btrfs устарел в RHEL | Hacker News» . Новости.YCombinator.com .
  100. ^ «Red Hat, похоже, отказывается от своих надежд на успех — Фороникс» . Фороникс.com .
  101. ^ Андреас Йегер (15 февраля 2005 г.). «Поддержка больших файлов в Linux» . пользователи.suse.com . Архивировано из оригинала 23 июля 2015 года . Проверено 12 августа 2015 г.
  102. ^ «Справка по настройке ядра Linux для CONFIG_LBD в версии 2.6.29 на x86» . ядро.xc.net . Архивировано из оригинала 6 сентября 2015 года . Проверено 12 августа 2015 г.
[ редактировать ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Btrfs&oldid=1230073101"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: b41a2cb5abc615a561885a683c3557db__1718879280
URL1:https://arc.ask3.ru/arc/aa/b4/db/b41a2cb5abc615a561885a683c3557db.html
Заголовок, (Title) документа по адресу, URL1:
Btrfs - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)