CITKIT.ru - свободные мысли о свободном софте
Деловая газета CitCity.ru Библиотека CITForum.ru Форумы Курилка
Каталог софта Движение Open Source Дискуссионный клуб Дистрибутивы Окружение Приложения Заметки Разное
19.03.2019

Последние комментарии

ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)
24 December, 22:53
Kubuntu Feisty (15)
24 December, 18:42
Один на один с Windows XP (3758)
24 December, 11:46

Каталог софта

Статьи

Дискуссионный клуб
Linux в школе
Open Source и деньги
Open Source и жизнь
Windows vs Linux
Копирайт
Кто такие анонимусы
Лицензии
Нетбуки
Нужен ли русский Linux?
Пользователи
Дистрибутивы
Идеология
Выбор дистрибутива
Archlinux & CRUX
Debian
Fedora
Gentoo
LFS
LiveCD
Mandriva
OpenSolaris
Slackware
Zenwalk
Другие линуксы
BSD
MINIX
Движение Open Source
История
Классика жанра
Окружение
shell
Библиотеки UI
Графические среды
Шрифты
Приложения
Безопасность
Управление пакетами
Разное
Linuxformat. Колонки Алексея Федорчука
Заметки
Блогометки
Файловые системы
Заметки о ядре

Заметки :: Файловые системы

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

Страницы: предыдущая :: 1 :: ... :: 3 :: 4 :: 5

Содержание

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

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

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

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

  1. просто подключить второй раздел к наличествующей файловой системе btrfs;
  2. объединить два раздела с 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 продемонстрировала во всей красе.




Страницы: предыдущая :: 1 :: ... :: 3 :: 4 :: 5

Комментарии

Страницы комментариев: 1 :: 2 :: следующая

аноним, Thu Feb 5 19:41:26 2009:
Не очень понятен поросячий восторг по поводу конвертирования ext3 в btrfs. Конверторы из
одной фс в другую существуют в природе уже давно.
Просто они не особо популярны, т.к. это никому
не нужно.
Алексей Федорчук, Thu Feb 5 16:03:55 2009:
> К тому времени, как её допилят, она уже безнадёжно устареет
___
Ага. Потому что к тому времени лично товарисч вот этот анонизмус:
> аноним, четверг, 5 февраля 2009 г. 13:47:49:
___
создаст новую суперфайловую мегасистему, которой

>восторгайтесь сейчас :)
аноним, Thu Feb 5 13:47:49 2009:
К тому времени, как её допилят, она уже безнадёжно устареет, так что восторгайтесь сейчас :)
onanim, Mon Feb 2 01:20:52 2009:
Если допилят - тогда и будем восторгаться и бурно радоваться. А пока что btrfs - нестабильная YAFS
Lena, Sun Feb 1 17:59:50 2009:
Что там была за хрень про шрифты и "налезания"?
Konqueror все пристойно отображает. И даже очень...
Юрий, Fri Jan 30 09:17:06 2009:
Спасибо, хороший обзор.
Qiwichupa, Fri Jan 30 05:22:32 2009:
Интересно что будет насчет утилит восстановления и вообще управления данными. Допустим если прикрутил я диск к уже существующей точке монтирования, а потом мне понадобилось, допустим, сменить один из включенных в эту точку дисков. Прокатит ли простое клонирование, можно ли будет управлять данными - например переносить инфу с одного из дисков на другой, освобождая диск для замены или просто при желании от него избавиться.
Buy, Fri Jan 30 01:34:45 2009:
>"пацан сказал - пацан сделал" зачем это?

А затем, шо btrfs риальна нааармальная тема!
:)))
Интересная статья, вот зажегся тоже потестить.
AVATAR, Thu Jan 29 23:19:36 2009:
"пацан сказал - пацан сделал" зачем это?
Фридрих, Thu Jan 29 21:15:10 2009:
2 аноним, четверг, 29 января 2009 г. 18:25:55:

> кстати, вы видели вообще, как выглядит
> дизайн сайта не с вашими шрифтами?

Видел.

> буквы налезают друг на друга под
> оффтопиком(лиса,асёл), макосью(лиса, сафари)
> и пенгвином (лиса и конкуер)

Конечно ШГ, спору нет, но насчёт налезающих букв - это вы загнули. Под оффтопиком не проверял, но под пингвином (лиса) вроде ничё так, вполне читабельно.

З.Ы. Судя по терминологии, прозреваю в вас ЛОРовский анонимный разум ;-)

Страницы комментариев: 1 :: 2 :: следующая

Комментарии заморожены.

Новости:

Все новости на CitCity.ru

Компании месяца

 
Последние комментарии
Почему школам следует использовать только свободные программы (101)
20 Декабрь, 14:51
ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)

24 Декабрь, 22:53
Linux в школе: мифы про школу и информатику (334)
24 Декабрь, 22:43
Kubuntu Feisty (15)
24 Декабрь, 18:42
Software is like sex: it's better when it's free.
©Linus Torvalds