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

[Resquer]

Вобщем ну его этот 10-й раид - лучше 1-й!

Это точно.
Хорошо, что я виртуалку для тестов поднял.. Данные с md1 выводиться еще полдня будут (54% за 4,5 часа только прошло), есть время потренироваться.
Пользователь добавил сообщение 15 Сентября 2016, 14:10:43:

Ну, в принципе можно и так. Но мне кажется это может быть медленнее чем rsync-ом в чистую FS.

Единственное, чем rsync с созданием новой ФС предпочтительнее, то это тем, что это безопаснее для данных. То есть если свет отключат, система повиснет и т.п.
Но этот вариант только в том случае катит, когда хватает места для двух копий всех данных. Перенос средствами btrfs удобнее, когда всех дисков сразу нет и можно переносить поэтапно - добавил новый диск, сделал btrfs device delete, потом еще раз с новым диском произвёл btrfs device add и т.д.
Пользователь добавил сообщение 15 Сентября 2016, 14:47:14:Кстати, тут осенило. Ведь если я создам второй btrfs том, то перенести с первого тома данные туда можно же и не через rsync, а используя btrfs send? Какие подводные камни и что предпочтительнее? Как мне кажется (надо пробовать), rsync не перенесёт специфичные для btrfs параметры, такие как флаг C на папки (nodatacow) и т.п.

[AnrDaemon]

и mdadm, и LVM при использовании btrfs - просто теряют смысл.

LVM да, а вот mdadm нет.
raid56 в btrfs до сих пор считается экспериментальной фичей, IIRC.
У меня BTRFS поверх RAID6 висит.

[Sly_tom_cat]

Resquer, Да, пожалуй send - receive должен быстрее rsync-а быть.

LVM да, а вот mdadm нет.
raid56 в btrfs до сих пор считается экспериментальной фичей, IIRC.
У меня BTRFS поверх RAID6 висит.

Ну про raid56 в данном случае речи не шло - речь шла о raid1(10).

А насчет btrfs поверх mdadm raid6 - вполне себе решение.... пока raid56 не объявлены хотя-бы стабильными. - с этим я соглашусь.

[Resquer]

Что то я туплю неподеццки с этими send|receive. Уже глаз замылился, направьте на путь истинный, где я косячу.
Дано: 2 фс btrfs, смонтированы в /mnt и в /mnt2
Сабволумов не делал, ну то есть всё по-умолчанию.
Хочу с /mnt2 среплицировать данные на /mnt
Так как исходная система должна быть readonly, то приходится делать снапшот:

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

btrfs subvolume snapshot -r /mnt2 /mnt2/test
sync
btrfs send /mnt2/test | btrfs receive /mnt/Всё зашибись, но в приёмнике тоже создаётся ридонли subvolume, то есть я в /mnt наблюдаю папку test с ридонли содержимым.
А как мне в /mnt получить писабельную реплику /mnt/test, без всяких subvolume? Не врубаюсь.

[Venom13]

btrfs send /mnt2/test | btrfs receive /mnt/

Первое что на ум приходит, попробовать вместо:
btrfs send /mnt2/test | btrfs receive /mnt/
Ввести:
btrfs send /mnt2/test | btrfs receive /mnt
(сам не пробовал)

[Resquer]

Venom13, Не, это ни на что не влияет

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

root@testcomp:/mnt2# btrfs send /mnt2/test | btrfs receive /mnt
At subvol /mnt2/test
At subvol test
root@testcomp:/mnt# btrfs subvolume list /mnt2
ID 262 gen 18 top level 5 path test


[Sly_tom_cat]

Без подтомов такая тема не прокатит. Объясняю:
Вы создали скриншот корневого (id=5) подтома (он всегда есть) и положили его в сам этот самый корневой подтом. Если бы писали индусы - на такой операции могла бы упасть система ибо вы по сути бесконечно-рекурсивную операцию запросили. Но код писали не индусы и btrfs как-то выкрутилась. Точно так же она как-то выкрутилась отправляя/получая снимок.

Сделайте лучше все по понятной схеме.
Все данные из корня в подтом, а потом рядом - снимок этого подтома - его и слать.
Тогда должно быть все нормально на стороне приемника должен создаваться RW подтом.
Но в принципе можно и не парится - подтому RW свойство можно снять через btrfs prop set /mnt/test ro false

А хотите на приемнике убрать подтом и скинуть все в корневой подтом - просто командой mv перенесите все из подтома test в коревой.
Пользователь добавил сообщение 15 Сентября 2016, 17:16:17:Кстати - еще вариант (не пробовал но может прокатить)

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

btrfs prop set /mnt2 ro true
btrfs send /mnt2 | btrfs receive /mnt
btrfs prop set /mnt ro false
Ведь сенду в принципе не важно что слать - снимок или подтом (вернее сказать между снимком и подтомом просто нет различий) - главное что бы он был в RO.

[Resquer]

Sly_tom_cat, ладно, это я как нить потом, на досуге побалуюсь, а сейчас мне времени терять неохота, md1 удалил, поставлю переносить данные rsync-ом, т.к. мне в этом разбираться не надо - знаю.

[thunderamur]

PS df - на btrfs показывает среднюю температуру по бальничке или квадрат от скорости сферического коня в вакууме.

я это замечал на 14.04, на 16.04 df показывает информацию на основе утилит btrfs.

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

btrfs fi df -h /
Data, single: total=13.00GiB, used=7.62GiB
System, single: total=4.00MiB, used=16.00KiB
Metadata, single: total=1.01GiB, used=327.23MiB
GlobalReserve, single: total=112.00MiB, used=0.00B

df -h /
Файл.система   Размер Использовано  Дост Использовано% Cмонтировано в
/dev/sda1         50G         8,1G   42G           17% /

du -sh /
9,5G /

btrfs de us /
/dev/sda1, ID: 1
   Device size:            50.00GiB
   Data,single:            13.00GiB
   Metadata,single:         1.01GiB
   System,single:           4.00MiB
   Unallocated:            35.99GiB
Пользователь добавил сообщение 16 Сентября 2016, 10:14:06:

т.к. и mdadm, и LVM при использовании btrfs - просто теряют смысл.

я думаю смысл mdadm + btrfs все-таки есть, т.к. в случае установки системы на mdraid система сама загрузчик ставит на диски в массиве, можно самому скопировать, но все же. Кроме того в последствии нет необходимости ручной загрузки деградированного массива.
Пользователь добавил сообщение 16 Сентября 2016, 10:22:10:

Вобщем ну его этот 10-й раид - лучше 1-й!

учитывая как он реализован в btrfs, действительно лучше 1-й)
Но блин, зачем все эти большие массивы если с образами дисков работает не айс, мб все таки сравнить производительность btrfs без cow с xfs при использовании под образы ВМ. Только сейчас у меня стенда норм нет, все ЖД стоят в домашнем сервачке и подключены через SAMBA, что может отразиться на результате даже в относительном выражении. А то вдруг окажется, что btrfs без cow не хуже XFS для файлов-образов.

[Resquer]

я думаю смысл mdadm + btrfs все-таки есть, т.к. в случае установки системы на mdraid система сама загрузчик ставит на диски в массиве, можно самому скопировать, но все же. Кроме того в последствии нет необходимости ручной загрузки деградированного массива.

Конкретно в моём случае - это неважно, т.к. у меня этот массив не загрузочный, а тупо большая файлопомойка, плюс сторадж под owncloud.

А по поводу RAID1 на 4х попарно неравных дисков - субъективно чисто средствами btrfs будет лучше по скорости. Рассмотрим 3 варианта: 
1. В случае 2-х массивов mdadm и lvm сверху - получаем банальный JBOD из двух массивов. Скорость чтения/записи - как с единственного диска.
2. Если делаем 2 массива mdadm и том btrfs сверху типа single (уже без lvm), собранный из этих 2х массивов - то субъективно получается быстрее, т.к. данные пишутся наподобие страйпов, кусочками на оба диска сразу, это видно через atop. Да и заполняемость дисков примерно с одинаковой скоростью идёт- проверяется через btrfs filesystem usage.
3. Массив RAID1 из 4-х дисков без прослойки mdadm - всё тоже самое, только запись сразу на 4 диска, нет чётких правил основной диск/зеркало, данные пишутся рандомно на все диски с таким условием, чтобы были дублирующие блоки как минимум на 2х дисках.

Я уже не могу это точно проверить, т.к. разрушил и lvm и mdadm, сейчас массив конвертится с single в raid1, еще до вечера наверное будет маслать. Но вчера, когда я переносил данные rsync-ом c lvm на single том btrfs, было видно, что данные писались на оба диска сразу и скорость передачи данных была гораздо выше, чем когда я первоначально переносил данные lvm->lvm в пределах одной группы томов. Для примерного ориентира - в первом случае скорость была 80-110Мб/сек, во втором - 100-160Мб/сек

[Sly_tom_cat]

Но блин, зачем все эти большие массивы если с образами дисков работает не айс

Я думаю цели под массивы могут быть разными - не только образа виртуалок....

Но по поводу образов VM on XFS vs VM on BTRFS wo COW - тут точно надо бы потестировать... только я бы еще профиль VM on BTRFS with COW включил в тест.

[Venom13]

Но блин, зачем все эти большие массивы если с образами дисков работает не айс ..

А откуда вообще взялось это утверждение?
У меня несколько витруалок работает на чистом RAID5 BTRFS..
Субъективно - ощущаю только плюсы.
Бекапы "на лету" - вообще чудо..

P.S. COW я отключил далеко не сразу.
(да, пере создавал файлы чтобы COW на них отключился)
На глаз разницы не заметил. И с включенным COW все прекрасно работало..
Но тут, скорее всего, со временем начнет падать производительность.
Опять же, если autodefrag с этим не справится.

[thunderamur]

Venom13, значит ты можешь провести тесты. Тут нужно в цифрах, а не на глаз. Можно даже без массива, просто на одном диске создать маленький раздел XFS, разместить там новый образ под ВМ, поставить Ubuntu (я думаю это относительно хороший тест различных сценариев работы) с замером времени, благо, что ставится она быстро (только сеть отключить, т.к. разное время скачивания пакетов испортит тест ФС). Потом этот же раздел форматнуть в Btrfs и то же самое на ней, если получится для Btrfs с и без COW.

[Venom13]

Venom13, значит ты можешь провести тесты.

На данный момент у меня проблема в том, что все диски уже в массиве.
А чтобы выкинуть диск из массива - уйдет много времени.
Но я планировал на днях добавить туда ещё пару жестких дисков.
Вот на одном из них и проверю..

[Sly_tom_cat]

Вот на одном из них и проверю..

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