В предыдущей статье я в общих словах рассмотрел преимущества использования файловой системы BTRFS для обычного пользователя, после чего описал процесс перевода ранее установленной систему на BTRFS. В этой статье мы рассмотрим опции монтирования файловой системы с оптимизациями для разных видов носителей, а также воспользуемся преимуществом сжатия данных "на лету". Ссылки на предыдущие статьи цикла смотрите в конце этой статьи.
Итак, начнём. Фактически у нас есть два основных типа накопителей. Это механические жесткие диски HDD и большая группа твердотельных накопителей без движущихся частей, куда входят SSD, MMC, различные флэшки и SD-карты. Основное их отличие заключается в механизме доступа к данным. Твердотельные накопители позволяют получать доступ к данным, расположенным в разных блоках памяти практически с одинаковой скоростью. Механические HDD имеют вращающийся диск с головками чтения, и время доступа к блоку данных на прямую зависит от текущего положения головок и положения самого диска. Таким образом, если фрагментация не является проблемой для твердотельных накопителей, то для механических это очень большая проблема т.к. из-за фрагментации скорость чтения может снизиться на порядки. Просто представьте себе большой файл (фильм например), "раскиданный" маленькими частями по всему диску. Головки будут двигаться от цилиндра к цилиндру, теряя драгоценное время, а потом ещё каждый раз ждать, когда диск повернется той частью, где начинается очередной кусочек данных. Таким образом получается, что для механических накопителей очень важно записывать данные по порядку, чтоб головка один раз встала на нужную дорожку (цилиндр) и прочитала сразу все блоки, не перемещаясь в другие места.
У твердотельных накопителей тоже есть свои недостатки. В первую очередь это ограниченное число циклов записи. По скорости чтения/записи они могут очень сильно отличаться. Сравните например обычную флэшку и SSD накопитель.
Посмотрим на основные опции монтирования (полный список можно увидеть ЗДЕСЬ) :
recovery and debug
recovery - Включает автовосстановление после монтирования, на данный момент сканирует старые списки корней и деревьев, которые можно прочесть. Практика показала что оно работает, но нужно иметь снимки файловой системы и оно просто вытаскивает списки корней и деревьев из снимков если таковые имеются
degraded - Используйте это, если у вас есть несколько устройств в объеме Btrfs (одна из RAID конфигураций или несколько дисков в Single или DUP режиме) и одно из них не монтируется. Это позволит вам по-прежнему монтировать файловую систему, даже если неисправное устройство выдаёт ошибки.
enospc_debug - Используйте, если столкнулись с ошибкой «Не хватает места»
Опции для SSD
ssd - Включает некоторые оптимизации для SSD в Btrfs. Минимизируется количество записей, отключается последовательная запись файлов. Эта опция включается автоматически, если вращение диска = 0. Не влечет за собой включения параметров TRIM/discard.
ssd_spread - Монтирование с -o ssd_spread вынуждает драйвер использовать для записи преимущественно не занятые области жёсткого диска, что специально вызывает сильную фрагментацию. Может значительно ускорить недорогие SSD.
Опции cache
inode_cache - Включить кэширование inode. Эта опция может замедлить работу системы при первом запуске.
space_cache - Кэширование данных о свободных блоках, чтобы не искать их перед записью
clear_cache - Очищает весь кеш свободного места, после монтирования. Это безопасная опция, но вызывает пересоздание кеша.
nospace_cache - выключает space_cache
Опции compression
compress=zlib - Включение прозрачного сжатия с алгоритмом gzip (медленнее lzo, но лучше сжимает)
compress=lzo - Включает алгоритм прозрачного сжатия lzo (быстрее gzip, немного хуже сжимает) Btrfs LZO Compression Performance.
compress=zstd - (Ядро > 5,14) Включает алгоритм прозрачного сжатия zstd (настраиваемый уровень сжатия) wiki о zstd.
compress=no - Без компрессии с версии ядра 3.6
compress-force=<comp.type> - Применяется аналогично compress, опция force позволяет выполнять компрессию файлов, которые обычно имеют низкий коэффициент сжатия (таких, как сжатые аудио или видео форматы).
Прочее
skip_balance - Пропускает автоматическую балансировку после монтирования или неправильного выключения.
nodatasum - Не высчитывать хэш-сумму, для новых файлов. Некоторый мусор и ошибки могут быть не замечены, но позволяет ускорить работу с FS. На большинстве современных CPU не даст ощутимого прироста к производительности.
autodefrag - Дефрагментация на «лету», не применять для SSD
noacl - Отключить контроль доступа к файлам (права)
nodatacow - не копировать данные при записи. datacow гарантирует, что у нас никогда не будет частично обновленных файлов. То есть файл будет обновлен полностью или останется неизменным. nodatacow обеспечивает небольшое повышение производительности за счет прямой перезаписи данных, за счет возможного получения частично обновленных файлов при сбоях системы. Увеличение производительности обычно составляет <5%, но если основная нагрузка системы это работа с базами данных и прочими системами, использующими большие файлы, то разница может стать очень большой.
commit=<время в секундах> - Устанавливает интервал периодической фиксации транзакций, когда данные синхронизируются с хранилищем. Более высокие значения интервала приводят к большему количеству не сохраненных данных, что имеет очевидные последствия при сбое системы. Используйте с осторожностью.
Теперь попробуем настроить нашу файловую систему BTRFS для оптимальной работы с конкретными типами накопителей. Все настройки мы будем прописывать в файле /etc/fstab. Открываем терминал и пишем команду:
sudo mcedit /etc/fstab
Начнём пожалуй с параметров монтирования для SSD накопителя. Очевидно, что нам потребуются опции ssd и ssd_spread. Стоит поэкспериментировать с опцией max_inline. Она позволяет установить максимальный размер файла, который может быть встроен в дерево метаданных, тем самым ограничивая его (дерева) разрастание. Если вы не работаете с критически важными данными и сбои системы у вас не частое явление, можно установить commit=600 и nodatacow. Применение опции relatime (опция не относится к уникальным для btrfs) позволит очень ощутимо поднять скорость так как при каждом обращении к диску записывается время доступа к файлу или директории (atime). Запись на диск происходит даже при операциях чтения, в том числе из кеша. При ее использовании метки времени обновляются, но не при каждом обращении к файлу, а только в том случае, если файл был изменен с момента последней записи atime. Также обязательно включим опцию space_cache, которая включает кэширование данных о свободных блоках в памяти. Без этой опции в процессе поиска свободного пространства перед записью Btrfs будет всякий раз сканировать все дерево. По результатам большинства тестов Phoronix включение опции space_cache дает выигрыш в скорости работы с диском, хотя и не столь существенный, как опция compress. Ну и естественно включаем компрессию. Я предпочитаю алгоритм zstd но есть важная деталь, НЕЛЬЗЯ использовать этот алгоритм на загрузочных файловых системах!
Теперь глянем сравнительные результаты тестов разных алгоритмов сжатия:
Тем не менее весь профит от использования наших настроек вы сможете прочувствовать и, при желании, измерить только немного поработав на настроенной системе. Для тестирования всего, что только можно, рекомендую Phoronix Test Suite.
Посмотрите интересную сводную табличку с данными по сжатию с сайта поддержки Ubuntu:
Данные таблички позволяют примерно оценить варианты и выбрать лучший конкретно для вашей системы. Если у вас не особо шустрый процессор (типа Atom, как в моей системе), то выбирать "тяжёлые" алгоритмы смысла нет и лучше остановиться на lzo или максимум zstd:3. Если у вас хороший проц, смело выбираем zstd:15. Но, повторю, НЕЛЬЗЯ использовать zstd алгоритм на загрузочных файловых системах! Используйте это если btrfs у вас есть ещё и на не загрузочном разделе. Как вариант можно сделать небольшой раздел с точкой монтирования /boot и использовать на нём lzo или zlib (или вообще ext4), а основной раздел ужать zstd:15.
Итак, возвращаемся к fstab. Вот что у нас получилось:
ssd, ssd_spread, max_inline=256, commit=600, nodatacow, relatime, space_cache, compress=zlib
Для сжатия уже имеющихся на диске файлов лучше загрузить систему с LiveUSB и выполнить команды:
sudo mount -t btrfs /dev/sda2 /mnt
sudo btrfs filesystem defragment -r -clzo /mnt/@ - для сжатия файлов алгоритмом LZO и
sudo btrfs filesystem defragment -r -czlib /mnt/@ - для ZLIB
Да, для сжатия данных в домашней папке не забудьте выполнить команду вида: sudo btrfs filesystem defragment -r -c<выбранный_вами_алгоритм> /mnt/@home
Все эти команды можно выполнить и в нормальном режиме, не перегружаясь в LiveUSB, но в таком случае часть файлов останутся не сжатыми так как они буду заняты системой. По большому счёту это совершенно не критично.
Что-то я сильно увлёкся, пора заканчивать. Пришла очередь параметров для обычного HDD. Я бы сделал так:
autodefrag,max_inline=256, commit=600, nodatacow, relatime, space_cache, compress=zlib
Если система установлена на внешнем USB приводе, исключаем опцию commit=600.
Для системы, установленной на флэшке опции будут как для SSD, только алгоритм сжатия включаем максимальный.
Вот, собственно и всё, что я хотел сказать. Если есть вопросы - задавайте их в комментариях. И не забудьте поставить лайк если статья Вам понравилась.
В следующей статье я постараюсь вернуться к принципу "Просто о Сложном" и расскажу как провести оптимизацию электропитания вашей системы буквально парой команд. А чтоб было совсем интересно, скажу, что на своём планшете c Core M 5y10c я увеличил время автономной работы в 2 раза (4 часа против 7 часов 43 минуты при воспроизведении ролика с YouTube) по сравнению с Windows 10. ;-)
Ссылки на предыдущие статьи:
ZRAM
ZSWAP
