Btrfs (Русский)

From ArchWiki
Состояние перевода: На этой странице представлен перевод статьи Btrfs. Дата последней синхронизации: 22 ноября 2022. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

Ссылки по теме

Из Btrfs Wiki:

Btrfs — это современная файловая система для Linux, использующая принцип «копирование при записи» (CoW), направленная на реализацию дополнительных функций с особым упором на отказоустойчивость, восстановление и простоту администрирования. Совместно разработанная несколькими компаниями, Btrfs лицензирована под GPL и открыта для участия всех желающих.
Важно: Некоторые функции Btrfs нестабильны. Подробнее на Btrfs Wiki: Статус, Стабилен ли Btrfs? и Начало работы. Смотрите раздел #Известные проблемы.

Подготовка

Для утилит пользовательского пространства установите пакет btrfs-progs, который необходим для базовых операций.

Если вам нужно загрузиться с файловой системы Btrfs (то есть ядро и initramfs находятся на разделе Btrfs), проверьте, имеет ли ваш загрузчик поддержку Btrfs.

Создание файловой системы

Этот раздел демонстрирует, как создать новую файловую систему Btrfs. Также можно выполнить #Преобразование Ext3/4 в Btrfs или сделать #Диск Btrfs без разделов.

Дополнительная информация доступна man-странице mkfs.btrfs(8).

Файловая система на одном устройстве

Чтобы создать файловую систему Btrfs на разделе /dev/раздел: 

# mkfs.btrfs -L метка /dev/раздел

Размер узла для метаданных по умолчанию составляет 16 КБ, а размер сектора по умолчанию для данных равен размеру страницы и определяется автоматически. Чтобы использовать больший размер узла для метаданных (он должен быть кратен размеру сектора, допускается до 64 КБ), укажите значение nodesize с помощью опции -n, как показано в этом примере с блоками по 32 КБ: 

# mkfs.btrfs -L метка -n 32k /dev/раздел
Примечание: Согласно mkfs.btrfs(8) § OPTIONS, «меньший размер узла увеличивает фрагментацию, но приводит к использованию более высоких b-деревьев, что, в свою очередь, приводит к меньшей конкуренции при блокировке. Больший размер узла дает лучшую упаковку и меньшую фрагментацию ценой более дорогих операций с памятью при обновлении блоков метаданных».

Файловая система на нескольких устройствах

Важно: Режимы RAID 5 и RAID 6 в Btrfs фатально несовершенны и не должны использоваться для чего-либо, кроме тестирования на данных, которые не жалко потерять. Список известных проблем и частичных обходных путей. Актуальную информацию о статусе можно посмотреть на странице о RAID5 и RAID6 в Btrfs Wiki.

Можно использовать несколько устройств для создания RAID-массива. Поддерживаются уровни RAID 0, RAID 1, RAID 10, RAID 5 и RAID 6. Начиная с ядра 5.5, поддерживаются RAID1c3 и RAID1c4 для 3- и 4- копий уровня RAID 1. Уровни RAID могут быть настроены отдельно для данных и метаданных с помощью опций -d и -m соответственно. По умолчанию данные имеют одну копию (single), а метаданные зеркалируются (raid1). Это похоже на создание конфигурации JBOD, где диски воспринимаются как одна файловая система, но файлы не дублируются. Дополнительная информация о создании Btrfs RAID есть на странице Using Btrfs with Multiple Devices. 

# mkfs.btrfs -d single -m raid1 /dev/раздел1 /dev/раздел2 ...

В /etc/mkinitcpio.conf необходимо включить либо хук udev, либо хук btrfs, чтобы использовать несколько устройств Btrfs в пуле. Дополнительную информацию смотрите в статье mkinitcpio (Русский)#Доступные хуки.

Примечание:
  • Существует возможность добавлять дополнительные устройства в файловую систему с несколькими устройствами после её создания. Дополнительную информацию смотрите в Btrfs wiki.
  • Устройства могут быть разных размеров. Однако если один из дисков в конфигурации RAID больше остальных, то дополнительное пространство не будет использоваться.
  • Некоторые загрузчики, такие как Syslinux, не поддерживают файловые системы на нескольких устройствах.
  • Btrfs не пытается выбирать самое быстрое устройство для чтения, поэтому совместное использование разных типов дисков приводит к нестабильной производительности. [1]

Советы по обслуживанию файловых систем на нескольких устройствах приведены в разделе #RAID.

Настройка файловой системы

Копирование при записи (CoW)

По умолчанию Btrfs постоянно использует копирование при записи (copy-on-write) для всех файлов. Когда выполняется операция записи, новые данные не записываются поверх старых; вместо этого модифицированная копия блока записывается в новое место, а метаданные обновляются, чтобы указать на новое место. Подробности реализации, а также преимущества и недостатки описаны на странице Btrfs Sysadmin Guide.

Отключение CoW

Важно: Отключение CoW в Btrfs также отключает контрольные суммы. Btrfs не сможет обнаружить повреждения в nodatacow файлах. В сочетании с RAID 1 перебои в электропитании или другие причины повреждений могут привести к рассинхронизации данных.

Чтобы отключить копирование при записи для создаваемых файлов в примонтированном подтоме, используйте опцию монтирования nodatacow. Это повлияет только на новые файлы. Для существующих файлов копирование при записи всё равно будет происходить. Опция nodatacow также отключает сжатие. Подробности смотрите в btrfs(5).

Примечание: Из btrfs(5) § MOUNT OPTIONS:
в рамках одной файловой системы невозможно монтировать одни подтома с nodatacow, а другие с datacow. Опция монтирования первого смонтированного подтома применяется ко всем остальным подтомам.

Чтобы отключить копирование при записи для отдельных файлов/каталогов, выполните: 

$ chattr +C /каталог/файл

Это отключит копирование при записи для тех операций, в которых существует только одна ссылка на файл. Если ссылок больше одной, например, из-за клонирования файлов / облегчённых клонов или снимков файловой системы, копирование при записи всё равно будет происходить. Начиная с coreutils 9.0, cp пытается создавать облегчённые копии по умолчанию — смотрите cp(1) для более подробной информации.

Примечание: Из chattr(1):
При использовании btrfs флаг 'C' следует устанавливать для новых или пустых файлов. Если он установлен на файле, который уже имеет блоки данных, то неизвестно, когда блоки, назначенные файлу, станут полностью стабильными. Если флаг 'C' установлен для каталога, он не будет иметь никакого эффекта на каталог, но новые файлы, создаваемые в этом каталоге, будут иметь атрибут No_COW.
Совет: В соответствии с примечанием выше, вы можете использовать следующий трюк, чтобы отключить копирование при записи для существующих файлов в каталоге: 
$ mv /путь/к/каталогу /путь/к/каталогу_old
$ mkdir /путь/к/каталогу
$ chattr +C /путь/к/каталогу
$ cp -a --reflink=never /путь/к/каталогу_old/. /путь/к/каталогу
$ rm -rf /путь/к/каталогу_old
Убедитесь, что данные не используются во время этого процесса. Также обратите внимание, что mv или cp без --reflink=never, как описано ниже, работать не будут.

Сжатие

Btrfs поддерживает прозрачное и автоматическое сжатие. Это уменьшает размер файлов, а также значительно увеличивает срок службы флеш-носителей благодаря уменьшению их износа. Смотрите Fedora:Changes/BtrfsByDefault#Compression, [2] и [3]. Это также может улучшить производительность в одних случаях (например, однопоточные задачи с интенсивным файловым вводом-выводом), но в то же время ухудшить производительность в других случаях (например, многопоточные задачи и/или задачи с нагрузкой на процессор и большим файловым вводом-выводом). Более высокая производительность обычно достигается при использовании самых быстрых алгоритмов сжатия, zstd и lzo, и некоторые бенчмарки предоставляют подробные сравнения.

LZO имеет фиксированный уровень сжатия, в то время как ZLIB и ZSTD имеют диапазон уровней сжатия от 1 (слабое сжатие) до 9 (ZLIB) или 15 (ZSTD)[4]. Изменение уровней по-разному влияет нагрузку процессора и пропускную способность ввода-вывода, поэтому стоит проверять производительность до и после изменения.

Опция монтирования compress=алгоритм[:уровень] позволяет включить сжатие, где алгоритм — это либо zlib, lzo, zstd, либо no (без сжатия). При использовании этой опции btrfs будет проверять, помогает ли сжатие первой порции данных в файле сэкономить место. Если да, то весь файл будет сжат; если нет, то сжатие использоваться не будет. Таким образом, если первая часть записи не уменьшится при сжатии, то весь файл не будет сжат, даже если остальные остальные порции данных сжимаются хорошо. [5]. Это сделано для того, чтобы не заставлять диск ждать начала записи, пока все записываемые данные не будут полностью переданы btrfs и сжаты.

Также можно использовать другую опцию монтирования compress-force=алгоритм[:уровень], которая заставляет btrfs пропустить проверку сжимаемости первой порции данных и включает автоматическую попытку сжатия для каждого файла. В худшем случае это может привести к (незначительному) бесполезному увеличению загрузки процессора. Однако эмпирическое тестирование на нескольких системах смешанного использования показало значительное улучшение примерно на 10% сжатия диска при использовании compress-force=zstd по сравнению с просто compress=zstd, который также имел 10% сжатие диска.

Будут сжиматься только файлы, созданные или изменённые после добавления опции монтирования.

Чтобы применить сжатие к существующим файлам, используйте команду btrfs filesystem defragment -cалгоритм, где алгоритм — это zlib, lzo или zstd. Например, чтобы сжать всю файловую систему с помощью zstd, выполните следующую команду: 

# btrfs filesystem defragment -r -v -czstd /
Важно: Дефрагментация файла, имеющего CoW-копию (либо снимок, либо копию, сделанную с помощью cp или bcp), плюс использование ключа -c с алгоритмом сжатия может привести к появлению двух не связанных друг с другом файлов, что приведёт к увеличению использования места на диске.

Чтобы включить сжатие при установке Arch на пустой раздел Btrfs, используйте опцию compress при монтировании файловой системы: mount -o compress=zstd /dev/sdxY /mnt/. Во время настройки свежеустановленной системы добавьте compress=zstd в опции монтирования корневой файловой системы в файле fstab.

Совет: Сжатие также может быть включено для отдельных файлов без использования опции монтирования compress; для этого примените chattr +c к файлу. Если применить это к каталогу, то файлы, создаваемые в этом каталоге, будут автоматически сжиматься.
Важно:
  • Системы, использующие старые ядра или btrfs-progs без поддержки zstd, могут быть не в состоянии прочитать или восстановить вашу файловую систему, если вы используете эту опцию.
  • Поддержка zstd в GRUB появилась в версии 2.04. Убедитесь, что у вас обновлён код загрузчика, установленный в MBR/ESP, запустив grub-install с соответствующими опциями для вашей настройки BIOS/UEFI, поскольку это не выполняется автоматически. Смотрите FS#63235.

Просмотр типов и коэффициентов сжатия

compsize берёт список файлов (или всю файловую систему btrfs) и смотрит используемые типы сжатия и эффективные коэффициенты сжатия. Размер без сжатия может не совпадать с числом, выдаваемым другими программами, такими как du(1), потому что каждый экстент считается один раз, даже если на него есть несколько ссылок и даже если часть его больше нигде не используется, но ещё не была убрана при сборке мусора. Опция -x ограничивает анализ одной файловой системой, что полезно в ситуациях типа compsize -x /, чтобы предотвратить попытки программы просканировать не-btrfs подкаталоги.

Подтома

В btrfs подтом (subvolume) не является блочным устройством (и не может рассматриваться как устройство); вместо этого можно рассматривать подтом btrfs как пространство имён файлов POSIX. Доступ к этому пространству имён может осуществляться через подтом верхнего уровня, или он может быть смонтирован сам по себе. [6]

Каждая файловая система Btrfs имеет подтом верхнего уровня с идентификатором 5. Он может быть смонтирован как / (по умолчанию), или вместо него может быть смонтирован другой подтом. Подтома можно перемещать в файловой системе, и они идентифицируются скорее по их идентификатору, чем по пути.

Более подробную информацию можно найти по следующим ссылкам:

Создание подтома

Чтобы создать подтом: 

# btrfs subvolume create /путь/к/подтому

Список подтомов

Чтобы просмотреть список текущих подтомов и их идентификаторы: 

# btrfs subvolume list -p путь

Удаление подтома

Чтобы удалить подтом: 

# btrfs subvolume delete /путь/к/подтому

Начиная с Linux 4.18, можно также удалять подтом как обычный каталог (rm -r, rmdir).

Монтирование подтомов

Подтома можно монтировать как разделы файловой системы, используя флаги монтирования subvol=/путь/к/подтому (путь указывается относительно подтома верхнего уровня) или subvolid=objectid. Например, вы можете иметь подтом с именем subvol_root и монтировать его как /. Можно имитировать традиционные разделы файловой системы, создавая различные подтома на верхнем уровне файловой системы и затем монтируя их в соответствующих точках монтирования. Предпочтительнее монтировать, используя subvol=/путь/к/подтому, а не через subvolid, поскольку subvolid может измениться при восстановлении из снимков, что потребует изменения настроек монтирования.

Совет: Изменение компоновки подтомов можно упростить, если не использовать подтом верхнего уровня (ID=5) в качестве / (что делается по умолчанию). Вместо этого создайте подтом для хранения фактических данных и смонтируйте его как /.
Примечание: Из btrfs(5) § MOUNT OPTIONS:
Большинство опций монтирования применяются ко всей файловой системе, и иметь силу будут только опции первого монтируемого подтома. Это связано с ограничениями текущей реализации и может измениться в будущем.

В Btrfs Wiki FAQ описано, какие опции монтирования можно применять для отдельных подтомов.

Смотрите Snapper#Suggested filesystem layout, Btrfs SysadminGuide#Managing Snapshots и Btrfs SysadminGuide#Layout для примеров схем файловых систем с использованием подтомов.

Примеры схем файловых систем с использованием подтомов можно посмотреть здесь: Snapper#Suggested filesystem layout, Btrfs SysadminGuide#Managing Snapshots, Btrfs SysadminGuide#Layout.

Полный список опций монтирования, специфичных для btrfs, описан в man-странице btrfs(5).

Монтирование подтома в качестве корня

Чтобы примонтировать определённый подтом как корневую файловую систему, добавьте его в параметры ядра: rootflags=subvol=/путь/к/подтому. Отредактируйте корневую точку монтирования в /etc/fstab, добавив опцию монтирования subvol=. Также можно указать id подтома (rootflags=subvolid=objectid как параметр ядра и subvolid=objectid как опция монтирования в /etc/fstab). Лучше использовать subvol=/путь/к/подтому, так как subvolid может меняться при восстановлении из снимков, что потребует изменения настроек монтирования, иначе система не сможет загрузиться.

Изменение подтома по умолчанию

Если опция монтирования subvol= не указана, будет монтироваться подтом по умолчанию. Чтобы изменить подтом, используемый по умолчанию, выполните команду: 

# btrfs subvolume set-default subvolume-id /

Чтобы найти subvolume-id, посмотрите #Список подтомов.

Примечание: После изменения подтома по умолчанию, если вы используете GRUB, вы должны снова запустить grub-install, чтобы загрузчик узнал об изменениях. Смотрите эту тему на форуме.

Изменение подтома по умолчанию с помощью btrfs subvolume set-default сделает верхний уровень файловой системы недоступным, хотя вы всё равно сможете примонтировать его с помощью опций монтирования subvol=/ или subvolid=5 [7].

Квоты

Важно: Qgroup ещё не стабильна, и сочетание квоты с очень большим количеством снимков подтомов может вызвать проблемы с производительностью, например, при удалении снимков. Кроме того, есть ещё несколько известных проблем.

Поддержка квот в Btrfs реализована на уровне подтомов с помощью групп квот, или qgroup: по умолчанию каждому подтому назначается группа квот в виде 0/subvolume_id. Однако при желании можно создать группу квот с любым номером.

Для использования групп квот необходимо сначала включить квоты командой 

# btrfs quota enable путь

С этого момента вновь созданные подтома будут контролироваться этими группами. Чтобы ретроспективно включить их для уже существующих подтомов, включите квоты как обычно, а затем создайте группу квот (qgroup) для каждого из этих подтомов, используя их subvolume_id, после чего просканируйте их: 

# btrfs subvolume list путь | cut -d' ' -f2 | xargs -I{} -n1 btrfs qgroup create 0/{} путь
# btrfs quota rescan путь

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

Ограничения на группах квот могут применяться либо к общему использованию данных, либо к использованию данных, которые не используются в других подтомах (уникальных данных, unshared), либо к использованию сжатых данных, либо к обоим. Копирование и удаление файлов могут влиять на лимиты, так как в других группах квот может измениться размер уникальных данных, если после удаления осталась единственная копия. Например, у свежего снимка почти все блоки общие с исходным подтомом, запись новых данных в любой из подтомов будет увеличивать размер уникальных данных в нём, и удаление общих данных в одном подтоме тоже увеличит размер уникальных данных в другом подтоме.

Чтобы применить ограничение к группе квот, используйте команду btrfs qgroup limit. В зависимости от использования вы можете использовать либо общий лимит, либо лимит на уникальные данные (-e), либо лимит на сжатые данные (-c). Чтобы посмотреть использование и лимиты для заданного пути в файловой системе, используйте 

# btrfs qgroup show -reF путь

Интервал записи на диск

Периодичность записи данных на диск диктуется самой Btrfs и общесистемными настройками. По умолчанию Btrfs устанавливает интервал между контрольными точками в 30 секунд, через который новые данные записываются на диск. Это можно изменить, добавив опцию монтирования commit в /etc/fstab для раздела btrfs. 

LABEL=arch64 / btrfs defaults,compress=zstd,commit=120 0 0

Общесистемные настройки также влияют на этот интервал. Это включает в себя файлы в /proc/sys/vm/* и выходит за рамки данной вики-статьи. Документация ядра о них доступна по адресу https://docs.kernel.org/admin-guide/sysctl/vm.html.

SSD TRIM

Файловая система Btrfs может освобождать неиспользуемые блоки с SSD диска, поддерживающего команду TRIM. С версии ядра 5.6 имеется поддержка асинхронного discard, что можно включить опцией монтирования discard=async. Незанятые экстенты не освобождаются сразу, а группируются и освобождаются позже в отдельном потоке, что улучшает задержки при записи на диск.

Дополнительная информация о включении и использовании TRIM есть в разделе Твердотельные накопители#TRIM.

Использование

Файл подкачки

Использование файлов подкачки на Btrfs поддерживаются с Linux 5.0.[8]. Правильный способ инициализации файла подкачки заключается в том, чтобы сначала создать подтом без снимков для размещения файла, а затем установить атрибут No_COW на весь каталог с помощью chattr. 

# chattr +C /путь/к/подтому

С этого момента любой новый файл, созданный внутри подтома для подкачки, будет иметь установленный атрибут No_COW.

Затем выполните шаги, описанные в разделе Файл подкачки#Создание файла подкачки. Настройка гибернации для файла подкачки описана в разделе Ждущий и спящий режимы#Гибернация в файл подкачки на Btrfs.

Примечание: Не поддерживаются файлы подкачки на файловых системах, которые охватывают несколько устройств. Смотрите btrfs(5) § SWAPFILE SUPPORT и обсуждение на форуме.

Отображение занятого/свободного места

Стандартные пользовательские инструменты linux, такие как df(1), будут неточно отображать свободное пространство на разделе Btrfs. Рекомендуется использовать btrfs filesystem usage для чтения информации о разделах Btrfs. Например, для получения полной статистики: 

# btrfs filesystem usage /точка/монтирования
Примечание: Команда btrfs filesystem usage в настоящее время работает некорректно с RAID5/RAID6.

В качестве альтернативы, btrfs filesystem df позволяет быстро проверить использование выделенного пространства без необходимости запуска от имени root: 

$ btrfs filesystem df /точка/монтирования

Смотрите [9] для более подробной информации.

Те же ограничения относятся к инструментам, анализирующим использование места в подмножестве файловой системы, таким как du(1) или ncdu(1), поскольку они не учитывают ссылки, снимки и сжатие. Вместо них используйте альтернативы с подержкой btrfs — btduAUR и compsize.

Дефрагментация

Важно: В ядре Linux версии 5.16.x < 5.16.5 присутствует регрессия, которая вызывает бесконечный цикл дефрагментации Btrfs на некоторых системах, влияя как на ручную, так и на автоматическую дефрагментацию. Это вызывает экстремальные нагрузки ввода-вывода на затронутые диски, что может сильно сократить срок их службы и повлиять на их производительность. Поэтому не рекомендуется использовать autodefrag в этих версиях, а лучше даже использовать noautodefrag, чтобы убедиться, что автоматическая дефрагментация отключена. Смотрите [10] и [11].

Btrfs поддерживает онлайн-дефрагментацию, которую можно включить опцией монтирования autodefrag, смотрите btrfs(5) § MOUNT OPTIONS. Чтобы вручную запустить дефрагментацию корневой файловой системы, используйте: 

# btrfs filesystem defragment -r /

Использование этой команды без ключа -r приведёт к дефрагментации только метаданных, хранящихся в указанном подтоме. Это позволяет дефрагментировать один файл, просто указав путь.

Важно: Дефрагментация файла, имеющего COW-копию (либо снимок, либо копию, созданную с помощью cp или bcp), плюс использование переключателя -c с алгоритмом сжатия может привести к появлению двух не связанных друг с другом файлов, что приведёт к увеличению использования места на диске.

RAID

#Файловая система на нескольких устройствах может использовать «RAID». Примечательными особенностями, которые отличают btrfs RAID от mdadm, являются самовосстанавливающиеся избыточные массивы и онлайн-балансировка. Дополнительная информация доступна на вики-странице Btrfs. На странице сисадмина Btrfs также есть раздел с более подробной технической информацией.

Важно: В коде Parity RAID (RAID 5/6) есть несколько серьёзных ошибок, приводящих к потере данных. Более подробную информацию смотрите на странице RAID5/6 в Btrfs Wiki и в сообщении об ошибке в linux-btrfs mailing list. В июне 2020 года был опубликован полный список текущих проблем и полезное руководство по восстановлению.

Scrub

В Btrfs Wiki Glossary говорится, что Btrfs scrub — это «онлайн-инструмент проверки файловой системы. Считывает все данные и метаданные в файловой системе, использует контрольные суммы и дубликаты копий из RAID-хранилища для выявления и восстановления повреждённых данных».

Примечание: Запущенный процесс scrub помешает уходу системы в сон, подробнее в этой теме.

Запуск вручную

Чтобы запустить scrub в фоне: 

# btrfs scrub start /

Чтобы проверить состояние scrub, работающего в фоне: 

# btrfs scrub status /

Запуск с помощью службы или таймера

Пакет btrfs-progs предоставляет юнит btrfs-scrub@.timer, запускающий ежемесячную проверку указанной точки монтирования. Включите таймер, указав экранированный путь, например, btrfs-scrub@-.timer для / и btrfs-scrub@home.timer для /home. Вы можете использовать systemd-escape -p /путь/к/точке/монтирования для экранирования пути, подробности смотрите в systemd-escape(1).

Вы также можете запустить scrub через службу btrfs-scrub@.service (тоже указав экранированный путь). Преимущество этого способа перед простым запуском команды btrfs scrub (от имени root) в том, что результаты проверки будут записаны в журнал systemd.

На больших NVMe-дисках с недостаточным охлаждением (например, в ноутбуке) scrub может считывать данные достаточно быстро и долго, чтобы диск сильно нагрелся. Если вы запускаете scrub с помощью systemd, вы можете легко ограничить скорость проверки с помощью опции IOReadBandwidthMax, описанной в systemd.resource-control(5), используя drop-in файл.

Балансировка

«Балансировка повторно пропускает все данные в файловой системе через аллокатор. В первую очередь он предназначен для перебалансировки данных в файловой системе между устройствами, когда устройство добавляется или удаляется. Балансировка восстанавливает недостающие копии для избыточных уровней RAID, если устройство вышло из строя». [12] Смотрите Btrfs FAQ.

В файловой системе с одним устройством балансировка может быть также полезна для (временного) уменьшения количества выделенных, но неиспользуемых (мета)чанков данных. Иногда это необходимо для устранения проблем «filesystem full». 

# btrfs balance start --bg /
# btrfs balance status /

Снимки

«Снимок (снапшот) — это просто подтом, который имеет общие данные (и метаданные) с другим подтомом, используя возможности COW в btrfs». (Btrfs Wiki SysadminGuide)

Создание снимка: 

# btrfs subvolume snapshot источник [назначение/]название

Для создания снимка, доступного только для чтения, добавьте флаг -r. Чтобы создать доступную для записи версию снимка, доступного для чтения, просто создайте его снимок.

Примечание:
  • Можно преобразовать снимок, доступный только для чтения, в снимок с возможностью записи. Однако это не рекомендуется, поскольку это вызывает проблемы с любой будущей инкрементной отправкой/получением. Создание нового снимка с возможностью записи предотвращает такие проблемы.
  • Снимки не являются рекурсивными. Каждый вложенный подтом внутри снимка будет пустым каталогом.

Отправка/получение

Подтом может быть отправлен в стандартный вывод или в файл с помощью команды send. Обычно это используется для передачи в btrfs-команду receive. Например, для отправки снимка с именем /root_backup (это может быть снимок, который вы сделали ранее из /) в /backup, можно выполнить следующую команду: 

# btrfs send /root_backup | btrfs receive /backup

Отправляемый снимок должен быть доступен только для чтения. Приведённая выше команда полезна для копирования подтома на внешнее устройство (например, USB-диск, смонтированный по адресу /backup выше).

Вы также можете отправить только разницу между двумя снимками. Например, если вы уже отправили копию root_backup выше и сделали новый снимок, доступный только для чтения, с именем root_backup_new, то для отправки только изменённых данных в /backup можно выполнить следующую команду: 

# btrfs send -p /root_backup /root_backup_new | btrfs receive /backup

После этого в /backup появится новый подтом root_backup_new.

Смотрите статью Incremental Backup на Btrfs Wiki и #Инкрементное резервное копирование на внешний диск о том, как использовать это для инкрементного резервного копирования и об инструментах, автоматизирующих этот процесс.

Дедупликация

Используя копирование при записи (CoW), Btrfs может копировать файлы или целые подтома без фактического копирования данных. Однако каждый раз, когда файл изменяется, создаётся новая полноценная копия. Дедупликация делает ещё один шаг вперед, определяя блоки данных с общими последовательностями и объединяя их в экстент с той же семантикой копирования при записи.

Инструменты для дедупликации: duperemove, bees, bedupAUR и btrfs-dedup. Также может потребоваться просто дедуплицировать данные на уровне файлов, используя, например, rmlint, jdupesAUR или dduper-gitAUR. Обзор возможностей этих программ и дополнительную информацию можно найти в Btrfs Wiki.

Кроме того, разработчики Btrfs работают над синхронной (inband, inline) дедупликацией, то есть дедупликацией, выполняемой в момент записи новых данных в файловую систему. В настоящее время это всё ещё эксперимент, который разрабатывается отдельно. Пользователям, желающим протестировать новую функцию, следует ознакомиться с соответствующей вики-страницей.

Изменение размера

Важно: Во избежание потери данных убедитесь, что вы сделали резервную копию данных перед изменением размера.

Вы можете увеличить файловую систему до максимального доступного пространства или указать точный размер. Убедитесь, что вы увеличили размер устройства или логического тома, прежде чем пытаться увеличить размер файловой системы. При указании точного размера файловой системы убедитесь, что новый размер удовлетворяет следующим условиям:

  • Новый размер должен быть больше размера существующих данных; в противном случае произойдет потеря данных.
  • Новый размер должен быть равен или меньше текущего размера устройства, поскольку размер файловой системы не может выходить за пределы доступного пространства.
Примечание: Если вы планируете также уменьшить размер логического тома, на котором находится файловая система, убедитесь, что вы уменьшили размер файловой системы до того, как попытаетесь уменьшить размер устройства или логического тома.

Чтобы увеличить размер файловой системы до максимально доступного размера устройства: 

# btrfs filesystem resize max /

Чтобы расширить файловую систему до указанного размера: 

# btrfs filesystem resize размер /

Замените размер на желаемый размер в байтах. Вы также можете указать единицу измерения, например K (кибибайты), M (мебибайты) или G (гибибайты). В качестве альтернативы можно указать увеличение или уменьшение текущего размера, дополнив значение знаком плюс (+) или минус (-) соответственно: 

# btrfs filesystem resize +размер /
# btrfs filesystem resize -размер /

Известные проблемы

Несколько ограничений следует знать, прежде чем пробовать.

Шифрование

Btrfs не имеет встроенной поддержки шифрования, но это может появиться в будущем. Пользователи могут зашифровать раздел перед запуском mkfs.btrfs. Смотрите dm-crypt/Encrypting an entire system#Btrfs subvolumes with swap.

Существующие файловые системы Btrfs могут использовать что-то вроде EncFS или VeraCrypt, хотя, возможно, без некоторых возможностей Btrfs.

Проблемы проверки btrfs

Инструмент btrfs check имеет известные проблемы и не должен запускаться без чтения дополнительной информации, смотрите раздел #Проверка файловой системы.

Советы и рекомендации

Диск Btrfs без разделов

Важно: Большинству пользователей не нужен такой тип установки и вместо этого лучше установить Btrfs на обычный раздел. Кроме того, GRUB настоятельно не рекомендует установку на диск без разделов.

Btrfs можно разместить на всём устройстве целиком, без использования разметки разделов MBR или GPT, используя подтома для имитации разделов. Однако отказываться от разделов не обязательно, достаточно просто создать файловую систему Btrfs на существующем разделе, созданном обычным способом. Существуют некоторые ограничения при установке без разделов:

Чтобы удалить существующую таблицу разделов и вместо неё записать файловую систему Btrfs, выполните следующую команду: 

# mkfs.btrfs /dev/sdX

Указывайте путь к устройству целиком (например, /dev/sda), а не к отдельному разделу (/dev/sda1). Второй вариант отформатирует лишь указанный раздел, а не заменит всю разметку. Поскольку корневым разделом является Btrfs, убедитесь, что btrfs скомпилирован в ядро, или поместите btrfs в mkinitcpio MODULES и пересоберите образ initramfs.

Установите загрузчик как на MBR-устройство. Смотрите Syslinux (Русский)#Ручная установка или GRUB (Русский)#Установка BIOS-версии загрузчика. Если ядро не загружается с ошибкой Failed to mount /sysroot., добавьте GRUB_PRELOAD_MODULES="btrfs" в /etc/default/grub и пересоздайте файл настроек GRUB.

Преобразование Ext3/4 в Btrfs

Важно: В списке рассылки btrfs есть много сообщений о некорректной конвертации. Убедитесь, что у вас есть рабочие резервные копии всех данных, которые вы не можете позволить себе потерять. Смотрите статью Conversion from Ext3 на btrfs wiki для получения дополнительной информации.

Загрузитесь с установочного образа, а затем выполните конвертацию: 

# btrfs-convert /dev/раздел

Смонтируйте раздел и проверьте целостность файлов на сконвертированном разделе. Обязательно измените /etc/fstab, чтобы отразить изменения (type на btrfs и fs_passno [последнее поле] на 0, поскольку Btrfs не выполняет проверку файловой системы при загрузке). Также обратите внимание, что UUID раздела изменился, поэтому обновите fstab соответствующим образом при использовании UUID. Выполните chroot в систему и перенастройте загрузчик на использование сконвертированного раздела (смотрите статью Установка Arch из другого дистрибутива). Если вы преобразуете корневую файловую систему, то, пока вы ещё в chroot, запустите mkinitcpio -p linux для пересоздания образа initramfs, иначе система не сможет успешно загрузиться.

Примечание: Если что-то пошло не так или не удалось смонтировать или записать файлы на свежесконвертированной файловой системе, всегда есть возможность отката, пока резервный подтом /ext2_saved всё ещё присутствует. Для отката используйте команду btrfs-convert -r /dev/раздел, которая отменит все изменения в новой файловой системе btrfs.

Убедившись в отсутствии проблем, завершите преобразование, удалив резервный подтом ext2_saved. Обратите внимание, что без него вы не сможете вернуться к ext3/4. 

# btrfs subvolume delete /ext2_saved

Наконец, выполните балансировку, чтобы перераспределить место.

Помните, что некоторые приложения, которые были установлены ранее, должны быть адаптированы к Btrfs.

Примечание: Преобразование Ext3/4 в Btrfs — долгая операция. Например, для файловой системы 4 ТБ на обычном HDD она может занять до 10 часов.

Аппаратное ускорение контрольной суммы

В Intel SSE4.2 появилась новая инструкция CRC32. Чтобы проверить, является ли подсчёт контрольной суммы в Btrfs аппаратно ускоренным: 

# dmesg | grep crc32c
Btrfs loaded, crc32c=crc32c-intel

Если вы видите crc32c=crc32c-generic, это, вероятно, потому, что ваш корневой раздел — Btrfs, и вам придётся вкомпилировать crc32c-intel в ядро, чтобы заставить его работать. Вставка crc32c-intel в mkinitcpio.conf не работает.

Восстановление повреждённой файловой системы

Важно: Инструмент btrfs check имеет известные проблемы, смотрите раздел #Проверка файловой системы.

btrfs-check не может быть использован на смонтированной файловой системе. Чтобы иметь возможность использовать btrfs-check без загрузки с live USB, добавьте его в initramfs: 

/etc/mkinitcpio.conf
BINARIES=(btrfs)

Затем пересоберите образ initramfs.

Теперь, когда возникнут проблемы с загрузкой, эта утилита будет доступна в initramfs и позволит выполнить восстановление.

Примечание: Если проверка вынуждена инвалидировать кэш пространства (и/или другие кэши?), то это нормально, если последующая загрузка зависнет на некоторое время (может появиться консольное сообщение о зависании btrfs-transaction). Система должна восстановиться после этого через некоторое время.

Дополнительная информация доступна в btrfs-check(8).

Загрузка в снимок

Для загрузки в снимок применяется та же процедура, что и для монтирования подтома в качестве корневого раздела, как описано в разделе #Монтирование подтома в качестве корня, поскольку снимки можно монтировать как подтома.

  • При использовании GRUB вы можете автоматически добавить снимки btrfs в меню загрузки при регенерации файла настроек с помощью grub-btrfs или grub-btrfs-gitAUR.
  • При использовании rEFInd вы можете автоматически заполнить меню загрузчика снимками btrfs с помощью refind-btrfsAUR после включения службы refind-btrfs.service.

Использование подтомов Btrfs в systemd-nspawn

Смотрите Systemd-nspawn#Use Btrfs subvolume as container root и Systemd-nspawn#Use temporary Btrfs snapshot of container.

Уменьшение частоты записи метаданных при обновлении времени доступа

Из-за того, что Btrfs использует копирование при записи, простое чтение файла может вызвать копирование метаданных. Уменьшение частоты обновления времени доступа может устранить это непредвиденное использование диска и увеличить производительность. Опции монтирования, связанные с управлением временем доступа, описаны в разделе fstab (Русский)#Параметры atime.

Инкрементное резервное копирование на внешний диск

Следующие пакеты используют btrfs send и btrfs receive для инкрементной отправки резервных копий на внешний диск. Обратитесь к их документации, чтобы увидеть различия в реализации, возможностях и требованиях.

  • btrbk — Инструмент для создания снимков и удалённых резервных копий подтомов Btrfs.
https://github.com/digint/btrbk || btrbkAUR
  • buttersink — Как rsync для снимков Btrfs. Требуется Python 2.
https://github.com/AmesCornish/buttersink.git || buttersink-gitAUR
  • snap-sync — Использование снимков Snapper для резервного копирования на внешний диск или удалённую машину.
https://github.com/wesbarnett/snap-sync.git || snap-sync
  • snapsync — Инструмент синхронизации для Snapper.
https://github.com/doudou/snapsync || ruby-snapsyncAUR

Следующий пакет позволяет создавать резервные копии снимков snapper на файловые системы, отличные от Btrfs.

  • snapborg — borgmatic-подобный инструмент, который интегрирует снимки snapper с резервными копиями borg.
https://github.com/enzingerm/snapborg || snapborgAUR

Решение проблем

Смотрите также Btrfs Problem FAQ.

GRUB

Смещение раздела

Проблема со смещением может возникнуть при попытке внедрить core.img в диск с разделами. Это означает, что можно напрямую внедрить core.img от GRUB в пул Btrfs на диске без разделов (например, /dev/sdX) напрямую.

GRUB может загружать разделы Btrfs, однако модуль может быть больше, чем у других файловых систем. В результате файл core.img, который создаёт grub-install, может не поместиться в первые 63 сектора (31.5KiB) диска между MBR и первым разделом. Современные инструменты разметки, такие как fdisk и gdisk, позволяют избежать этой проблемы, смещая первый раздел примерно на 1 или 2 МиБ.

Корневая файловая система не найдена

Если возникает ошибка error no such device: root при загрузке с RAID-массива, то отредактируйте /usr/share/grub/grub-mkconfig_lib и уберите обе кавычки из строки echo " search --no-floppy --fs-uuid --set=root ${hints} ${fs_uuid}". Пересоздайте файл настроек GRUB, и после этого система должна загрузиться без ошибок.

Таймаут монтирования

Иногда, особенно на больших массивах RAID1, монтирование может прерваться во время загрузки с подобным сообщением в журнале: 

Jan 25 18:05:12 host systemd[1]: storage.mount: Mounting timed out. Terminating.
Jan 25 18:05:46 host systemd[1]: storage.mount: Mount process exited, code=killed, status=15/TERM
Jan 25 18:05:46 host systemd[1]: storage.mount: Failed with result 'timeout'.
Jan 25 18:05:46 host systemd[1]: Failed to mount /storage.
Jan 25 18:05:46 host systemd[1]: Startup finished in 32.943s (firmware) + 3.097s (loader) + 7.247s (kernel)>
Jan 25 18:05:46 host kernel: BTRFS error (device sda): open_ctree failed

Это можно легко обойти, установив более длительный таймаут с помощью специфичной для systemd опции монтирования x-systemd.mount-timeout в fstab. Например: 

/dev/sda                /storage    btrfs       rw,relatime,x-systemd.mount-timeout=5min  0 0

BTRFS: open_ctree failed

По состоянию на ноябрь 2014 года, похоже, существует ошибка в systemd или mkinitcpio, вызывающая следующую ошибку, если Btrfs размещён на нескольких устройствах и используется хук btrfs в mkinitcpio.conf: 

BTRFS: open_ctree failed
mount: wrong fs type, bad option, bad superblock on /dev/sdb2, missing codepage or helper program, or other error

In some cases useful info is found in syslog - try dmesg|tail or so.

You are now being dropped into an emergency shell.

Обходным решением является удаление btrfs из массива HOOKS в /etc/mkinitcpio.conf и добавление btrfs в массив MODULES. Затем пересоберите образ initramfs и перезагрузитесь.

Вы получите ту же ошибку, если попытаетесь смонтировать raid-массив без одного из устройств. В этом случае необходимо добавить опцию монтирования degraded в /etc/fstab. Если в массиве находится корневая файловая система, вы также должны добавить rootflags=degraded в параметры ядра.

По состоянию на август 2016 года, потенциальным обходным решением этой ошибки является монтирование массива только по одному диску в /etc/fstab и разрешение btrfs обнаруживать и добавлять остальные диски автоматически. Похоже, что сбою способствуют групповые идентификаторы, такие как UUID и LABEL. Например, массив RAID1 из двух устройств, состоящий из 'disk1' и disk2', будет иметь присвоенный ему UUID, но вместо UUID будет использоваться только /dev/mapper/disk1 в /etc/fstab. Более подробное объяснение смотрите в этой статье.

Другим возможным обходным решением является удаление хука udev в mkinitcpio.conf и замена его хуком systemd. В этом случае btrfs не должен находиться в массивах HOOKS или MODULES.

Смотрите тему на форуме и FS#42884 для более подробной информации.

Проверка файловой системы

Важно: Поскольку Btrfs находится в стадии интенсивной разработки, особенно команда btrfs check, настоятельно рекомендуется создать резервную копию и проконсультироваться с btrfs-check(8) перед выполнением btrfs check с ключом --repair.

Команда btrfs-check(8) может быть использована для проверки или восстановления размонтированной файловой системы Btrfs. Однако этот инструмент ещё не доработан и не может исправить некоторые ошибки файловой системы, даже те, которые не делают файловую систему немонтируемой.

Смотрите также

Retrieved from "https://wiki.archlinux.org/index.php?title=Btrfs_(Русский)&oldid=757781"