Btrfs/Настройка: различия между версиями

Материал из DZWIKI
Перейти к навигации Перейти к поиску
 
(не показано 6 промежуточных версий этого же участника)
Строка 17: Строка 17:
|archive-date = 2023-12-28
|archive-date = 2023-12-28
}}</ref>
}}</ref>
{{Notice|'''Примечание:''' Из [https://man.archlinux.org/man/btrfs.5#MOUNT_OPTIONS btrfs(5) § MOUNT OPTIONS]:<br>
в рамках одной файловой системы невозможно монтировать одни подтома с <code>nodatacow</code>, а другие с <code>datacow</code>. Опция монтирования первого смонтированного подтома применяется ко всем остальным подтомам.}}
Чтобы отключить копирование при записи для отдельных файлов/каталогов, выполните:
<syntaxhighlight lang="bash">
chattr +C /каталог/файл
</syntaxhighlight>
Это отключит копирование при записи для операций над файлами, на которые есть только одна ссылка. Если ссылок на файл больше одной, например, из-за клонирования файлов или облегчённых клонов или снимков файловой системы, копирование при записи всё равно будет происходить. Начиная с [[coreutils]] 9.0, [[cp]] пытается создавать облегчённые копии по умолчанию — смотрите [https://man.archlinux.org/man/cp.1 cp(1)] для более подробной информации.
{{Notice|'''Примечание:''' Из [https://man.archlinux.org/man/chattr.1 chattr(1)]:<br>
При использовании Btrfs флаг '<code>C</code>' следует устанавливать для новых или пустых файлов. Если он установлен на файле, который уже имеет блоки данных, то неизвестно, когда блоки, назначенные файлу, станут полностью стабильными. Если флаг '<code>C</code>' установлен для каталога, он не будет иметь никакого эффекта на каталог, но новые файлы, создаваемые в этом каталоге, будут иметь атрибут <code>No_COW</code>.
}}
{{Imbox
| type = notice
| text = '''Совет:''' В соответствии с примечанием выше, вы можете использовать следующий трюк, чтобы отключить копирование при записи для существующих файлов в каталоге:
<syntaxhighlight lang="bash">
mv /путь/к/каталогу /путь/к/каталогу_old
mkdir /путь/к/каталогу
chattr +C /путь/к/каталогу
cp -a --reflink=never /путь/к/каталогу_old/. /путь/к/каталогу
rm -rf /путь/к/каталогу_old
</syntaxhighlight>
Убедитесь, что данные не используются во время этого процесса.
Также обратите внимание, что <code>mv</code> или <code>cp</code> без <code>--reflink=never</code>, как описано ниже, работать не будут.
}}
==== Влияние на снимки ====
Если для файла отключено копирование при записи (NOCOW) и сделан [[Btrfs/Снимки|снимок]], то первая запись в блок файла после создания снимка [https://www.spinics.net/lists/linux-btrfs/msg33090.html будет COW-операцией], поскольку снимок блокирует старые блоки файла на своих местах. Однако файл сохранит атрибут NOCOW, и все последующие записи будут выполняться в одни и те же блоки файла до момента создания следующего снимка.
Частые снимки могут снизить эффективность NOCOW, так как при первой записи всё равно требуется COW. Чтобы полностью избежать COW-операций для таких файлов, поместите их в отдельный подтом и не создавайте снимки этого подтома.
== Сжатие ==
Btrfs поддерживает [https://btrfs.readthedocs.io/en/latest/Compression.html прозрачное и автоматическое сжатие]. Это уменьшает размер файлов, а также значительно увеличивает срок службы флеш-носителей благодаря уменьшению вызываемого записью износа.<ref>{{cite web
|url          = https://fedoraproject.org/wiki/Changes/BtrfsByDefault#Compression
|title        = Fedora:Changes/BtrfsByDefault#Compression
|lang        = en
|date        = 2021-02-03
|access-date  = 2024-01-07
|website      =
|archive-url  = https://web.archive.org/web/20231222112344/https://fedoraproject.org/wiki/Changes/BtrfsByDefault
|archive-date = 2023-12-22
}}</ref><ref>{{cite web
|url          = https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NTV77NFF6NDZM3QTPUM2TQZ5PCM6GOO2/
|title        = Btrfs by default, the compression option - devel - Fedora Mailing-Lists
|lang        = en
|date        = 2020-07-08
|access-date  = 2024-01-07
|website      =
|archive-url  = https://web.archive.org/web/20230324202057/https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NTV77NFF6NDZM3QTPUM2TQZ5PCM6GOO2/
|archive-date = 2023-03-24
}}</ref><ref>{{cite web
|url          = https://pagure.io/fedora-btrfs/project/issue/36#comment-701551
|title        = Issue #36: Write amplification [meta] - project - Pagure.io
|lang        = en
|date        = 2020-11-13
|access-date  = 2024-01-07
|website      =
|archive-url  = https://web.archive.org/web/20231226220223/https://pagure.io/fedora-btrfs/project/issue/36
|archive-date = 2023-12-26
}}</ref>
Это также может улучшить производительность<ref>{{cite web
|url          = https://www.phoronix.com/review/btrfs_compress_2635
|title        = Using Disk Compression With Btrfs To Enhance Performance - Phoronix
|lang        = en
|date        = 2010-08-28
|access-date  = 2024-01-07
|website      =
|archive-url  = https://web.archive.org/web/20230128092435/https://www.phoronix.com/review/btrfs_compress_2635
|archive-date = 2023-01-28
}}</ref> в одних случаях (например, однопоточные задачи с интенсивным файловым вводом-выводом), но в то же время ухудшить производительность в других случаях (например, многопоточные задачи и/или задачи с нагрузкой на процессор и большим файловым вводом-выводом). Более высокая производительность обычно достигается при использовании самых быстрых алгоритмов сжатия, [[zstd]] и [[lzo]], и некоторые бенчмарки<ref>{{cite web
|url          = https://www.phoronix.com/scan.php?page=article&item=btrfs-zstd-compress
|title        = Btrfs Zstd Compression Benchmarks On Linux 4.14 - Phoronix
|lang        = en
|date        = 2017-11-13
|access-date  = 2024-01-07
|website      =
|archive-url  = https://web.archive.org/web/20230708070016/https://www.phoronix.com/review/btrfs-zstd-compress
|archive-date = 2023-07-08
}}</ref> предоставляют подробные сравнения.
LZO имеет фиксированный уровень сжатия, в то время как zlib и zstd имеют диапазон уровней сжатия от 1 (слабое сжатие) до 9 (zlib) или 15 (zstd); смотрите [https://man.archlinux.org/man/btrfs.5#COMPRESSION btrfs(5) § COMPRESSION]. Изменение уровней по-разному влияет нагрузку процессора и пропускную способность ввода-вывода, поэтому стоит проверять производительность до и после изменения.
Опция монтирования <code>compress=алгоритм[:уровень]</code> позволяет включить сжатие, где <code>алгоритм</code> — это либо [[zlib]], [[lzo]], [[zstd]], либо no (без сжатия). При использовании этой опции Btrfs будет проверять, помогает ли сжатие первой порции данных в файле сэкономить место. Если да, то весь файл будет сжат; если нет, то сжатие использоваться не будет. Таким образом, если размер первой порции записи не уменьшится при сжатии, то весь файл не будет сжат, даже если остальные порции сжимаются хорошо<ref name="incompressible-data">{{cite web
|url          = https://btrfs.readthedocs.io/en/latest/Compression.html#incompressible-data
|title        = Compression: Incompressible data
|lang        = en
|date        =
|access-date  = 2024-01-07
|website      =
|archive-url  = https://web.archive.org/web/20240101183952/https://btrfs.readthedocs.io/en/latest/Compression.html
|archive-date = 2024-01-01
}}</ref>. Это сделано для того, чтобы не заставлять диск ждать начала записи, пока все записываемые данные не будут полностью переданы Btrfs и сжаты.
Также можно использовать другую опцию монтирования <code>compress-force=алгоритм[:уровень]</code>, которая заставляет Btrfs пропустить проверку сжимаемости первой порции данных и включает автоматическую попытку сжатия для каждого файла. В худшем случае это может привести к (незначительному) бесполезному увеличению загрузки процессора. Однако эмпирическое тестирование на нескольких системах смешанного использования показало значительное улучшение примерно на 10% сжатия диска при использовании <code>compress-force=zstd</code> по сравнению с просто <code>compress=zstd</code>, который также имел 10% сжатие диска. Однако имейте в виду, что принудительное сжатие не рекомендуется официальной документацией Btrfs<ref name="incompressible-data"/>.
Будут сжиматься только файлы, созданные или изменённые после добавления опции монтирования.
Чтобы применить сжатие к существующим файлам, используйте команду <code>btrfs filesystem defragment -cалгоритм</code>, где <code>алгоритм</code> — это <code>zlib</code>, <code>lzo</code> или <code>zstd</code>. Например, чтобы сжать всю файловую систему с помощью zstd, выполните следующую команду:
<syntaxhighlight lang="bash">
btrfs filesystem defragment -r -v -czstd /
</syntaxhighlight>
{{Внимание|'''Важно:''' Дефрагментация файла, имеющего CoW-копию (либо снимок, либо копию, сделанную с помощью '''[[cp]]''' или bcp), плюс использование ключа <code>-c</code> с алгоритмом сжатия может привести к появлению двух не связанных друг с другом файлов, что приведёт к увеличению использования места на диске.}}
{{Imbox
| type = notice
| text = '''Совет:''' Сжатие также может быть включено для отдельных файлов без использования опции монтирования <code>compress</code>; для этого примените <code>chattr +c</code> к файлу. Если применить это к каталогу, то файлы, создаваемые в этом каталоге, будут автоматически сжиматься.
}}
{{Внимание|'''Важно:'''
* Системы, использующие старые ядра или [[btrfs-progs]] без поддержки zstd, могут быть не в состоянии прочитать или восстановить вашу файловую систему, если вы используете эту опцию.
* Поддержка zstd в [[GRUB]] появилась в версии 2.04. Убедитесь, что у вас обновлён код загрузчика, установленный в MBR/ESP, запустив grub-install с соответствующими опциями для вашей настройки BIOS/UEFI, поскольку это не выполняется автоматически.
}}
=== Просмотр типов и коэффициентов сжатия ===
'''[https://archlinux.org/packages/?name=compsize compsize]''' берёт список файлов (или всю файловую систему Btrfs) и смотрит используемые типы сжатия и эффективные коэффициенты сжатия. Размер без сжатия может не совпадать с числом, выдаваемым другими программами, такими как [https://man.archlinux.org/man/du.1 du(1)], потому что каждый экстент считается один раз, даже если на него есть несколько ссылок и даже если часть его больше нигде не используется, но ещё не была убрана при сборке мусора. Опция <code>-x</code> ограничивает анализ одной файловой системой, что полезно в ситуациях типа <code>compsize -x /</code>, чтобы предотвратить попытки программы просканировать не-Btrfs подкаталоги.
== Подтома ==
{{main|Btrfs/Подтома}}


== Примечания ==
== Примечания ==

Текущая версия от 23:42, 6 января 2024

На этой странице мы рассмотрим настройку файловой системы.

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

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

Отключение CoW

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

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

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

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

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

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

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

Сжатие

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

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

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

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

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

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

btrfs filesystem defragment -r -v -czstd /

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

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

Подтома

Примечания

  1. btrfs(5) — Arch manual pages (англ.). Arch manual pages (14 декабря 2023). Дата обращения: 6 января 2024. Архивировано 28 декабря 2023 года.
  2. Fedora:Changes/BtrfsByDefault#Compression (англ.) (3 февраля 2021). Дата обращения: 7 января 2024. Архивировано 22 декабря 2023 года.
  3. Btrfs by default, the compression option - devel - Fedora Mailing-Lists (англ.) (8 июля 2020). Дата обращения: 7 января 2024. Архивировано 24 марта 2023 года.
  4. Issue #36: Write amplification [meta] - project - Pagure.io (англ.) (13 ноября 2020). Дата обращения: 7 января 2024. Архивировано 26 декабря 2023 года.
  5. Using Disk Compression With Btrfs To Enhance Performance - Phoronix (англ.) (28 августа 2010). Дата обращения: 7 января 2024. Архивировано 28 января 2023 года.
  6. Btrfs Zstd Compression Benchmarks On Linux 4.14 - Phoronix (англ.) (13 ноября 2017). Дата обращения: 7 января 2024. Архивировано 8 июля 2023 года.
  7. 7,0 7,1 Compression: Incompressible data (англ.). Дата обращения: 7 января 2024. Архивировано 1 января 2024 года.

Ссылки и источники