Как лучше хранить большой массив информации? mdadm / lvm / zfs / btrfs

Лесом идет те кто не делает fsync()

Я про другие тоже писал. Но дело не в этом. На мой взгляд, данной статистики достаточно, чтобы не заявлять «диски сыпятся пачками чуть ли не каждый день». Давай посчитаем: ты укажешь вероятность подыхания одного диска за день, любую какую считаешь нужной. Затем, исходя из неё, посчитаешь вероятность не-поломки за 70 диско-лет нагрузки. Потом, если что, скорректируешь исходную вероятность. Потом посчитаешь, исходя из неё же, поломку одновременно двух дисков их трёх запущеных в течение 2 суток на протяжении, например, 10 лет. Даже пусть у тебя будет фора - не-поломка это в данном случае идеальный смарт, а «сдохли два из трёх» это должно быть что-то достаточно плохое для вылета из массива (а на самом деле - вообще полное сдыхание диска без возможности снять дамп, иначе данные вполне восстанавливаются за недолго). Но поскольку оценить разницу вероятностей этих событий сложно, а бизнес-эффект от простоя на восстановление (если диск вылетел из массива но читается) тем более без деталей не узнать, то пропустим её.

Тут anc убеждает в обратном.

На мой взгляд, данной статистики достаточно, чтобы не заявлять «диски сыпятся пачками чуть ли не каждый день»

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

Давай посчитаем.....

Я тоже такого хочу.

Не внимательно читаете.

Забудьте про OpenZFS. Она пока не поддерживается в коммерческих системах и перспективы ее туманны.

Лесом идет те кто не делает fsync()

fdatasync()? А вообще грамотный txlog наше всё, конечно ;)

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

например:
Delphix и iXsystems занимаются коммерческой поддержкой решений на ZFS.

Интересно, спасибо.

Лучше в облако засунуть.

RAID6

чтобы при случайном удалении нужных данных они удалились с зеркал этого RAID?

язабан, честно.

надежное хранилище будет когда система в этом хранилище система будет бекапить твои данные в фоновом режиме не надеясь на всякие рейды.

ZFS

как скоро тс вернется на форум и закречит что при полезных 18гб пространства у него свободны всего пару гигабайт.

я уже предвкушаю ответы местных «шпециалистов» типа «создай снапшот и удали его» лол.

чушь.

Сколько пафоса-то. Проведи такой эксперимент на SmartArray P440ar с 24 дисками по 2.4ТБ. И я посмотрю на тебя.

емнип, это починили еще лет 10 назад.

не до конца, к сожалению, но да, поймать очень сложно.

то любая не CoW FS идет лесом.

тяжелый случай…

Это очевидный факт, его не нужно аргументировать.

Балаболка ты дешевая. «Очевидный факт», «всем известно», «это другое». Был о тебе лучшего мнения.

Ребилд все равно же лимитирован скоростью записи на новый диск и он будет одинаковым

В случае 5/6 там запись на несколько дисков, в том числе тех, что находятся под нагрузкой, т.к. это еще и ребаланс.

О боже мой, да всем насрать. Продолжай толкать проверенный временем snake oil, «не балаболка» ;)

Продолжай толкать проверенный временем snake oil, «не балаболка» ;)

Какой же вы неугомонный то. Перефразируя реплику из одного из моих любимых фильмов: сколько же километров нужно от..того ето чтобы такую чушь нести.

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

а то я сейчас лицо пробью от твоей натужной напыщенности.

Жду видео на YouTube. Надеюсь не разочароваться. Но к игнору вы близки. Останавливает что чушь приходится опровергать - тот объём damage который вы уже нанесли даже не смешон. Пионер, блин.

ссылка на драму есть?
у меня таких косяков за 4 года не наблюдалось.

В случае 5/6 там запись на несколько дисков, в том числе тех, что находятся под нагрузкой, т.к. это еще и ребаланс.

Для 5 это опасно, знаю. Но 6-му то похер, если он не из говна и палок конечно. И у 5 и у 6 запись на весь массив лимитирована одним диском, причем и в обычной эксплуатации и при ребилде. А на 10 в обычной эксплуатации скорость записи N/2, но при ребилде будет так же упираться в единичный диск. Мне кажется это ты и путаешь.

чушь приходится опровергать

Ну и как успехи на этом поприще?

тот объём damage который вы уже нанесли

Бгг. Смотри не порвись там.

Бгг. Смотри не порвись там.

Уровень «Бивиса и Батхеда» detected. Удачи.

Бгг

И таки в игнор, достал.

И у 5 и у 6 запись на весь массив лимитирована одним диском, причем и в обычной эксплуатации и при ребилде.

raidz2 из 8 HDD:

# dd if=/dev/zero of=bigfile bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes transferred in 24.141397 secs (424MB/sec) запись

# dd if=bigfile of=/dev/null bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes transferred in 20.760081 secs (493MB/sec) чтение

а вот scrub шёл со скоростью до 1ГБ/сек на больших файлах.

Примерно 5 ТиБ и около 5 300 000 файлов, очень разного размера, несколько сотен тысяч совсем мелких, по 5 КиБ, какие-то крупные, по несколько гибибайт. Эта группа будет активно обновляться, перезаписываться, удаляться. Тут, теоретически, данные сжимаемые, но не уверен, что это имеет смысл.

Коллеги, ZFS под это дело как-то тюнить надо?

Для 5 это опасно, знаю. Но 6-му то похер, если он не из говна и палок конечно.

Был у меня raidz2 из говна и палок - сильно тормозил =)

для обычной файлопомойки - нет.
для DB - надо.

Я про скорость ребилда. То, что оно на несколько дисков в случае 5/6 пишутся, уже просто причина длительности ребилда. А 10 ребилдится очень быстро и - самое главное - не аффектит остальной массив.

Судя по количеству правок, «я бежала за вами три дня и три ночи, чтобы сказать о том, как вы мне безразличны» :-D

Ну, в общем, запишу тебя как «разочарование 2021 года». Пополнишь довольно длинный список, кстати… урожайным год вышел.

То, что оно на несколько дисков в случае 5/6 пишутся

Слушай, а давай отделять мух от котлет, потому что:

10 ребилдится очень быстро

нет

не аффектит остальной массив.

да

Повторю, деградированный 10 по скорости ребилда (!) ничем не лучше деградированного 6 (5 считаю говном). В первом случае имеем чтение (n-1)/2 (если страйп из 2 зеркал) дисков с записью на 1 диск = скорость 1 диска, во втором случае имеем чтение/запись n-1 дисков и запись на 1 диск = скорость 1 диска. CoW почти исключает фрагментацию, поэтому ее не учитываю.

Соррян, тред читал не подробно, может уже и поздно что-то советовать, но вброшу пару тезисов.

1) Диски могут умирать молча. ОС делает попытку прочитать блок, а диск в ответ пыхтит и ничего не выдает.

Как это обычно обнаруживается. В массиве умирает или начинает умирать диск. Его заменяют и запускают восстановление массива. И тут обнаруживается, что на еще одном диске оказывается есть нечитаемые сектора. В случае зеркала или raid5 это конец данным.

И zfs, и mdadm умеют уменьшать вероятность такого сценария. В первом есть скраббинг, а во втором есть check-array, который нужно кроном гонять. Производительность, понятное дело, при check-array-е значительно падает, а времени он занимает прилично.

2) Железные рейды только для тех, у кого есть запасные железки. А также понимание, что железки взаимозаменяемы и их запаса хватит до конца эксплуатации массива.

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

3) zfs не умеет добавлять диски в raidz2 после его создания, в отличие от mdadm и raid6.

В mdadm это выглядит так, как описали выше — одной командой. Массив становится больше размером, и начинается «восстановление» массива, которое занимает продолжительное время.

Файловую систему на массиве тоже нужно будет расширять. Почему-то все рекомендуют это делать на непримонтированной системе. Загрузочная флешка/диск, даунтайм, ...

zfs этого не умеет вообще.

4) lvm кажется совершенно бесполезной тратой ресурсов для описанного сценария.

Мне кажется, lvm может помочь только если нужны квоты или что-то подобное. Если возможности lvm не нужны, думаю, что его нужно избегать, потому что накладные расходы от него есть.

5) ZFS технически может и хороша, но... Не могу не заметить, что ее оторвали от корней, причем как от родного для нее ядра, так и от разработчиков, не говоря уже о том, что она сама по себе довольно сложная.

Перспектив у zfs практически нет. В линукс ее не примут никогда: лицензия; Линус был против нарушений слоев абстракций всеми кроме btrfs.

Даже сейчас нельзя просто взять условный systemrescuecd и что-то с zfs сделать — нужно искать форки и т.п. Не думаю что через условные пять лет что-то улучшится, скорее наоборот.

6) В btrfs рейд-массивы вроде как не готовы к использованию. Оказалось, что нельзя просто так взять и сделать свою zfs.

7) ECC память, в общем-то, обязательна для любых массивов, где на диск пишут производные данные (raid5,raid6,raidz?). Связано это с тем, что ошибка даже в одном бите при расчете производных данных убивает эти данные. Без ECC ошибки происходят незаметно.

8) Про выбор между xfs и ext4 поверх mdadm/lvm, ничего сказать не могу.

9) Про саму ext4 могу сказать, что есть смысл при создании отключить резерв блоков для root-а. Он задается в процентах и на больших массивах он будет существенным.

10) UPS с автоматическим отключением при истощении батарейки — обязательно. Даже не смотря на журнал. Проверка файловой системы может стать утомительно долгой на больших объемах поверх массива жестких дисков.

Мне кажется, lvm может помочь только если нужны квоты или что-то подобное.

Какие такие квоты в LVM?

Какие такие квоты в LVM?

Плохо выразился, прошу прощения. Имел ввиду следующее.

LVM позволяет поделить все пространство на логические разделы нужного размера и монтировать их куда нужно. И по сути предоставляет квотирование дискового пространства. С дополнительной возможностью использования разных файловых систем для этих логических разделов.

Ну типа все пространство в 10 Tb разделим на раздел в 6 Tb для данных одного типа и на раздел 4 Tb другого типа. Примонтируем это в /mnt/data-1 и в /mnt/data-2.

Если сравнить с подходом, когда есть 10 Tb в /mnt/data и папки для данных /mnt/data/1/ и /mnt/data/2/,

То... LVM позволяет: 1) ограничить объем данных на разделах, 2) использовать разные ФС на разных разделах. 3) изменять размеры разделов. 4) дополнять имеющийся виртуальный диск в 10Tb новыми физическими дисками/массивами и затем использовать это физическое пространство в логических разделах.

Все это за счет увеличенной сложности и небольших накладных расходов на каждую файловую операцию.

Я хотел сказать, что на практике все вышеперечисленные пункты нужны не всем: (1) решается квотами файловой системы если нужно. (3) решает проблему привнесенную самим LVM, а (4) еще больше усложняет систему: делать выводы о том, отказ скольких дисков такая система переживет или из-за какого конкретно диска тормозит запись/чтение становится трудно.