Расширение raid массива

если сервер не падал с полки

Ты всё ещё не прочитал, что такое UER в дисках (и различие его в десктопных/энтерпрайзных дисках)

Возможно я не прав, но по-моему этот калькулятор сломан. Я выставил характеристики для своего рейда, и получил вероятность успешного ребилда 0%, на любых доступных настройках вероятности ошибок. Хотя в ходе тестирования я делал ребилд 4 раза. Учитывая, что у меня постоянно глючат и зависают любые компьютеры, я не верю, что с дисками мне настолько везёт.

еще раз: есть массив, который допустим даже неделю назад успешно прошел операцию проверки. есть SMART, в котором 0 пендингов (= неустойчиво читаемых секторов) и реаллокейтов. вопрос: какая вероятность что на блинах сразу двух дисков за эту неделю появились сектора с uncorrectable error?

можно порядок цифр хотя бы.

Ты уже забыл, с чего начался разговор… А начинался от калькулятора широко известной ситуации на raid5 вида:

один диск сдох, массив превратился в raid0, в момент после добавления нового диска и ресинка на него на одном из оставшихся дисков случился UER, raid-контроллер/mdadm тут же сказал «у меня лапки, восстанавливайтесь из бэкапа».

Мне тоже показалось, что там есть баги. Это был первый попавшийся калькулятор из гугла, но есть и другие. Да и методики расчёта этих вероятностей тоже много где расписаны и обсуждались, легко гуглится по «raid 5 rebuild failure probability» или даже просто «raid 5 is dead».

Вот тут вроде работает нормально: https://www.raid-failure.com/raid5-failure.aspx

Везение тут ни при чём. Просто все эти «вероятности» берутся с потолка и не имеют никакого отношения к реальности.

Я выставил характеристики для своего рейда, и получил вероятность успешного ребилда 0%, на любых доступных настройках вероятности ошибок.

Что у тебя за конфигурация такая?

Просто все эти «вероятности» берутся с потолка

Вообще-то они берутся из спеков производителя к дискам.

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

Так в том и вопрос, как производители получают эти цифры и можно ли им доверять.

У меня таких ссылок нет (как и вообще особого интереса к теме), но есть сильное ощущение, что активно используется вот эта классическая методика в сочетании с какой-то статистикой: https://en.m.wiktionary.org/wiki/pull_out_of_one%27s_ass

Тут нет raid 1 и raid6, не сравнить. Интересно именно сравнение разных конфигураций.

Нашел еще такой калькулятор, он немного про другое, но тоже позволяет оценить вероятность проблем) Еще бы single disk варианты для наглядности.

https://wintelguy.com/raidmttdl.pl

Было бы круто, если бы у btrfs был нативный full-disk encryption, а так приходится собирать сначала raid, потом luks поверх.

Там не будет FDE, но FBE (fscrypt) уже где-то в пути.

в чем проблема сделать LUKS, а потом btrfs поверх?

или просто дешевые refurbished попались? :)

Так и есть

Спасибо, но мне это мало о чём говорит. Я в своё время тоже интересовался расчётом надёжности рейдов, покак не пришёл к мысли об абсолютной бессмысленности данной процедуры ввиду сомнительной достоверности исходных данных. И да, если что, то я читал про все эти телкордии, мили, фидесы и прочие стандарты оценки надёжности, коих больше десятка, и чем больше я о них читал, тем сильнее крепло моё убеждение в «сферичности» предоставляемых производителями данных. Если почитать спецификации, то легко заметить, что в них фигурируют зачастую одни и те же цифры, и это при том, устройства принадлежат к разному классу, к разным ценовым категориям, изготовлены на разных производственных площадках с применением разной элементной базы. А показатель MTTF у них условно один и тот же – 2 млн. часов. Причём нередки случаи когда для бытовых моделей указываются более высокие показатели MTTF, чем для серверных. И ещё раз, откуда такие круглые числа? Почему 2000000, а не, скажем, 1995500 или 2387488? Даже если предположить что это некие пороговые значения, то во-первых, почему не указывается отклонение, а во-вторых, они всё равно у каждого производителя должны отличаться. Или взять пресловутый UBER. Нетрудно заметить что он тоже для всех стандартный: либо 10^15, либо 10^16, либо 10^17 (гораздо реже). Бывают и больше, но это уже исключения. Замечу что разница между этими значениями ровно в тысячу раз. Как так? Почему не (хотя бы) 10.2^16 или 9.8^16? Вобщем, как я это вижу: существует множество абстрактных моделей оценки надёжностей, которые учитывают бесчисленное число (и в различных пропорциях) таких же абстрактных показателей и в результате получаются те самые цифры что мы видим в брошюрах производителей. А натурные испытания если и проводятся, то их вклад в итоговый результат минимален.

А что будет, если при открытии btrfs из двух устройств ты введешь ключ от одного, а от второго - нет?

Btrfs не будет монтироваться без всех устройств, если не указан параметр «degraded».

Это плохо. Зеркало должно монтироваться, если устройство отсутствует, но при этом не должно быть такой фигни, что если пользователь ошибся при вводе пароля, все сломалось и требуется ресинхронизация. По этому два luks на каждый диск это плохое решение.

Я в своё время тоже интересовался расчётом надёжности рейдов, покак не пришёл к мысли об абсолютной бессмысленности данной процедуры ввиду сомнительной достоверности исходных данных

Если тебе оказалось не совсем понятно то, что по ссылке, то примерный эквивалент в русском языке (ну, как мне кажется, потому что у меня с обоими не всё гладко) — «высасывать из пальца». При этом я думаю, что на статистику всё же смотрят, но в основном это всё равно извлечение чисел из нетрадиционных источников, немного инженерной интуиции и «квалифицированного технического писательства»©.

Зеркало должно монтироваться, если устройство отсутствует

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

администратор это кожаный ублюдок который ничего не решает