Btrfs/Настройка: различия между версиями
Dzmuh (обсуждение | вклад) |
Dzmuh (обсуждение | вклад) |
||
| (не показаны 4 промежуточные версии этого же участника) | |||
| Строка 35: | Строка 35: | ||
{{Imbox | {{Imbox | ||
| type = notice | | type = notice | ||
| text = Совет: В соответствии с примечанием выше, вы можете использовать следующий трюк, чтобы отключить копирование при записи для существующих файлов в каталоге: | | 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
Внимание! Важно: Отключение CoW в Btrfs также отключает контрольные суммы. Btrfs не сможет обнаружить повреждения в nodatacow файлах. В сочетании с RAID 1 перебои в электропитании или другие причины повреждений могут привести к рассинхронизации данных. |
Чтобы отключить копирование при записи для создаваемых файлов в примонтированном подтоме, используйте опцию монтирования nodatacow. Это повлияет только на новые файлы. Для существующих файлов копирование при записи всё равно будет происходить. Опция nodatacow также отключает сжатие.[1]
Примечание: Из btrfs(5) § MOUNT OPTIONS: в рамках одной файловой системы невозможно монтировать одни подтома с nodatacow, а другие с datacow. Опция монтирования первого смонтированного подтома применяется ко всем остальным подтомам. |
Чтобы отключить копирование при записи для отдельных файлов/каталогов, выполните:
chattr +C /каталог/файл
Это отключит копирование при записи для операций над файлами, на которые есть только одна ссылка. Если ссылок на файл больше одной, например, из-за клонирования файлов или облегчённых клонов или снимков файловой системы, копирование при записи всё равно будет происходить. Начиная с coreutils 9.0, cp пытается создавать облегчённые копии по умолчанию — смотрите cp(1) для более подробной информации.
Примечание: Из chattr(1): При использовании Btrfs флаг ' C' следует устанавливать для новых или пустых файлов. Если он установлен на файле, который уже имеет блоки данных, то неизвестно, когда блоки, назначенные файлу, станут полностью стабильными. Если флаг 'C' установлен для каталога, он не будет иметь никакого эффекта на каталог, но новые файлы, создаваемые в этом каталоге, будут иметь атрибут No_COW. |
Влияние на снимки
Если для файла отключено копирование при записи (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 /
Внимание! Важно: Дефрагментация файла, имеющего CoW-копию (либо снимок, либо копию, сделанную с помощью cp или bcp), плюс использование ключа -c с алгоритмом сжатия может привести к появлению двух не связанных друг с другом файлов, что приведёт к увеличению использования места на диске. |
Внимание! Важно:
|
Просмотр типов и коэффициентов сжатия
compsize берёт список файлов (или всю файловую систему Btrfs) и смотрит используемые типы сжатия и эффективные коэффициенты сжатия. Размер без сжатия может не совпадать с числом, выдаваемым другими программами, такими как du(1), потому что каждый экстент считается один раз, даже если на него есть несколько ссылок и даже если часть его больше нигде не используется, но ещё не была убрана при сборке мусора. Опция -x ограничивает анализ одной файловой системой, что полезно в ситуациях типа compsize -x /, чтобы предотвратить попытки программы просканировать не-Btrfs подкаталоги.
Подтома
Примечания
- ↑ btrfs(5) — Arch manual pages (англ.). Arch manual pages (14 декабря 2023). Дата обращения: 6 января 2024. Архивировано 28 декабря 2023 года.
- ↑ Fedora:Changes/BtrfsByDefault#Compression (англ.) (3 февраля 2021). Дата обращения: 7 января 2024. Архивировано 22 декабря 2023 года.
- ↑ Btrfs by default, the compression option - devel - Fedora Mailing-Lists (англ.) (8 июля 2020). Дата обращения: 7 января 2024. Архивировано 24 марта 2023 года.
- ↑ Issue #36: Write amplification [meta] - project - Pagure.io (англ.) (13 ноября 2020). Дата обращения: 7 января 2024. Архивировано 26 декабря 2023 года.
- ↑ Using Disk Compression With Btrfs To Enhance Performance - Phoronix (англ.) (28 августа 2010). Дата обращения: 7 января 2024. Архивировано 28 января 2023 года.
- ↑ Btrfs Zstd Compression Benchmarks On Linux 4.14 - Phoronix (англ.) (13 ноября 2017). Дата обращения: 7 января 2024. Архивировано 8 июля 2023 года.
- ↑ 7,0 7,1 Compression: Incompressible data (англ.). Дата обращения: 7 января 2024. Архивировано 1 января 2024 года.
Ссылки и источники
- Btrfs (Русский) - ArchWiki. ArchWiki (25 ноября 2023). Дата обращения: 6 января 2024. Архивировано 6 января 2024 года.