Эксперимент с btrfs: 24 диска и 2 гигабита записи на них

Есть линукс, на нём 24 харда по 3 TB.
Вопрос: как-то это тюнится?

Необходимо добавить ещё 24 диска.

Заменой на lvm/zfs/ceph/etc.

очень хотелось проверить.

Какая разница между lvm и mdadm?

24 диска в RAID 0? Да это самоубийство! Один диск вылетит и тютю данным. А дисков 24, то есть вероятность потери данных в 24 раза больше чем при одном диске.

Уровнем абстракции. Mdadm ниже по уровню чем LVM. (Поправьте меня если неправ)

Зачем?

И какой сценарий использования - записывают сначало все потоком в 2Гбит/с а потом читают, или это все одновременно происходит?

Что за данные? Нужна ли им вообще фс? (если это один файл потока данных, то можно обойтись и без этого)

Есть вариант использовать вообще tar поверх raid, если это предназначено для хранения в стиле «записали быстро и оставили в покое до лучших времен)

2 гбита это не жутко медленно для 24 дисков то? Я бы сказал п-ц как медленно.

Если это одновременно чтение и запись в произвольные места, то даже 24 диска будут плохо себя чувствовать. Если же это линейная запись, то и 3 диска пормально вытянут, это ведь всего 256МиБ/с

raid0 на 24 харда? я боюсь за тех, кто вас окружает

Если серьёзно, то вы бы хоть подробности привели, а то ничего не понятно

Как много не понимающих слово «эксперимент» в этом треде.

+1

Перепись зануд-извращенцев.

А по сабжу - btrfs is deprecated :-)

2 гигабитных порта видать всего.

mdadm - софтовый рейд, и все. lvm, грубо говоря, позовяет объединять устройства в одно, и поверх лепить все что угодно, тупые разделы, снапшоты, разделы с кешем, разделы с зеркалированием а-ля рейд1, мигрировать их с устройства на устройсвто. В общем они для разных задач.

не, ты чего, с запасом тянет

Ниверю (с)

Вот 146% даю что если начать шуровать одновременно и записью и чтением (рандом 4к) по 2 Гбит/с даже такой жирный рейд не выдержит.

Это тогда получается по 21МиБ/с общей нагрузки на диски, ни один такое не выдержит (если именно случайная запись-чтение)

Да даже коли на весь рейд всего 2Гбит/с навалить нагрузки он не осилит. (это больше 11МиБ/с на диск)

Вот пруфцы сего днища: http://hdd.userbenchmark.com/

Я тебе советую посмотреть в сторону NILFS2, вот что будет блистать на такой скорости записи!

(а btrfs как была так и осталась тормозистором среди фс)

Хватает с огромным запасом пока диски забиты менее чем на 90%

Мне нужно видео писать, те данные вообще можно грохать большими пачками.

Btrfs явный оверкил но дает лучше распределение нагрузки чем mdadm

В lvm вроде есть механизмы распределения нагрузки, кстати.

А по сабжу - btrfs is deprecated :-)

Не вижу тут: https://btrfs.wiki.kernel.org/index.php/Main_Page

по 2 Гбит/с

что за маджик константа такая?

Предположим, что 24 диска - не самой первей свежести.
Узнаем, что btrfs - умеет создавать snapshots, то есть back up's

Автор, арийско верно указал, что использует RAID 0.
Таки в его случае, перёвёл бы конфигурацию на RAID5-6.

Не вижу тут

да-да, этот ресурс, на который ты дал ссылку - истина в последней инстанции..

24 харда
рейд 0

такое количество винтов...да там походу синк постоянно происходит ))) с винта на винт)

(а btrfs как была так и осталась тормозистором среди фс)

то есть в шаблонных тестах на похорониксе она блистает, а в экспериментах безумных русских линуксоидов сливает?

да-да, этот ресурс, на который ты дал ссылку - истина в последней инстанции..

А что, нет ?

Блин, подробности-то дайте, мне интересно стало

Так это вы btrfs на 98% забили данными? ну тогда конечно тормозить будет, это же copy-on-write

у меня nodatacow.

Поясню, чего у меня за эксперимент.

Надо проверить, есть ли удобный способ средствами линукса записывать видео с камер наблюдения на большой сторадж.

Под удобством подразумевается:

1) выход из строя диска _может_ приводить к потере данных, но желательно не более чем 1/n данных. Такое приемлемо для многих клиентов

2) перегрузка одного диска не должна приводить к отказу всей системы. Диск забит — пишем на другой. Как вариант, можно писать везде параллельно

3) исходим из того, что записи примерно в 100-1000 раз больше чем пользовательского чтения

4) всё это можно в доступной форме объяснить стороннему админу неизвестной квалификации

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

Какие паттерны использования? Всё в целом похоже на tar, но с индексом. Т.е. данные пишутся в конец, потом с начала можно целыми блоками грохать.

Грубо говоря, за пару недель можно написать вполне работающий код, который вообще обходится без ФС, но это перебор.

Пробовал mdadm. Там беда получается такая: три диска загружены на 100% по минуте, остальные холодные стоят.

Попробовал btrfs (nodatacow). Пока диск пустой, всё очень красиво: все диски поровну нагружены. Когда диск забит на 98%, то не получается запуститься, dmesg полон:

[17759.359389] INFO: task flussonic:5882 blocked for more than 120 seconds.
[17759.359409]       Not tainted 4.4.0-21-generic #37-Ubuntu
[17759.360173] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[17759.360936] flussonic       D ffff88053faa7c08     0  5882   5860 0x00000000
[17759.360939]  ffff88053faa7c08 0001ffff00000001 ffff880152438000 ffff88083ce20000
[17759.360941]  ffff88053faa8000 ffff8807c545a9f0 ffff8807c545a800 ffff8807c545a9f0
[17759.360942]  0000000000000001 ffff88053faa7c20 ffffffff818203f5 ffff8802af7a81b0
[17759.360944] Call Trace:
[17759.360947]  [<ffffffff818203f5>] schedule+0x35/0x80
[17759.360959]  [<ffffffffc02b1fb3>] wait_current_trans.isra.21+0xd3/0x120 [btrfs]
[17759.360962]  [<ffffffff810c3a10>] ? wake_atomic_t_function+0x60/0x60
[17759.360972]  [<ffffffffc02b38db>] start_transaction+0x2cb/0x4c0 [btrfs]
[17759.360981]  [<ffffffffc02b3ae8>] btrfs_start_transaction+0x18/0x20 [btrfs]
[17759.360992]  [<ffffffffc02b921f>] btrfs_dirty_inode+0x9f/0xd0 [btrfs]
[17759.361002]  [<ffffffffc02b92cf>] btrfs_update_time+0x7f/0xc0 [btrfs]
[17759.361005]  [<ffffffff812291c8>] touch_atime+0xa8/0xd0
[17759.361006]  [<ffffffff8118efd7>] generic_file_read_iter+0x537/0x5c0
[17759.361008]  [<ffffffff8120c154>] new_sync_read+0x94/0xd0
[17759.361009]  [<ffffffff8120c1b6>] __vfs_read+0x26/0x40
[17759.361011]  [<ffffffff8120c776>] vfs_read+0x86/0x130
[17759.361012]  [<ffffffff8120d685>] SyS_pread64+0x95/0xb0
[17759.361014]  [<ffffffff818244f2>] entry_SYSCALL_64_fastpath+0x16/0x71
[18838.025659] perf interrupt took too long (2506 > 2500), lowering kernel.perf_event_max_sample_rate to 50000
[32364.979729] flussonic[9724]: segfault at 200 ip 00000000004f839d sp 00007f63c38c6d78 error 4 in beam.smp[400000+319000]

это же copy-on-write

Это btrfs. Тормоза из copy-on-write никак не следуют.

выход из строя диска _может_ приводить к потере данных, но желательно не более чем 1/n данных. Такое приемлемо для многих клиентов

Я так думаю, (любой) RAID0 в этом случае в пролёте.

Когда диск забит на 98%, то не получается запуститься, dmesg полон:

Not tainted 4.4.0-21-generic #37-Ubuntu

В первую очередь проверяем на самом последнем ядре.

Тормоза из copy-on-write никак не следуют

В случае SSD - не следуют. Но тут речь о хардах.

Пока диск пустой, всё очень красиво: все диски поровну нагружены. Когда диск забит на 98%

Я снова ничего не понял. Что за «диск»?

не

когда диск забит на 98%

а

когда суммарный раздел забит на 98%

Я так думаю, (любой) RAID0 в этом случае в пролёте.

и да, и нет. Если подмонтировать 24 харда с обычной ext4 и раскидывать по ним файлики, то получится доморощенный RAID0 с изоляцией хардов и независимыми потерями. Видимо это прийдется делать, но хочется попробовать избежать

они же поровну нагружены значит любой

Ну если вся ФС забита на 98%, то Btrfs здесь в пролёте, да.

Если подмонтировать 24 харда с обычной ext4 и раскидывать по ним файлики, то получится доморощенный RAID0 с изоляцией хардов и независимыми потерями.

Ну ты как будто не знаешь, что такое RAID0. RAID0 — это striping, т. е. все файлы равномерно размазаны по всем дискам. Если ты теряешь любой диск из N, то ты не «теряешь 1/N данных», а получаешь много мелких дырок во всех файлах, т. е. портятся все файлы.

В случае SSD - не следуют. Но тут речь о хардах.

Следует для древних фрагментированных партиций, а он новыми данными заполнил 98%. Там нет фрагментации.

Может лучше xfs, проверенная, с многопоточной записью и без излишеств btrfs ?

http://www.phoronix.com/scan.php?page=article&item=linux-412-fs&num=2

Lol XD

Если нужно писать постоянно и потом по кругу уничтожать старое, то не нужны рейды

1 монтируем 1 диск

2 создаем раздел nilfs2

3 пишем до упора(отключив чистку мусора этой фс)

4 отмонтируем

И так далее

Соедини диски попарно в рейд, на каждый рейд ext4 а поверх засандаль aufs (overlay неумеет в множественные ветки в rw), она будет более-менее равномерно распределять запись по дискам.

ИМХО единственный разумный вариант в котором не теряются все файлы сразу. Если иски не тормозные, можно и без рейда так же.

Читай заголовок топика.

тут надо изрядно попрогать и непонятно зачем тогда вообще nilfs, если уже будет без разницы какая FS.

проверю xfs, спасибо!

ты рекомендуешь lvm + xfs?

да, как то вяло)

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

Вещь очень специфическая но в некоторых обстоятельствах оно может пригодиться

Есть корзина на 16 hdd по 4 тб в raid6 на md, ФС XFS, свободно 1гб. Не тормозит ничего. Юзкейс как у тебя, только софт не твой :)

Есть корзина на 16 hdd по 4 тб в raid6 на md

реально raid6 на 16 дисках? т.е. 14 + 2избыточных? Необычно для меня. Уже замену диска пробовал делать? Просто, по моим понятиям на таком количестве дисков надо делать raid60, по конфигурации например (6+2) + (6+2). Хотел бы просветиться

А смысл делать страйп из страйпов :)

Ребилд идёт медленно, и это минус, зато места дофига, а это плюс. И потом, этож видеоархив, ну сдохнет все и хрен с ним, новый сбилдим. А вот, то что терять нельзя у нас на другой корзине: 2 HBA по 8 hdd с raidz2 на каждом в зеркале.