Btrfs: прикинем быстродействие

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

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

Тестовый прикид был тот же самый, что и раньше. Машина — на Intel Core 2 Duo, описанная здесь , только вот «мозгов» у неё чуток поубавилось (осталось всего 4 Гбайт); полигонный винчестер — Samsung SATA о пятистах гигабайтах, с установленным Zenwalk 5.4, на котором располагается и btrfs-раздел. Тестовый набор тоже не изменился: каталог классической музыки, сконкатенированный из пяти серий в единый файл «Адьютант его превосходительства», iso-образ Xubuntu и дерево портежей Gentoo, последовательно подвергавшиеся копированию и удалению. Короче, всё, как описано в Последнем тестировании  и последующих заметках ZFS против всех  и ZFS на двух дисках .

Правда, всё, о чём будет говориться далее, нельзя считать сравнительными тестами  в полном смысле: во-первых, немного изменилось «железо», во-вторых, проводилось лишь двухкратное повторение тестовых операций, единственно для исключения флуктуаций, в-третьих, все измерения проводились в рабочей среде — то есть под Иксами в терминальном окне XFce. Собственно, мне и хотелось на скорую руку получить чисто качественную картину — насколько btrfs по быстродействию вписывается в некие усреднённые рамки, очерченные остальными файловыми системами. И стоит ли с ней возиться дальше.

Впрочем, все «сягчающие» обстоятельства нынешнего квази-тестирования как раз btrfs ставили в невыгодное положение относительно прочих файловых систем. Тем более показательны результаты, которые она продемонстрировала.

Так вот, результаты эти можно видеть в таблице 1 и на серии диаграмм. В качестве сравнительного материала сравнения приведены данные для файловых систем ZFS под FreeBSD (пул на одиночном диске), и файловых систем Linux — ext2fs, ext3fs (смонтирована в режиме ordered) и reiserfs (смонтирована с опцией notail), все также на индивидуальных дисковых разделах. Результаты для XFS в аналогичных условиях из диаграмм исключены, поскольку, как мы уже видели ранее , не лезут ни в какие ворота.

Таблица 1. btrfs против равных

Операция Копирование Удаление
Объект Музыка Portage Avi Iso Portage
btrfs 00:07 00:24 01:25 00:17 00:22
ZFS 00:12 00:29 02:30 00:21 00:16
ext2 00:08 01:28 03:09 00:31 00:18
ext3 00:06 01:41 02:36 00:25 00:17
reiser 00:07 01:29 02:37 00:25 00:04
XFS 00:07 16:53 02:36 00:24 10:0

Итак, в тесте на копирование музыкальных файлов btrfs идёт нога в ногу с другими файловыми системами Linux, ощутимо выигрывая у ZFS под FreeBSD (это единственный тест, где ZFS проявила себя не в лучшем виде в предыдущем тестировании ).

На копировании большого (2,7 Гбайт) avi-файла — уверенная победа btrfs над всеми, в том числе и над исключённой из диаграмм XFS, показавшей результаты наравне с reiserfs и остальными.

На копировании дерева портежей — фотофиниш между btrfs и ZFS, остальные файловые системы далеко позади, а XFS, как можно видеть из таблицы, вообще в глубочайшей… выразимся политкорректно, яме.

Копирование файла iso-образа (без малого 600 Мбайт) также принесло чистую победу btrfs, ZFS вплотную следует за лидером, прочие отстали (в том числе и неокученная XFS).

И лишь на удалении дерева портежей btrfs уступает всем остальным участникам соревнования, за исключением XFS, результаты которой опять-таки ниже уровня Каспийского моря.

То есть можно видеть, что в общем зачёте по очкам btrfs опережает всех конкурентов, причём некоторые из них приближаются в ней по одним показателям, иные же — по другим. И потому возникла такая вот совсем некорректная идея — выпустить эту файловую систему на ковёр против сборной FOSS-мира. То есть — тех файловых систем, которые показали рекордные результаты в каком-либо из тестов. И тут уже снять играничение весовых категорий — то есть допустить к соревнованиям и файловые системы на мультиустройствах — ZFS на двухдисковом пуле и файловые системы Linux’а на программном RAID level 0. Ведь из предыдущих заметок мы знаем, что в этом случае все они показывают весьма существенный прирост быстродействия.

Результаты, приведённые в талице 2, впечатляют: btrfs на однодисковом пуле лишь немного проигрывает файловым системам на программном RAID, а в одном случае (при копировании портежей) даже немного (скорее всего, в пределах ошибки эксперимента) опережает ZFS на пуле двухдисковом. Конечно, при удалении дерева портежей btrfs оказывается далеко позади reiserfs на программном RAID’е — но надо признать, что и остальные файловые системы тут не блещут в сравнении с последней.

Таблица 2. btrfs против лучших

Копирование Удаление
Тест Музыка Portage Avi Iso Portage
btrfs 00:07 00:24 01:25 00:17 00:22
ZFS 2 диска 00:25
reiser RAID 00:02 00:04
XFS RAID 01:12 00:12

Ещё раз повторяю, я привел лишь сугубо качественную картину. Однако лично меня она убедила в том, что btrfs — штука весьма стоящая, заслуживающая пристального внимания и глубокого изучения. А когда проянится вопрос с её надёжностью и стабильностью — то и повсеместного применения.

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

Btrfs: прикинем быстродействие: 10 комментариев

  1. спасибо за обзор… возьму на заметку btrfs…

    з.ы. в ближайшем будущем намечал смену диструбутива, хотел домашний каталог делать на xfs… теперь буду думать… :)

  2. 2 x0r
    Информация к размышлению по поводу ФС для домашнего каталога: конвертация из ext2/ext3 в btrfs реально работает — проверил (хотя и не верил).
    В ближайшие часы будет заметка по этому поводу.

  3. Какова методика измерений, вводимые команды?

  4. Скорость впечатляет, вопрос надежности… у zfs какая-то дикая система «контроля целостности», после отключения получил +40% потоковой записи.

  5. Могу только выразить глубочайшее удивление, как автору удалось получить такие результаты на XFS. Применяю XFS с 2002 года и никогда, ни при каких обстоятельствах не видел ничего подобного. Конечно, «конкретная геометрия диска» здесь не при чём и не может быть при чём. Я бы проверил результаты на других, более вменяемых дистрибутивах: не в ядре ли что напутали. Для примера, на моей рабочей машине (athlon x2 2400, 4Гб ОЗУ) и винчестере Seagate 250/5400, копирование (time cp …) одного файла размером 2.8 Гб в пределах одного раздела СИЛЬНО ЗАПОЛНЕННОЙ ФАЙЛОВОЙ СИСТЕМЫ (менее 1% свободного места, как известно. это садит производительность на порядок!!!), заняло 0.28user 11.21system 1:02.90elapsed 18%CPU

    Копирование того же файла на второй винчестер с аналогичным числом оборотов и объёмом кэша, но почти свободного, заняло 0.28user 9.59system 1:21.21elapsed 12%CPU.

    Копирование файловой свалки (пакеты src.rpm) размером от (… — симлинки) до 12М, всего
    719,301,800 байт в 4214 файлах, заняло 0.15user 4.39system 1:15.00elapsed 6%CPU.

    Для удаления той же свалки (time rm /common/gleb/V/*) понадобилось 0.00user 0.64system 0:12.42elapsed 5%

    Дистрибутив ALT Linux 4.1, 2.6.25-std-def-alt8.M41.1 #1 SMP Thu Sep 11 01:14:41 MSD 2008 i686 GNU/Linux

    Так что, автору большое пожелание искать паталогию в своей системе, чтобы не сделать слишком уж поспешных выводов.

  6. 2 gleb
    Сам был удивлён, потому что раньше — вот здесь
    http://alv.me/?p=116
    результаты не так выпадали из общего ряда.

  7. Достойное выступление.Если оно ТАКОЕ в тестовом состоянии и недоделанное, понятно что будет когда доделают.Зря сан пождничал имхо, теперь хит сезона видимо будет другой.

  8. Re: медленная XFS

    Возможно «виновата» поддержка write barriers. Они по-умолчанию включены с 2.6.17
    Бенчмарк (не мой):

    http://lkml.indiana.edu/hypermail/linux/kernel/0812.1/00285.html

    Однако их отключение, как я понял, может при сбое питания привести к знаменитым файликам из нулей.

  9. Жаль, нет ещё в сравнении ext4.
    И ещё, думается, что сравнение с ZFS, несколько, некорректное, так как она работает в других условиях, чем остальные.

  10. 2 Ivanych
    Есть и сравнение с ext4, во всех послежних материалах этого раздела: http://alv.me/?cat=19

    А на счёт сравнения с ZFS — более или менее корректно, потому что обе эти системы объединяют функции собственно ФС и менеджеров томов. Других таких нету.

Обсуждение закрыто.