Знакомство с btrfs

2009-01-26

Btrfs в двухдисковой конфигурации

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

Благо, на роль второго устройства имелся подходящий кандидат — первичный раздел на втором диске, /dev/sdb3, объёмом около 30 Гбайт, который нёс файловую систему FAT32, созданную по случаю для обмена файлами между FreeBSD и OpenSolaris (как ни странно, несмотря на одинаковую файловую систему, это оказался наиболее простой способ их взаимодействия). Ныне необходимость в этом отпала, и содержимым раздела можно было безболезненно пожертвовать (как и им самим).

Изучение документации (можно и в русском переводе) показало наличие двух способов задействовать мультиустройства:

просто подключить второй раздел к наличествующей файловой системе btrfs;
объединить два раздела с btrfs в программный RAID.

Второй путь обещал (при использовании RAID Level0) больший выигрыш в быстродействии, но требовал большего числа манипуляций, и поэтому я решил сначала опробовать первый.

Сама по себе процедура оказалась очень простой. Сначала я, соблюдения порядку для, обнулил начальные сектора обречённого на заклание FAT-раздела

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

и, посредством fdisk, изменил его идентификатор на 83 (Linux). Впрочем, в необходимости этих шагов я не уверен, но и вреда от них не могло быть ни малейшего.

Затем создаю файловую системы btrfs на очищенном от скверны разделе:

# mkfs.btrfs /dev/sdb3

И присоединяю его к существующей btrfs командой управления томами:

# btrfs-vol -a /dev/sdb4 /home/soft

где опция -a (или --add) и предписывает присоединить указанный раздел к файловой системе btrfs, смонтированной в /home/soft. Напомню, что в результате предшествовавших манипуляций в этом каталоге обосновался на ПМЖ раздел /dev/sda7 объёмом около 10 Гбайт.

После описанных действий вывод команды mount не изменился:

$ mount
...
/dev/sda7 on /home/soft type btrfs (rw,noatime)

Но зато команда df показала увеличение файловой системы как раз на те 27 истинных гигабайт, которые составляли объем присоединённого раздела:

$ df -h
Filesystem    Size    Used    Avail    Use%    Mounted on
...
/dev/sda7    37G        7.6G    12G        20%        /home/soft

Из чего я сделал резонный вывод, что первый этап операции прошла успешно.

Предстоял второй этап. Обычный здравый смысл подсказывал, что от присоединения к файловой системе второго раздела внутренняя её структура измениться не могла. То есть все метаданные и данные по-прежнему находились на первом носителе, и ни о каком стриппинге между ними не могло быть и речи. Следовало сбалансировать их. Что я и проделал столь же простой командой:

# btrfs-vol -b /home/soft

Где опция -b (или --balance) означенную балансировку и выполняет.

В документации сказано, что эта процедура может быть длительной — в зависимости от заполненности исходной файловой системой. В моём случае она протекала менее 10 секунд; много это или мало — за отсутствием сравнительного материала судить не берусь. Тем более, что по-хорошему она должна выполняться один раз за время жизни файловой системы в нормальном (не тестовом) режиме.

Далее пошла проверка на запись и считывание — всё работало. И осталось поломать голову, как увековечить это дело после следующей перезагрузки — в доступной мне документации на сей счёт не говорилось ни слова.

После нескольких проб и ошибок я совершил крамольную, казалось, бы, вещь — вписал в /etc/fstab такие строки:

/dev/sda7    /home/soft    btrfs    defaults,noatime    1 0
/dev/sdb3    /home/soft    btrfs    defaults,noatime    1 0

Самое смешное, что после этого всё заработало. Команда mount показывала, что /dev/sdb3 примонтировано в /home/soft, об устройстве /dev/sda7 в ней не говорилось ни слова, но df выдавало на гора положенные 27 гигабайт с копейками.

Временно успокоившись на этом, я решил таки прикинуть быстродействие — в сравнении с btrfs на однодисковой конфигурации. И был несколько травмирован: не то, что никакого прироста не обнаружилось, но кое-где обрисовался и явный урост. Что можно наглядно видеть в таблице 3 (сравниваем ## 2 и 1) и на Рис. 11.

Таблица 3. Быстродействие btrfs raid0 в сравнении с прочими файловыми системами на мультиустройствах

Тест	##пп	Копирование				Удаление
Тест	##пп	Музыка	Portage	Avi	Iso	Portage
btrfs	1	00:07	00:24	01:25	00:17	00:22
btrfs 2 диска	2	00:11	01:28	01:30	00:28	00:12
btrfs raid0	3	00:03	00:19	00:58	00:12	00:23
ZFS 2 диска	4	00:08	00:25	01:35	00:14	00:25
ext3, RAID	5	00:03	01:04	01:25	00:13	00:13
reiser RAID	6	00:02	00:56	01:21	00:13	00:04
XFS RAID	7	00:03	01:33	01:12	00:12	00:18

Правда, как можно видеть из Рис. 11, удаление дерева портежей на двухдисковой btrfs происходит ощутимо быстрее — но возможно, что это просто случайная флуктуация: по остальным показателям она отстаёт от своей однодисковой сестры вполне ощутимо.

Рис. 11. Btrfs: один диск против двух

Сначала я попытался объяснить это тем, что при перезагрузке и перемонтировании в двухдисковой конфигурации что-то разбалансировалось — я ведь не был уверен, что всё сделал правильно (кстати, не уверен и до сих пор). И попробовал повторить команду

# btrfs-vol -b /home/soft

Некоторое время она шелестела винтом, а потом выдала Segmentation fault. После чего файловая система перестала читаться вообще. Команда btrfsck, как и предупреждал Ali в поминавшемся ранее топике, дала тот же результат — то есть сегфолт.

Благо, как уже говорилось выше, ничего невосполнимого на усопшей btrfs не имелось. Так что можно было со спокойной душой списать убытки и заняться экспериментами с программным RAID-массивом.

В рамках btrfs без дополнительных аппаратных ("железный" RAID) или программных (любая система управления томами) средств поддерживаются RAID уровней 0 (стриппинг), 1 (зеркалирование) и 10 (стриппинг плюс зеркалирование). В перспективе — достижение уровней 5 и 6. Впрочем, для пользовательской машины с целью повышения быстродействия интерес представляет только RAID Level 0.

Для создания его, исходя из общих соображений, требуется два раздела примерно одинакового объёма. Поэтому перво-наперво я переразмечаю свой второй диск — вместо одного раздела создаю два, /dev/sdb3, на 10 Гбайт, и /dev/sdb4, на всё, что осталось (со временем я и ему найду применение в рамках рассматриваемой темы).

Обнуляю оба предназначенных к конкатенации раздела (/dev/sda7 и /dev/sdb3) всё той же командой dd и создаю из них RAID с btrfs следующим образом:

# mkfs.btrfs -m raid0 /dev/sda7 /dev/sdb3

Команда btrfs-show, предназначенная для просмотра btrfs-разделов, после этого выдаёт следующий результат:

# btrfs-show
failed to read /dev/sr0
Label: none  uuid: 4bc43654-9d27-477b-aa03-b4ecc992a134
    Total devices 2 FS bytes used 7.59GB
    devid    1 size 9.31GB used 7.48GB path /dev/sda7
    devid    2 size 9.31GB used 7.46GB path /dev/sdb3

На первую строку внимания не обращаю — это наша утилита просмотра пытается определить файловую систему привода компакт-дисков (в котором ни малейшего диска не содержится). Остальное же убеждает, что два btrfs-устройства имеют место быть (хотя смысла значений used я так до конца пока и не понял). Это находит подтверждение в выводе команды

$ df
Filesystem            Size  Used Avail Use% Mounted on
...
/dev/sda7              19G   28K   19G   1% /home/soft

показывающем, что объём, занятый каталогом /home/soft, вполне соответствует ожидаемому.

В отношении монтирования новообразованного raid'а поступаю проверенным ранее способом — то есть вписываю в /etc/fstab оба входящих в него устройства. Хотя дальнейшие эксперименты показали, что достаточно было бы и одного — причём любого из двух. И перехожу к замерам быстродействия.

И тут душа моя порадовалась: результат оказался вполне ожидаемым. То есть на raid0 все файловые операции выполнялись несколько (или даже весьма ощутимо) быстрее, нежели на однодисковой btrfs (см. таблицу, ## 1 и 3), не говоря уже о неудачной простой двухдисковой конфигурации. Что наглядно видно на Рис. 12.

Рис. 12. Btrfs: raid0 против одного и двух

Осталось сравнить быстродействие btrfs'ного raid0 с прочими файловыми системами в двухдисковых конфигурациях. Результаты сравнения можно видеть всё в той же таблице и на серии диаграмм (Рис. 13-17).

Рис. 13

Рис. 14

Рис. 15

Рис. 16

Рис. 17

Подробные комментарии, как мне кажется, излишни. Достаточно сказать, что почти на всех проводимых операциях btrfs raid0 идёт вровень с лучшими из лучших или опережает их, иногда вполне значимо. Исключение — всё то же удаление дерева портежей, но, как уже неоднократно отмечалось, супротив reiser на RAID здесь не блещет ни один из противников.

Дописав предыдущие строки, я вдруг понял, что упустил одну довольно важную деталь: создание raid0 с опцией -m обеспечивает стриппинг только метаданных, не распространяясь на данные собственно. Как пишутся при этом они — ведомо одному Аллаху.

А посему, выделив толику времени, не поленился изничтожить прежнюю файловую систему (описанным ранее способом, посредством команды dd — благо, как неоднократно говорилось, содержала она только сиюминутное и суетное). После чего пересоздал её следующим образом:

# mkfs.btrfs -m raid0 -d raid0 /dev/sda7 /dev/sdb3

где значение опции -d и обеспечивает стриппинг данных. На новобразованной файловой системе были проделаны всё те же тесты. Общаясь с btrfs, я уже отвык удивляться, поэтому полученные результаты вызвали удивление вполне ожидаемое (таблица 4).

Таблица 4.

Тест	Копирование				Удаление
Тест	Музыка	Portage	Avi	Iso	Portage
btrfs	00:07	00:24	01:25	00:17	00:22
btrfs -m raid0	00:03	00:19	00:58	00:12	00:23
btrfs -m -d raid0	00:07	00:35	00:59	00:12	00:22

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

Рис. 18

Так что, пожалуй, при наличии двух дисков оптимально будет использование btrfs в режиме расщепления метаданных.

Заключение

На этом практические упражнения временно заканчиваю: btrfs raid 0 остаётся у меня как хранилище скачиваемых из сети файлов, что даёт на него должную нагрузку на предмет проверки надёжности. А пока она происходит — глядишь, и релиз linux-2.6.29 с официально стабильной btrfs подоспеет, btrfs-progs будет доведён до ума, да и поддержка её появится в дистрибутивах в качестве штатной опции.

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

назад | к началу