Обновлённая btrfs: так ли она быстра?

2009-07-15

В конце прошлого и начале нынешнего года новые версии файловой системы btrfs (патчи к ядру) и инструментария для работы с ней выходили с регулярностью чуть ли не недельной. Однако после официального включения её поддержки в ядро Linux 2.6.29, чему соответствовала btrfs-progs-0.18 (17 января 2009 года) наступило полугодовое затишье.

И вот, давеча, заглянув в архив исходников btrfs, я обнаружил, что уже дней десять как там лежит новая версия btrfs-progs — 0.19, о чем никаких официальных сообщений мне не попадалось. С Changelog'ом можно ознакомиться здесь.

Вкратце: новая версия инструментария предназначена для ядра Linux 2.6.31-rc1; она поддерживает новый формат btrfs и обратно совместима со старым, но не наоборот. То есть файловые системы btrfs, созданные посредством v0.19, предыдущими версиями инструментария пониматься не будут. Утверждается, что v0.19 являет собой кардинальное ускорение почти для всех задач по сравнению с v0.18. Код поддержки нового формата доступен также для ядра 2.6.30 следующим образом:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git newformat2

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

Первая попытка успехом не увенчалась: я скачал ядерный бранч Криса Мейсона с git.kernel.org указанным выше образом и даже благополучно, то есть без ошибок, его собрал в Xubuntu. Однако загружаться новое ядро в этом дистрибутиве категорически отказалось, жалуясь на ошибки в VFS, хотя вроде поддержка всего, чего требовалось, в конфигурации ядра была включена (за основу был взят действующий конфиг рабочей системы).

Поэтому я ухватился за новую версию Fedora, в разрабатываемом варианте которой использовалось ядро 2.6.31-rc1, то самое, в котором поддержка нового формата btrfs была включена изначально. Успешно установив 11-ю версию Fedora и обновив её до Rawhide, как это было описано в предыдущей заметке, я получил плацдарм для дальнейших действий.

Надо отметить, что был и другой вариант приобщения к btrfs 0.19 — использование специально собранного Крисом Live-дистрибутива на базе Archlinux'а, предназначенного для загрузки с флэшки. Но о нём я узнал только, когда деятельность по освоению Fedora была в полном разгаре, так что отвлекаться смысла уже не было. Тем не менее, желающие могут скачать его (в 32- и 64-битном вариантах) отсюда — спасибо Михаилу Рудаченко aka Ali за наводку.

Однако вернёмся к нашей Fedora. Обновив вместе со всей системой ядро до версии 2.6.31-0.39.rc1.git9.fc12.x86_64, я первым делом проверил, а включена ли в нём поддержка btrfs "искаропки":

$ less  /boot/config-2.6.31-0.39.rc1.git9.fc12.x86_64
| grep BTRFS
CONFIG_BTRFS_FS=m
CONFIG_BTRFS_FS_POSIX_ACL=y

Как можно видеть из вывода, ответ оказался положительным — правда, она была включена как модуль, я же на самосборных ядрах встраивал её в ядро жёстко. Хотя сам Крис рекомендует именно модульное подключение. Имела место быть и связанная с модулем библиотека CRC32C.

Следующий проверочный шаг показал, что все необходимые модули не просто наличествуют, но и задействованы в системе:

$ lsmod | grep btrfs
btrfs                 425256  0
zlib_deflate           20424  1 btrfs
libcrc32c               2072  1 btrfs

А вот инструментария для работы с btrfs в системе после моей инсталляции не оказалось. Что было легко исправимо: посредством

$ yum search btrfs

я отыскал нужный пакет

btrfs-progs.x86_64 : Userspace programs for btrfs

с помощью

$ yum list btrfs-progs

убедился в соответствии версии

btrfs-progs.x86_64                         0.19-3.fc12

После чего сталось только инсталлировать оный:

su -
# yum install btrfs-progs

Теперь надо было создать новый вариант файловой системы — под неё я, как и раньше, отдал пятнадцатигигабайтный раздел, используемый для помещения скачанных из Сети программ. Обнулив для страховки его прежнее содержимое

# dd if=/dev/zero of=/dev/sdb2

выполняю форматирование с опциями по умолчанию:

# mkfs.btrfs /dev/sdb2

и обеспечиваю его монтирование от лица пользователя записью в /etc/fstab:

/dev/sdb2	/home/alv/test	btrfs	noatime,noauto,user	0 0

Вот теперь можно было заняться измерениями. Они проводились всё на том же, многократно поминавшемся ранее железе и включали тот же комплекс мероприятий, что и прежде . Каковой, напомню, заключался в измерении времени копирования серии flac-файлов, дерева портежей Gentoo, большого (2,7 Гбайт) avi-файла и iso-образа Xubuntu, а также удаления дерева портежей (засекать время удаления прочих файлов смысла не имело).

Результаты измерений приведены в таблице — в сравнении с таковыми для btrfs предыдущего формата (описывалось здесь ), а также файловыми системами нового поколения — ext4 (для Linux, описывалось здесь ) и ZFS (для FreeBSD, описывалось здесь ).

Таблица

Операция	Копирование				Удаление
Объект	Музыка	Portage	Avi	Iso	Portage
Btrfs 0.19	00:05	00:52	01:13	00:08	00:26
Btrfs 0.18	00:07	00:24	01:25	00:17	00:22
Ext4	00:10	00:15	01:44	00:19	00:04
ZFS	00:12	00:29	02:30	00:21	00:16

Результаты оказались довольно интересными. Можно видеть некоторое ускорение таких операций, как копирование набора flac-файлов

большого avi-файла

и iso-образа:

По всем этим показателям btrfs версии 0.19 не только превосходит предшественницу, но и уверенно опережает все остальные "юные" файловые системы, которые, в свою очередь, показывают большее быстродействие, чем файловые системы традиционные (см. последнее тестирование оных).В то же время результаты копирования дерева портежей иначе чем провальными для btrfs 0.19 назвать нельзя:

Да и удаление множества мелких файлов по сравнению с версией 0.18, которая в этом отношении тоже не блистала, несколько ухудшилось:

Эти результаты несколько обескураживали, поэтому я повторил измерения, предварительно отмонтировав тестовые раздел и смонтировав его заново: ничего не изменилось, так что даже не было смысла считать средние значения.Таким образом, можно считать фактом, что быстродействие нового варианта btrfs при манипуляциях с файлами большими, очень большими и среднего размера несколько увеличилось, хотя кардинальным ростом я это не назвал бы. А вот работа с большим количеством очень мелких файлов ухудшилась — и ухудшилась действительно кардинально.

И тем не менее, это не основание отказываться от использования btrfs: массовые операции с очень маленькими файлами — это специфика Source Based дистрибутивов с их портообразными системами пакетного менеджмента, в обычных пакетных дистрибутивах они более чем редки. А по быстродействию с обычными пользовательскими данными btrfs новой версии ещё более увеличила свой отрыв от всех возможных конкуренток.