б) Появились файлы с битыми битами.

AFAIK, нет. Если массив смог перестроиться, то ты ничего не потеряешь. Кроме времени на перестроение массива. И пары нервных клеток.

/мимокрокодил

там в рассчетах 512бит сектора. сейчас в дисулях по 4к чуть менее, чем везде

Это несущественные детали.

По-моему, это ключевая деталь, делающая все расчёты неактуальными.

Вот собрал я супер-упоротый рейд-5 на 20 10тб дисках. Гарантированно словил глюки на ребилде. Какие глюки?

ЕМНИП ошибка на ребилде приводит к остановке ребилда.

В постановке моего вопроса глубоко наплевать сколько потеряется: бит, байт, сектор, 100мб. Вопрос не в этом.

Вот про md-рейд можешь почитать:

https://raid.wiki.kernel.org/index.php/RAID_Recovery
https://raid.wiki.kernel.org/index.php/Recovering_a_failed_software_RAID

С железными (и псевдожелезными) рейдами ищи вендорские материалы

(предполагаю) Но я не думаю, что там алгоритмы из разряда «раз не смогли прочитать сектор в начале диска, то и в конце даже пытаться не будем - не осилим».

К сожалению, мне подходит только аппаратный (да с контроллером за несколько сотен). И интересует общий поход, а не вендорские маркетинговые фишки.

Еще раз:
На ребилде словил ошибку чтения. Дальше что?

по формуле, успех оказался ещё меньший, если 5ый массив из 7 2тб дисков:

веголишь 0.348

а там 0.38 было.

Ну я смотрю на 6й или даже 60й.

Только вопрос в другом.

Общего подхода нет, это зависит от вендора.
В HP SmartArray, например, ребилд останавливается после ошибки, и выводится сообщение «пересоздайте рейд и восстановите данные из бэкапа».

Дальше что?

Backup often.

Ну а что еще? Вендор raid гарантий с возмещением убытков не даст - а вероятность отказа есть всегда.

Считай что дешевле - потеря файлов, бекап какой-то части файлов (от 0 до 100%) или обращение в сервисную службу при отказе. Вероятность самого отказа на raid разных типов и разных вендоров тоже придется считать, да. Это называется business continuity plan.

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

К счастью, лично не сталкивался, но для себя выбрал ZFS (raidz) именно из-за этого.

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

С точки зрения работы RAID, именно так и надо делать.

RAID он на уровне носителя (блочного устройства) работает, а не единичных файлов. Возникла хоть одна ошибка - сделавательно носитель запорот и требуется процедура восстановления.

а т.к. там XOR используется (по крайней мере в 5), то как ты предлагаешь действовать системе восстановления, как она почует правильный вариант? допустим половина дисков отдаёт одно, другая половина другое. какой вариант выберешь? алгоритмичиски это не решаемо никак.

судя по всему ему вообще рейд не нужен, раз он лишь о файлах думает.

нужно отказоустойчивое файлохранилище, а не RAID, который работает уровнем ниже.

Если дисков много - подними raid10 и не парься. Или вообще кластеризуй fs а не харды

сдается мне ты прав и тс пытается решать задачу немножечко не тем инструментом

Рейд - не бекап. Нужен только чтобы быстро воткнуть новый винт вместо сдохшего и обеспечить 0 времени простоя. Если рейд не пересобрался, то все данные на всех дисках превращаются в дуб.

А вообще смотри snapraid. Удобная штука.

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

На ребилде словил ошибку чтения. Дальше что?

невозможно восстановить массив данных. rebuild failed. goodbye.

А есть raid, которые в таком случае ругаются, но пытаются прочитать дальше те блоки данных, которые таки получилось прочитать?

Для меня цели рейда:
- некоторая страховка от отказа физики (один диск с браком вылетел - плевать, вствляем запасной из дисковой полки, в смысле берем с полки, сдуваем пыль, ребилдим);
- повышение производительности массива (мне надо ну хотя бы 500-800мбайт\сек);
- большая емкость с учетом первых двух пунктов (мне лучше рейд на 10тб, чем один диск на 10 тб).

Бэкапы и резервные текущие копии данных - есть (хотя недавно все равно умудрился обосраться). На отдельном хосте.

Вопрос в другом:
Ошибка чтения при ребилде. Дальше что?!

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

Потеряли весь массив? Потеряли часть данных? Часть - плевать. Весь - пичаль, тлен, тоска.

Как оно на практике то? Какого хрена он отказывается ребилдить «целые» данные?

Но ведь весь носитель - он не один логический 0 или 1. Он же «длинный». Ну вот в этой области запороли, а в этой контроллер мамой клянется, что каждый бит верен. Чего бы не иметь опцию отребилдить хотя бы целое? Или я совсем чушь несу?

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

Да пусть хоть монетку кидает (если я разрешил это в опциях). Для меня не проблема чутка битого файла, это не страшно.
А «какой выбрать» - потому и хочу R-6, вместо R-10.

Вполне допускаю, что я даже не понимаю того, о чем рассуждаю. Потому и тема.

Мне не нужна отказоустойчивость любой ценой за бешеное бабло и куча девяток надежности. Мне нужна некоторая страховка от проблем с механикой и т.п., повышение скорости массива (ссд на терабайты - дорого, и риски выше). И оно должно быть в хосте, а не по сети доступно. И хост должен быть строго на венде. Поэтому zfs\raidz и прочее, что мне тут умные люди советуют (не сарказм) я не могу применить.

Если дисков много - подними raid10 и не парься.

Уже. На двух хранилках. Но мне кажется, что R-6 безопаснее будет. Есть еще вариант упороться до R-60, но это уже слишком.

Или вообще кластеризуй fs а не харды

Не прокатит.

А если я хочу восстановить то, что восстанавливается и плевал на битую область? Так не бывает что ли? Ну вот на трех дисках в массиве сразу сдох, допустим, 1549й сектор. Один и тот же везде. Массив переживает отказ только двух дисков, мы гарантированно потеряли часть данных безвозвратно. И что? А если меня это устраивает? И я не хочу везти все диски в сервис и платить им (заслуженно, спору нет) кучу денег? Я хочу согласиться с потерей _части_ данных. Это возможно на каком-то контроллере, с кучей «отказ от грантий» и «да, я дурак», или нет?

И оно должно быть в хосте, а не по сети доступно. И хост должен быть строго на венде. Поэтому zfs\raidz и прочее, что мне тут умные люди советуют (не сарказм) я не могу применить.

Открой для себя infiniband.

За какой бюджет можно получить производительность сопоставимую с «прямо в хосте»? Ну т.е. все важные параметры (я даже хз как сформулировать), т.е. не только линейный однопоток, но и многопочность, задержки и т.п. и т.д.

Кажется, я начал догадываться

«Бытовые» диски не советуют в рейды, ибо они могут надолго уйти в себя в попытках чтения и не откликнуться за установленное время. Выходит, что если диск ну никак не может вычитать область, то его контроллер откидывает и все ребилдит? А можно ли явно указывать в опциях «читай, что осталось»?

Твой прямовхост упирается в DMI, особенно на чипсете X99.

Шнур 60 долларов 3 метра.

Карточки по 50-100 баксов, естественно не новые.

Еще также понадобится HBA адаптер для жестких, т.к. стандартный DMI - УГ.

http://www.zeta.systems/blog/2016/09/21/iSCSI-vs-iSER-vs-SRP-on-Ethernet-&amp...

Но учти, что результаты получены в операционной системе, а не вна куске говна.

А на 10гбе меди реально? А если с LACP? Просто карточки двухпортовые уже есть. Можно попробовать.

LACP без свича управляющего возможен? (хост-хост)

Чуть выше тест, медь просто отсасывает с заглотом и стоит дороже. Нафиг тебе агрегация на 40/56 гбит?

Да, уже вижу.
А венда же умеет все это клиентом, да ведь?

А по начинке копа для этого массива какие потребности? Сколько нужно рамы, скажем, на 10тб массив? Сильно ли нужен проц?

Под венду есть более медленный SRP, но он быстрее чем iSCSI, iSER нет.

Процессора уровня core i5, ryzen 1400 хватит. Памяти не могу сказать сколько, т.к. не знаю как твой софт обращается к файлам, возможно 16 гб до смерти хватит. Если данные чувствительны к повреждениям, то обязательно нужен ECC. И обязательно, если контроллер HBA, нужен ИБП! Для аппаратного контроллера можно на него забить, так как там требуется батарея.

Еще вместо HBA может хватить матплаты с socket 1151, т.к. там 32 гбит на DMI.

Таки, надо рассмотреть вариант.
Но у него есть серьезный минус - сам не осилю, надо кого-то выбрать к кому обратиться (дело не в деньгах). И еще, не люблю пользоваться тем, в чем вообще не понимаю.

Тут проблема в том, что даже 8 жестких не нагрузят эту сеть толком, а 8*2 тб ssd обойдутся в $3500.

На ребилде словил ошибку чтения. Дальше что?

Я же тебе говорил уже много раз - дальше всё.

Какое именно «все»? Оно штатно никак ничего не отдаст?

А на каких принципах происходит чудо с zfs и т.п.? Там же те же диски с 10^-14 ошибки. Те же большие объемы. Те же взаимно усиливающиеся вероятности отказа.

Такое «всё» - rebuild failed, bye-bye. Штатно - не отдаст, нет массива.

В случае с ZFS тебе в свойствах пула после ресильвера будет сообщение «битый блок в таком то файле, восстанови его из бэкапа»

Я в возмущении :)

Уже. На двух хранилках. Но мне кажется, что R-6 безопаснее будет. Есть еще вариант упороться до R-60, но это уже слишком.

Эх...

Raid - он не для надёжного хранения придуман, а для отказоустойчивого (и/или для скорости). При всей схожести понятий - это разные вещи. Для надёжного хранения есть разные системы резервного копирования от сменных hdd в рэках до стримеров.

Пусть том будет из 8 дисков (WD red), производительность важнее надежности (но не полностью в ущерб полседней), какое железо надо на хост хранилки, чтоб не упираться в него? Проц\память. По материнке? Без наворотов хватит?

Пусть том будет из 8 дисков (WD red), производительность важнее надежности (но не полностью в ущерб полседней)

Такая конфигурация уже примерно сравняется по стоимости с терабайтными SSD. Или даже дороже выйдет.

WD30EFRX x 8 x 6600 руб = 52 200 руб (хотя 4 диска уже есть, почти новые). Это всего лишь одна 2тб ссдшка 850й серии. Хотя задуматься заставляет, да.

А что ты вообще хочешь сделать? Есть задачи где тебе нужен не относительно маленький SSD, например на 256-512Гб, куда бы ты копировал рабочие файлы, а сразу 2Тб?