Содержание
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 продемонстрировала во всей красе.
