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

Автор: Алексей Федорчук

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

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

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

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

Однако вернёмся к нашей 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-файлов

btrfs019-01.gif

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

btrfs019-03.gif

и iso-образа:

btrfs019-04.gif

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

btrfs019-02.gif

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

btrfs019-05.gif

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

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