Btrfs (Русский)

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

Из документации Btrfs:

Btrfs — это современная файловая система для Linux, использующая принцип «копирование при записи» (CoW), направленная на реализацию дополнительных функций с особым упором на отказоустойчивость, восстановление и простоту администрирования.

Примечание: Как и некоторые другие файловые системы, Btrfs находится в активной разработке. Это означает, что некоторые функции могут быть ещё не готовы к повседневному использованию. Чтобы узнать, может ли это повлиять на ваш вариант использования, проверьте страницу Status в документации 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 фатально несовершенны и не должны использоваться для чего-либо, кроме тестирования на данных, которые не жалко потерять. Список известных проблем и частичных обходных путей. Актуальную информацию о статусе можно посмотреть здесь: btrfs(5) § RAID56 STATUS AND RECOMMENDED PRACTICES.

Можно использовать несколько устройств для создания 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, systemd или btrfs, чтобы использовать несколько устройств Btrfs в пуле. Дополнительную информацию смотрите в статье mkinitcpio (Русский)#Доступные хуки.

После создания файловой системы рекомендуется выполнить следующую команду для сканирования файловых систем Btrfs на нескольких устройствах и их регистрации, что позволит монтировать файловую систему с несколькими устройствами, указав только одно из устройств:

# btrfs device scan

Примечание:

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

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

Профили

Btrfs использует концепцию профилей для настройки зеркалирования, чётности и чередования. В стандартной терминологии RAID это называется уровнем RAID. Профили для метаданных (опция -m команды mkfs.btrfs(8)) и данных (опция -d команды mkfs.btrfs(8)) могут быть разными в пределах одной файловой системы.

Некоторые примечательные профили:

single: Без зеркалирования, без чередования, без чётности, позволяет объединить несколько устройств в одну файловую систему, что в терминологии mdadm называется LINEAR.
raid0: Без зеркалирования, с чередованием, без чётности, обеспечивает параллельный доступ между устройствами, но не ограничивается устройствами одного размера, как традиционный mdadm RAID.
raid1: С зеркалированием, без чередования, без чётности, позволяет выполнить восстановление после отказа одного диска.

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

Копирование при записи (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, как описано ниже, работать не будут.

Влияние на снимки

Если для файла отключено копирование при записи (NOCOW) и сделан снимок, то первая запись в блок файла после создания снимка будет COW-операцией, поскольку снимок блокирует старые блоки файла на своих местах. Однако файл сохранит атрибут NOCOW, и все последующие записи будут выполняться в одни и те же блоки файла до момента создания следующего снимка.

Частые снимки могут снизить эффективность NOCOW, так как при первой записи всё равно требуется COW. Чтобы полностью избежать COW-операций для таких файлов, поместите их в отдельный подтом и не создавайте снимки этого подтома.

Сжатие

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

LZO имеет фиксированный уровень сжатия, в то время как zlib и zstd имеют диапазон уровней сжатия от 1 (слабое сжатие) до 9 (zlib) или 15 (zstd); смотрите btrfs(5) § COMPRESSION. Изменение уровней по-разному влияет нагрузку процессора и пропускную способность ввода-вывода, поэтому стоит проверять производительность до и после изменения.

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

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

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

Чтобы применить сжатие к существующим файлам, используйте команду 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 property set файл compression алгоритм. Первая команда использует старый интерфейс атрибутов файлов, который унаследован от файловой системы ext2 и не является гибким, поэтому по умолчанию устанавливается сжатие zlib. Вторая команда устанавливает свойство файла с заданным алгоритмом (установка уровня сжатия таким способом пока не реализована). Если применить это к каталогу, то файлы, создаваемые в этом каталоге, будут автоматически сжиматься.

Важно:

Системы, использующие старые ядра или 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. Доступ к этому пространству имён может осуществляться через подтом верхнего уровня, или он может быть смонтирован сам по себе. [5]

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

При монтировании файловой системы Btrfs по умолчанию монтируется подтом верхнего уровня. При желании вместо него можно смонтировать другой подтом.

Одно из основных применений подтомов — #Снимки.

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

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

Для создания подтома файловая система Btrfs должна быть примонтирована. Последний аргумент команды будет названием подтома.

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

Примечание: Можно использовать опцию --parents для автоматического создания родительских каталогов, если они не существуют.

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

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

# btrfs subvolume list -p путь

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

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

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

Также можно удалить подтом как обычный каталог командами вроде 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, 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 [6].

Квоты

Важно: 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 может освобождать неиспользуемые блоки с твердотельного накопителя, поддерживающего команду TRIM. Поддерживается асинхронный discard, который доступен в виде опции монтирования discard=async и включен по умолчанию в linux 6.2. Незанятые экстенты не освобождаются сразу, а группируются и освобождаются позже в отдельном потоке, что улучшает задержки при записи на диск.

Асинхронный discard можно безопасно использовать вместе с периодическим TRIM [7].

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

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

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

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

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

# btrfs subvolume create /swap

Совет: Рассмотрите возможность создания подтома непосредственно под подтомом верхнего уровня, например @swap. Затем убедитесь, что подтом смонтирован в /swap (или любое другое доступное место).

Создайте файл подкачки:

# btrfs filesystem mkswapfile --size 4g --uuid clear /swap/swapfile

Без опции --size по умолчанию будет создан файл размером 2 ГиБ.

Включите файл подкачки:

# swapon /swap/swapfile

Наконец, отредактируйте файл fstab, добавив в него новую запись для этого файла подкачки:

/etc/fstab

/swap/swapfile none swap defaults 0 0

Примечание: Также можно создать файл подкачки вручную, отключив CoW для него и выполнив шаги, описанные в разделе Файл подкачки#Создание файла подкачки. Альтернативный метод описан в 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 /точка/монтирования

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

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

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

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

# btrfs filesystem defragment -r /

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

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

RAID

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

Важно: В коде Parity RAID (RAID 5/6) есть несколько серьёзных ошибок, приводящих к потере данных. Более подробную информацию смотрите на странице RAID5/6 в документации Btrfs и в сообщении об ошибке в 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, если устройство вышло из строя». [9] Смотрите Btrfs FAQ.

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

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

Снимки

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

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

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

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

Примечание:

Можно преобразовать снимок, доступный только для чтения, в снимок с возможностью записи командой btrfs property set -f -ts '/путь/к/снимку' ro false. Однако это не рекомендуется, поскольку это вызывает проблемы с любой будущей инкрементной отправкой/получением. Создание нового снимка с возможностью записи предотвращает такие проблемы.
Снимки не являются рекурсивными. Каждый вложенный подтом будет пустым каталогом внутри снимка.

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

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

# btrfs send /root_backup | btrfs receive /backup

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

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

Другой пример, который создаёт /mnt/arch-v2/subvolumes/@var:

# btrfs send --proto 2 --compressed-data '/mnt/arch/snapshots/@var' | btrfs receive '/mnt/arch-v2/subvolumes/'

Параметры --proto 2 и --compressed-data позволяют передавать данные более эффективно (если они хранятся в сжатом виде).

Вы также можете отправить только разницу между двумя снимками. Например, если вы уже отправили копию 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. Также может потребоваться просто дедуплицировать данные на уровне файлов, используя, например, rmlint, jdupes^AUR или dduper-git^AUR. Обзор возможностей этих программ и дополнительную информацию можно найти в Btrfs Wiki.

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

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

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

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

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

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

# btrfs filesystem resize max /

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

# btrfs filesystem resize размер /

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

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

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

Перед использованием Btrfs стоит узнать об имеющихся ограничениях.

Шифрование

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

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

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

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

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

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

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

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

Невозможно разместить другие файловые системы на другом разделе того же диска.
В связи с предыдущим пунктом размещение системного раздела EFI на этом диске невозможно. Для загрузки с UEFI необходимо другое устройство.

Чтобы удалить существующую таблицу разделов и вместо неё записать файловую систему 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 есть много сообщений о некорректном преобразовании. Убедитесь, что у вас есть рабочие резервные копии всех данных, которые вы не можете позволить себе потерять. Смотрите страницу Convert на 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 часов.

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

Важно: Инструмент 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-git^AUR.
При использовании rEFInd вы можете автоматически заполнить меню загрузчика снимками Btrfs с помощью refind-btrfs^AUR после включения службы 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 || btrbk

snap-sync — Использование снимков Snapper для резервного копирования на внешний диск или удалённую машину.

https://github.com/wesbarnett/snap-sync || snap-sync

snapsync — Инструмент синхронизации для Snapper.

https://github.com/doudou/snapsync || ruby-snapsync^AUR

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

snapborg — borgmatic-подобный инструмент, который интегрирует снимки snapper с резервными копиями borg.

https://github.com/enzingerm/snapborg || snapborg^AUR

Автоматические снимки

Для управления снимками Btrfs и автоматического их создания можно использовать менеджер снимков, например Snapper, Timeshift или Yabsnap.

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

Смотрите также Btrfs Troubleshooting pages и 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. Однако этот инструмент ещё не доработан и не может исправить некоторые ошибки файловой системы, даже те, которые не делают файловую систему немонтируемой.

Диск постоянно активен

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

Начиная с версии ядра 6.3, для решения этой проблемы стандартный лимит iops_limit для discard был изменён со 100 на 1000. На старых версиях ядра можно вручную установить нужное значение:

# echo 1000 > /sys/fs/btrfs/uuid/discard/iops_limit

Где uuid — это UUID файловой системы Btrfs. Со значением 1000 можно поэкспериментировать.

Чтобы значение устанавливалось при загрузке системы, можно использовать systemd-tmpfiles:

/etc/tmpfiles.d/btrfs-discard.conf

w /sys/fs/btrfs/uuid/discard/iops_limit - - - - 1000

Или можно полностью отключить асинхронный discard, добавив опцию монтирования nodiscard в файл fstab, а вместо него использовать периодический TRIM.

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

Официальный сайт
- Документация Btrfs
- Btrfs Wiki (архив)
О производительности
Разное
- Funtoo:BTRFS Fun
- Ави Миллер представляет Btrfs на SCALE 10x, январь 2012 г.
- Резюме выступления Криса Мейсона с LFCS 2012 г.
- Btrfs: stop providing a bmap operation to avoid swapfile corruptions 2009-01-21
- Doing Fast Incremental Backups With Btrfs Send and Receive