Алексей Федорчук
Вдохновлённый прикидками быстродействия 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. Напомню, что в результате предшествовавших манипуляций http://alv.me/?p=70 в этом каталоге обосновался на ПМЖ раздел /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 на однодисковой конфигурации. И был несколько травмирован: не то, что никакого прироста не обнаружилось, но кое-где обрисовался и явный урост. Что можно наглядно видеть в таблице (сравниваем ## 2 и 1) и на рис. 1.
Таблица. Быстродействие 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 |
Правда, как можно видеть из рис. 1, удаление дерева портежей на двухдисковой btrfs происходит ощутимо быстрее — но возможно, что это просто случайная флуктуация: по остальным показателям она отстаёт от своеё однодисковой сестры вполне ощутимо.
Рис. 1. Btrfs: один диск против двух
Сначала я попытался объяснить это тем, что при перезагрузке и перемонтировании в двухдисковой конфигурации что-то разбалансировалось — я ведь не был уверен, что всё сделал правильно (кстати, не уверен и до сих пор). И попробовал повториьь команду
# btrfs-vol -b /home/soft
Некоторое время она шелестела винтом, а потом выдала Segmentation fault. После чего файловая система перестала читаться вообще. Команда btrfsck, как меня и предупреждали товарищи, дала тот же результат — то есть сегфолт.
Благо, как уже говорилось выше, ничего невосполнимого на усопшей 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), не говоря уже о неудачной простой двухдисковой конфигурации. Что наглядно видно на рис. 2.
Рис. 2. Btrfs: raid0 против одного и двух
Осталось сравнить быстродействие btrfs’ного raid0 с прочими файловыми системами в двухдисковых конфигурациях. Результаты сравнения можно видеть всё в той же таблице и на серии диаграмм (рис. 3-7).
Рис. 3
Рис. 4
Рис. 5
Рис. 6
Рис. 7
Подробные комментарии, как мне кажется, излишни. Достаточно сказать, что почти на всех проводимых операциях btrfs raid0 идёт вровень с лучшими из лучших или опережает их, иногда вполне значимо. Исключение — всё то же удаление дерева портежей, но, как уже неоднократно отмечалось, супротив reiser на RAID здесь не блещет ни один из противников.
На этом практические упражнения временно заканчиваю: btrfs raid 0 остаётся у меня как хранилище скачиваемых из сети файлов, что даёт на него должную нагрузку на предмет проверки надёжности. А мы тем временем займёмся вопросами теоретическими — как устроена btrfs, и что позволило ей дойти до жизни такой. Что и будет предметом ближайших заметок. А пока они будут сочиняться — глядишь, и релиз linux-2.6.29 с официально стабильной btrfs подоспеет, btrfs-progs будет доведён до ума, да и поддержка её появится в дистрибутивах в качестве штатной опции.
Пока же должен подчеркнуть, что всё выше сказанное — сугубо экспериментально. И никакие невосполнимые данные я пока на btrfs размещать не намерен. Да и другим не советую. И это отнюдь не в упрёк: всё-таки полтора года — слишком мало для создания надёжной и стабильной файловой ситсемы практически с нуля, хотя и с учётом всего накопленного опыта. А пока достаточно и того, что свой потенциал btrfs продемонстрировала во всей красе.
> релиз linux-2.6.29 с официально стабильной btrfs подоспеет
Думаю что он будет в 29 сугубо в тестовом состоянии.Такие ФС в одночасье не делаются.
А есть ли гдето сравнения производительности freebsd zfs vs solaris zfs?
Есть ли какая нибудь разница в функциональности между freebsd zfs и solaris zfs?
можно было сравнить ещё время индексации файлов:
time du -sh /your/dir
на разных файловых системах это время (и подсчитанный обьём) будет разным
неплохо былобы ещё использовать синтетические тесты из phoronix test suite