Btrfs. +40% бесплатно. Сравнение с Ext4

В последнее время мне часто попадались новости о Btrfs. Какая файловая система классная и какая функциональная. Решил загуглить информацию о практическом опыте пользования. К сожалению, всё, что в сети смог найти - субъективная вкусовщина без цифр и без сравнений. Никакой прагматической пользы я не нашёл, поэтому решил провести собственные опыты, сравнить btrfs с ext4.

4 теста: 
1. Скорость загрузки системы.
2. Чтение множества маленьких файлов.
3. Чтение одного большого файла.
4. Внезапное отключение электропитания.

Тесты проводились на идентичных виртуальных машинах virtualbox.

Хост:
Debian: 13.4
DE: GNOME 48
CPU: AMD Athlon 2 280  3.4GHz (частота занижена на 0.2 потому что барахлит БП)
RAM: 16GB (2x8)
GPU: AMD Radeon HD 7770
Накопитель HDD SATA2

Виртуалки:
- 2 ядра (100% загрузки)
- 10 ГБ ОЗУ
- 5 ГБ диск (root)

Подготовка:
Было создано 2 виртуальные машины с дисками по 5ГБ каждая. На каждой была установлена базовая система Debian 13 (без DE). На одной машине была ФС ext4 со стандартными параметрами монтирования, а на другой btrfs с параметром compress (при установке ставится алгоритм lzo).

На машине с btrfs я сразу поменял параметры монтирования в fstab с compress на compress=zstd:1 и выполнил дефрагментацию чтобы пережать с новым алгоритмом.
После этого я начал одновременно устанавливать типичный набор программ (DE, браузер, офис, просмотрщики файлов). Делал это параллельно, чтобы системы были идентичны друг другу.

Занимаемое пространство привлекает внимание. На ext4 это 3.71ГБ, а брат близнец на btrfs всего 2.08ГБ, что составляет 56% от первоначального объёма. Даже если взять информацию от btrfs filesystem usage, где указывается 3.55ГБ, всё равно получается солидно 58%.

Следующим этапом была дефрагментация .vdi файлов. Как оказалось, не зря. Один из файлов дисков был разбит на 400+ частей, что существеннно замедляло работу дисковой подсистемы хоста. После его дефрагментации, машина начала включаться в полтора раза быстрее.

Завершающим этапом стала дефрагментация внутри самих машин.

Тест 1: Boot

Я не просто так выше написал про дефрагментацию. Из-за фрагментации файлов, машина с ext4 грузилась примерно за 1:30. Ниже прикладываю выборку тестов уже после дефрагментации vdi. Время замера от момента выбора ОС в grub до появления ярлыков рабочего стола.

ext4
1. 0:57
2. 0:58
3. 0:58

btrfs
1. 0:54
2. 0:56
3. 0:55

Изменения мизерные. Без секундомера незаметно.

Тест 2: Чтение множества мелких файлов

(Верхняя горизонтальная строка на скриншоте)

Для этого я выделил по 10ГБ ОЗУ на каждую виртуалку и организовал RAM диски, чтобы исключить влияние медленной записи. В качестве кучи мелких файлов я использовал всё, что было в системе (копировал её в оперативу).

Тестовый bash скрипт:

#!/bin/bash
rm -R -f /home/user/RAM/*  #Очистка рам диска
sudo sync  #Принудительный слив буфера записи
sudo echo 3 | sudo tee /proc/sys/vm/drop_caches  #Очистка кешированных данных
time cp -a -x / /home/user/RAM/ #Замер времени копирования
exit 0

Перед каждой выборкой, на хостовой машине выполнялась команда очистки кеша sudo echo 3 | sudo tee /proc/sys/vm/drop_caches.

Результаты из 5 выборок:

ext4:
1. 3m18s
2. 3m10s
3. 3m4s
4. 3m9s
5. 3m6s

btrfs:
1. 2m40s
2. 2m20s
3. 2m21s
4. 2m19s
5. 2m20s

В условиях данного теста, btrfs даёт выигрыш примерно 25%.

Тест 3: Чтение одного большого файла

(Нижняя горизонтальная строка на скриншоте)

Для этого теста я создал дополнительный диск .vdi на 5ГБ и примонтировал его /home/user/TST/. Порядок действий был следующий.

Так как tar прерывает свою работу из-за недоступных файлов и ссылок, я решил скопировать всё возможное в RAM, а уже оттуда сжимать на тестовый раздел.

В итоге я получил файлы root.tar с максимально похожим содержимым. Размеры файлов 3.62ГБ на ext4 и 2.12ГБ на btrfs что составляет 59%.

Тестовый скрипт:

#!/bin/bash
rm -R -f /home/user/RAM/*  #Очистка рам диска
sudo sync  #Принудительный слив буфера записи
sudo echo 3 | sudo tee /proc/sys/vm/drop_caches  #Очистка кешированных данных
time cp -a -x /home/user/TST/root.tar /home/user/RAM/root.tar #Замер времени копирования
exit 0

Как и в предыдущем тесте, перед каждой выборкой выполнялась команда очистки кеша sudo echo 3 | sudo tee /proc/sys/vm/drop_caches.

Результаты из 5 выборок:

ext4
1. 1m1s
2. 1m4s
3. 1m3s
4. 1m3s
5. 1m42s (предположительно какой-то процесс на хосте занял время)

btrfs
1. 0m48s
2. 0m49s
3. 0m48s
4. 0m44s
5. 0m46s

Здесь выигрыш от btrfs ещё солиднее, примерно 30-35%.

Тест 4: Внезапное отключение электропитания

(Данный тест для галочки и не моделирует реальную нагрузку)

Чтобы не засорять подопытных мусором, этот тест проводил завершающим. Хочу предупредить, что я не знаю, как можно провести его максимально приближённо к реальности, а потом сделал следующее.

Попытался скачать старую версию ядра и на разных этапах отключал машину. Отключения были во время распаковки, initramfs, updategrub, а также initramfs и updategrub при удалении ядра.

Обе системы успешно пережили это и продолжили работать как ни в чём не бывало.

Вывод

Сжатие данных минимизирует воздействие бутылочного горлышка системы ввода-вывода. Бонусом +40% памяти накопителя почти бесплатно.

Что касается снапшотов и откатов, я таким не пользуюсь и не знаю, как провести тестирование. Да и не нужно оно мне.

Для моих нужд btrfs превосходит ext4.

Как бы я хотел провести этот эксперимент на реальной машине с AMD K8 и накопителями PATA (обзор на это железо я выкладывал ещё в 2020), но, к сожалению, у меня сейчас нет доступа к тому компьютеру.