BTRFS файловая система для Linux, основанная на структурах B-деревьев и работающая по принципу «копирование при записи» (copy-on-write).
Многие о ней слышали, у некоторых она по дефолту (Fedora), а некоторые прочли отзывы об проблемах и даже не стали пробовать. Бенчмарки на Phoronix порой тоже не в пользу этой ФС. Я же решил перейти на BTRFS в качестве экономии места. На данный момент я являюсь хранителем на Rutracker, раздаю 4,000+ раздач суммой ~7.16ТБ, поэтому мне это актуально как никогда.
BTRFS поддерживает сквозное сжатие при записи, упаковку хвостов, а также дедупликацию сторонними утилитами. Файлы на моём хранительском винчестере представляют собой сжатые файлы, это ZIP архивы с PS2 играми, mkv фильмы и сериалы, а также flac музыка, поэтому этот опыт был ещё более интересен, и возможно пригодится другим.
Чужой пример того как можно получить профит от использования для /root.
И сравнение до и после дефрагментации. К слову, данный владелец утверждал ускорение загрузки Linux, но этого мне не проверить.
Миграция
Переход с Ext3/4 на BTRFS можно выполнить в пару кликов, но способ нерекомендуемый и я им не воспользовался, хоть и пришлось потратить намного больше времени. Отрезал от винча 7.95ТБ пустого пространства за 3ч+.
Важно! При указании опции в fstab compress=формат_сжатия, происходит проверка файлов на наличие сжатия для ускорения операции, но может так случиться, что части файлов могут быть плохо сжаты, поэтому вы можете упустить важную экономию. Чтоб этого не произошло, вы можете использовать опцию compress-force=формат_сжатия. Я выбрал zstd.
Только файлы, созданные или измененные после добавления опции монтирования, будут сжаты.
У меня на копирование данных ушло почти сутки. В вашем случае могут быть другие цифры. И вот после этого начинаются нюансы с BTRFS, или как любят говорить "фичи".
Проблемы после перехода
Получив после удаления старого раздела Ext4 свободное пространство рука первым делом тянется расширить раздел, и конечно хочется это через GUI используя Gparted, но не тут то было. Gparted просто не даёт это сделать и всячески игнорирует свободное пространство. Также для BTRFS есть их фирменная команда для расширения, которая тоже не работала ссылаясь на отсутствие свободного пространства.
btrfs filesystem resize +size /
btrfs filesystem resize max /
Прошерстя интернет увидел в Реддит совет, который у меня сработал, это просто отмонтировать диск через консоль и потом Gparted наконец начал работу.
sudo umount /mnt
Но время в 20ч+ в Gparted меня не устроило, поэтому начал искать альтернативу. Информации за сколько и как это бы выполнил btrfs filesystem resize у меня нету.
Наконец о радостях
И здесь на помощь приходят те самые (наконец положительные) фичи BTRFS. BTRFS поддерживает подтомы а также объединение в один пул как логических так и физических дисков. Всё это без RAID, но с его преимуществом в скорости, файлы точно также будут записываться на два физических устройства. Поэтому дальнейшие действия это:
- Создать в свободном пространстве логиеский том BTRFS
- Присоединить его в общий пул с общей точкой монтирования и общим UUID
sudo btrfs device add /dev/sdX /mnt
проверяем:
sudo btrfs device usage /mnt
Важно! Для тех у кого 2 и более физических устройства, которые вы объединяете, стоит выполнить баланс после добавления в пул. НО, для одного физического диска это не стоит делать. Так я и убил ещё 25ч на бесполезное дело. Но это часть моего опыта. Также это замедлит деинсталяцию раздела из общего пула используя опцию remove.
sudo btrfs filesystem balance /mnt
проверяем итоги:
sudo btrfs device usage /mnt
Финал
В зависимости от файлов я выйграл от 1 до 7%. Кто-то подумает что это немного, но здесь важно смотеть на те самые важные гигабайты и учитывать размер хранилища. А выйграл я 133.6ГБ, которые я потрачу на новые раздачи.
И конечно здесь не обойтись без бенчмарков, после стольки 6 лет использования сугубо Ext4 для HDD.
А вот что нам даёт переход на BTRFS. Тест был выполнен несколько раз и это никакая не ошибка. Переход на BTRFS даёт прирост для рандомной записи мелких файлов в несколько раз. И по нижнему показателю уменьшает отставание от SSD с х20 до х6. Я думаю вы представляете что было бы уже при двух HDD. (сравнение с OCZ VTR180. нижний бенч 80)
Update
Учитывая опыт коллеги, я не мог не забыть про тест со сжатием системы, поэтому я сначала скопировал и проверил сжатие home, а затем и root + home
Теперь сфера применения BTRFS стала намного шире, становясь рекомендованной ФС как для установки Linux на HDD, так и для установки на flash память низкого объёма. Или же старичков на IDE HDD.
Итоги
Стоило ли оно того и кому может подойти:
- Вы хотите получить больше свободного пространства и у вас есть один или несколько винчестеров.
- Вы владелец большого объёма сжатых файлов, но тоже хотите больше свободного места.
- Для установленной системы у вас используется HDD, и вы хотите немного буста рандомной записи. Хороший дуэт с BFQ low latency.
- У вас flash память маленького объёма и важен каждый гигабайт.
- Вы часто записываете много мелких файлов на HDD.
- Вы просто хотите легко сделать один общий пул из нескольких дисков, с одной привычной точкой монтирования, но не хотите разбираться в RAID и LVM.
Из-за чего вам может не подойти:
- возможно будет долгое монтирование
При первом конфиге BTRFS из двух логических дисков в одном пулле на одном физическом диске, при занятых ~7ТБ, монтирование занимало 43с. Но потом в дальнейшем диск был отформатирован в один логический том, и при занятых 2ТБ монтирование было уже терпимые 3с. С ростом заполняемости диска время монтирования продолжает расти.
P.S. скорее всего статья будет обновляться для более читабельного вида. Не откажусь от конкретики.
