BTRFS. Готова ли к использованию в 16.04?

[Venom13]

Будет очень здорово увидеть результаты.

Согласен.
Единственное. Немного не нравится метод тестирования установкой..
Там же много интерактивных действий в процессе установки. Хоть desktop, хоть server.
По стараюсь, конечно, их минимизировать.

[Sly_tom_cat]

Так замерять надо с момента разбивки диска - далее там в фоне уже все ставится, а остальной интерактив нужен для сбора информации, которая используется в самом конце.

[thunderamur]

Venom13, замеряй после ввода логина-пароля, далее все вопросы идут в процессе установки, и до предложения перезагрузится.

[Venom13]

Я бы предложил такие конфигурации для более полного тестирования:
1. VM на RAW диске (скормить виртуалке сырой диск)
2. VM в образе на XFS
2. VM в образе на BTRFS с настройками по умолчанию
2. VM в образе на BTRFS с отключенным COW на файле образа

Однако, результат заставил переосмыслить XFS..

Тесты:
1. RAW-Disk.
Установка: 9:19
Первый запуск: 22 с.
2. QCOW2 образ на XFS разделе:
Установка: 8:47
Первый запуск: 9 с.
3. QCOW2 образ на BTRFS-Single разделе (COW-включен):
Установка: 14:39
Первый запуск: 11 с.
4. QCOW2 образ на BTRFS-Single разделе (COW-ВЫключен):
Установка: 17:01
Первый запуск: 10 с.
5. QCOW2 образ на BTRFS-Single разделе (COW-ВЫключен, включено принудительное сжатие):
Установка: 17:42
Первый запуск: 11 с.
6. QCOW2 образ на BTRFS-RAID5 разделе (3 диска, COW-включен):
Установка: 27:15
Первый запуск:  16 с.
7. QCOW2 образ на Ext4:
Установка: 9:52
Первый запуск:  8 с.

Перед каждым тестом том удалялся, создавался и форматировался заново. Чтобы исключить влияние фрагментации.
Кроме 6-го теста. В нем установка производилась на существующий массив, с кучей данных (занято ~40%)..

Конфигурация гипервизора:

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

screenfetch
venom13@SrvKVM
OS: Ubuntu 16.04 xenial
Kernel: x86_64 Linux 4.4.0-36-generic
Uptime: 10h 54m
Packages: 803
Shell: bash 4.3.46
CPU: AMD Phenom II X4 980 @ 3.7GHz
RAM: 1154MiB / 16044MiB

[thunderamur]

Принудительное сжатие зачем? Хотя сути это не меняет, видно, что XFS и Ext4 лучше всех справляются с большими файлами-образами, но специально созданная под большие файлы XFS справляется лучше. Кроме того, у себя при использовании VBox, я замечал что на XFS система на ВМ ставится намного быстрее и ЖД не хрустит при этом как на Ext4. Что касается Btrfs под эти цели, то похоже она для этого не годится совсем.

[Resquer]

3. Массив RAID1 из 4-х дисков без прослойки mdadm - всё тоже самое, только запись сразу на 4 диска, нет чётких правил основной диск/зеркало, данные пишутся рандомно на все диски с таким условием, чтобы были дублирующие блоки как минимум на 2х дисках.

Беру свои слова назад.
Сконвертировал свой массив из single в raid1, затем произвёл балансировку (балансировка почти сутки происходила).
Итог такой:

Код: [Выделить]

root@store:~# btrfs filesystem usage /mnt/2tb
Overall:
    Device size:                  20.01TiB
    Device allocated:              8.46TiB
    Device unallocated:           11.55TiB
    Device missing:                  0.00B
    Used:                          8.45TiB
    Free (estimated):              5.78TiB      (min: 5.78TiB)
    Data ratio:                       2.00
    Metadata ratio:                   2.00
    Global reserve:              512.00MiB      (used: 0.00B)

Data,RAID1: Size:4.23TiB, Used:4.22TiB
   /dev/sdb        4.23TiB
   /dev/sdc        4.23TiB

Metadata,RAID1: Size:3.00GiB, Used:1.45GiB
   /dev/sdb        3.00GiB
   /dev/sdc        3.00GiB

System,RAID1: Size:32.00MiB, Used:624.00KiB
   /dev/sdb       32.00MiB
   /dev/sdc       32.00MiB

Unallocated:
   /dev/sdb        3.05TiB
   /dev/sdc        3.05TiB
   /dev/sdd        2.73TiB
   /dev/sde        2.73TiB


Код: [Выделить]

root@store:~# btrfs device usage /mnt/2tb
/dev/sdb, ID: 3
   Device size:             7.28TiB
   Data,RAID1:              4.23TiB
   Metadata,RAID1:          3.00GiB
   System,RAID1:           32.00MiB
   Unallocated:             3.05TiB

/dev/sdc, ID: 4
   Device size:             7.28TiB
   Data,RAID1:              4.23TiB
   Metadata,RAID1:          3.00GiB
   System,RAID1:           32.00MiB
   Unallocated:             3.05TiB

/dev/sdd, ID: 1
   Device size:             2.73TiB
   Unallocated:             2.73TiB

/dev/sde, ID: 2
   Device size:             2.73TiB
   Unallocated:             2.73TiB
Все данные полностью лежат на первой паре. Напомню, в single варианте, данные были примерно равномерно размазаны по двум дискам. Правда, там было всего два диска и они были одинаковые по размеру. И, да, при создании ФС был принудительно для data указан режим single, а по умолчанию, если не указывать конкретно, включается режим raid0 (если диски одинаковые по размеру).
Надо будет провести эксперимент - создать single раздел btrfs из двух неодинаковых дисков и понаблюдать, как там данные пишутся. Если также, как и на одинаковых - примерно равномерно по обоим, то вариант с прослойкой mdadm под btrfs имеет право на жизнь - в этом случае будут оба массива одновременно использоваться.

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

[Venom13]

Пытался реализовать вот этот момент:

Поддержка сложных многодисковых конфигураций — RAID уровней 0, 1, 5, 6 и 10, а также реализация различных политик избыточности на уровне объектов ФС — то есть возможно назначить, к примеру, зеркалирование для какого-либо каталога или файла.

Создал 3 подтома. Примонтировал их в разные точки монтирования.
Запустил конвертацию с изменением уровня RAID на одной точке монтирования... И все 3 подтома начали конвертацию. 
т.е. это чисто теоретическая возможность?
Или я что-то не так делаю?
Пользователь добавил сообщение 19 Сентября 2016, 12:22:49:И еще. Кто-нибудь пробовал собирать гибридные массивы с SSD?

Целый ряд вопросов..
1. Как массив поймет что у него есть диск SSD? Параметры SSD указывать - наверное не стоит, т.к. большинство дисков не SSD.
т.е. диск SSD будет использоваться не оптимально.
2. Диск SSD будет работать в режиме "на убой". Любая линейная запись будет в первую очередь на него т.к. он самый быстрый?
А потом балансировка/автодефрагментация будет не используемые файлы с него перемещать..
3. Если у нас RAID5-6.. То 1 SSD диск нам ведь никак не поможет, т.к. синхронная запись на 2-3 диска..
Получается что таким образом можно эффективно ускорить только single массив.
Или добавлять SSD диски в количестве, кратном минимальному для выбранного типа массива.

В общем поле для экспериментов великое. А лишнего SSD под рукой нет..

[Pilot6]

1. Как массив поймет что у него есть диск SSD? Параметры SSD указывать - наверное не стоит, т.к. большинство дисков не SSD.
т.е. диск SSD будет использоваться не оптимально.

Элементарно поймет. Посмотрит в  /sys/block/sdX/queue/rotational

2. Диск SSD будет работать в режиме "на убой". Любая линейная запись будет в первую очередь на него т.к. он самый быстрый?
А потом балансировка/автодефрагментация будет не используемые файлы с него перемещать..

Ну и что такого? Для этого и нужны быстрые SSD.

[Venom13]

Ну и что такого? Для этого и нужны быстрые SSD.

Тоже верно.
Но надо тестировать на сколько верно работает алгоритм.

Допустим. Массив на 6 Tb в котором стоит 128 Gb SSD.
Виртуальные машины просто летают, т.к. запись/чтение с SSD.
И диску не "больно", т.к. циклов записи не больше чем при обычном использовании.
Редко используемые машинки вытесняются с SSD на обычные HDD...

Но довольно грустно будет выглядеть сценарий:
Качает торрентом (rsync, btsync, ..) 2 Tb файлов.
Сколько циклов перезаписи "сожжет в пустую" наш SSD?
А ведь быстрый SSD мы ставили не для этого..

[AnrDaemon]

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

[Venom13]

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

Ей всегда нужно думать.. 
Это заявленная "фишка" BTRFS:

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

Звучит интересно. Просто хочу с ней разобраться..
Пользователь добавил сообщение 19 Сентября 2016, 13:59:06:В этом сценарии больше всего не хватает некого атрибута, для папки..
"Использовать SSD" или нет.
Но ничего подобного я не нашел. И даже на уровне подтомов не получилось поменять структуру хранения.
А создавать несколько массивов BTRFS с разным набором типов дисков.. Это убивает всю идеологию подтомов и снепшотов.

[AnrDaemon]

А создавать несколько массивов BTRFS с разным набором типов дисков.. Это убивает всю идеологию подтомов и снепшотов.

м?

[Venom13]

м?

https://help.ubuntu.ru/wiki/btrfs?#%D0%BF%D0%BE%D0%B4%D1%82%D0%BE%D0%BC%D0%B0

[Sly_tom_cat]

Создал 3 подтома. Примонтировал их в разные точки монтирования.
Запустил конвертацию с изменением уровня RAID на одной точке монтирования... И все 3 подтома начали конвертацию. 
т.е. это чисто теоретическая возможность?
Или я что-то не так делаю?

Пока поддержка разных систем хранения реализована только для всей файловой системы btrfs в целом. В планах было сделать различие в поддержке для отдельных томов - но вроде как это пока еще не сделано. Или если и сделано - то пока не понятно как это настроить. Балансировка она балансирует всю ФС.

Пользователь добавил сообщение 19 Сентября 2016, 18:03:31:Гибридные пулы - пока только идея: https://btrfs.wiki.kernel.org/index.php/Project_ideas#Hybrid_Storage

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

[Venom13]

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

Вот. Теперь все стало на свои места...