В серверах есть ускорители с 48 вольт, но там питание через материнку передаётся и мощности другие (400 Вт * 8 ускорителей на материнку = 3.2 кВт) и с обратной совместимостью ситуация другая.
Это будет совсем другой разъём, а Molex Mini-Fit Jr. из 80-х в компьютеры ставило не одно поколение людей. И мы поставим (только уменьшим его). В компьютерах много этого "мы сделаем так, потому что так уже делали в нашей сфере".
припаять по 6 проводов [чтобы они оказались соединены друг с другом]
Такой вариант 12VHPWR/12V-2x6 есть, но есть и классический "провод -> клемма -> обжать -> усиками в колодку".
Странно, что никто тут* не заметил фатальную ошибку.
Меня заинтересовала лицензирование патента в 2002 году «Анонимным» игроком на рынке, немного загуглив, любой может выведать информацию о том, с какой технологией в тот месяц вышел процессор серии Pentium 4. И ему понравилось настолько, что он решил продлить патент еще на 8 лет, а потом на 12. Думаю выводы более менее очевидны.
Событие в 2002 - это уплата пошлины за продление патента, платит её владелец патента (AMD и потом GloFo) в USPTO. По правилам USPTO её необходимо платить на четвёртом, восьмом и 12-м году, что там и написано.
Не знаю, как USPTO считает 3.5 года. Тут это 365*3.5 дней
Википедия в качестве первого (?) патента называет патент Sun 1994 года. Кто патентами атаковал, кто патентами защищался, кто кому лицензировал право пользования - неизвестно и на patents.google.com не отмечается.
Двоичные приставки в статью попали по ошибке. Ёмкость накопителей измеряют с десятичными приставками*. В этом можно убедиться, глядя на ёмкость, указанную без приставок.
IBM 350 Model 1. Накопитель вмещал 3.75 мебибайт данных
"50000 records of only 100 characters each" - старый IBM Systems Journal. То есть 5 миллионов 6-битных символов, 3.75 десятичных МБ. Это первый жёсткий диск, дальше правило не нарушали.
StorageTek STC 4305 вмещал 45 МиБ данных
Возьмём его версию на 11.2 каких-то МБ. 14660 bytes per track * 768 tracks per drum = 11 258 880 байтов ~= 11.3 десятичных МБ ~= 10.7 двоичных МБ. То есть его паспортные мегабайты - десятичные (всё как и у HDD-аналога, тоже по ссылке).
Dataram BulkCore состоял из шасси с восьмью планками RAM-памяти объемом 256 КиБ каждая.
Единственное исключение из-за его RAMDisk'овости. Видно намёк на двоичную круглость, при этом тип памяти не тот, чтобы в разницу между приставками прятать служебный объём (256 КиБ - 256 КБ = 6144 байт), как это делается в SSD на флеш-памяти. Также он позиционируется как блок оперативной памяти (отличная замена для жёстких дисков DEC, а также отличная замена для блоков памяти DEC; короче, купите уже), а в этой сфере приставки более двоичны и менее десятичны двоичные.
в контексте информационных технологий подразумевают как десятая и двадцатая степень двойки
Неграмотно - биты в секунду имеют десятичные приставки (но биты ёмкости микросхем - двоичные приставки). Накопители, опять же. На них не давит желание задействовать всё адресное пространство, потому что у них большие ёмкости. Также они появились во времена плюрализма на тему количества битов в байте; если тебя не окружают степени двойки (см. 6-битные символы выше, а также 36-битные архитектуры и BCD) - значит, ещё минус одна причина придерживаться двоичных приставок.
Для исключения путаницы были введены двоичные приставки киби-, меби- и другие.
И в статье мы видим последствия этого. Эти прапорщики от академий думали, что смогут заставить весь мир отказаться от старых контекстно-зависимых приставок и поэтому не стали придумывать новые однозначно-десятичные приставки. "Мир, от старых приставок откажись! Раз-два". Теперь у нас есть мегабайты, которые могут новыми, точно десятичными, а могут быть старыми, контекстно-зависимыми.
* исключения есть, но не в случае с HDD и SSD-помимо-RAMDisk'ов. Дискеты на 1.44 рекламных двоично-десятичных МБ, CD на 700 двоичных МБ.
Вода высокой степени очистки, используемая в системах охлаждения, стоит около 300$/литр.
А травить жизнь не дешевле? Что будет, если использовать более обычную воду и ЧАС? И ингибитор коррозии вроде уротропина, если я правильно предполагаю следующую проблему. Или один уротропин, если полагаться на его биоцидные свойства.
Он и не на 4090 из обзора играть будет, вероятно. Так что для настоящего обзора надо хотя бы три разрешения, четыре видеокарты... и шапочку.
А если упрощать работу обозревателя - то хотя бы 1080p на старшей карте. Упор в видеокарту в реальных условиях можно будет прикинуть иначе.
Второй смысл - попытаться заглянуть в будущее на тот случай, если менять видеокарты чаще процессора. Скажем, раньше занижение разрешения показало перспективы AMD FX, но будущую недостаточность 4/4 не показало.
Noctua берёт много денег за то, что она чуть-чуть лучше остальных, но в данном случае даже не лучше. Сначала Noctua работала на репутацию, а теперь репутация работает на Noctua.
А так современные подшипники все хороши по надёжности и шуму
В компьютерных вентиляторах ли? Там постоянно ставят обычные подшипники скольжения и называют их гидродинамическими (гидравлическими, гиперпоточными...), чтобы ассоциировались с условно-вечными подшипниками HDD.
Смазка есть? Есть. Крутится? Крутится. Значит гидродинамический. "Ну? Что я тебе говорил? Я тебе продал цветной телевизор".
Быстро изнашиваются, получаем биения, вибрации, шум.
Раньше было сравнение, где проволочная то ли лидировала, то ли почти ("technically the quietest grill, but it raises the pitch of the fan noise making it more noticeable").
Noctua ещё бюрократию упоминает: пальцы важнее ушей, приходится соблюдать требования к минимальному размеру отверстий.
Видимо, говорят о токе в рамках таких-то* допущений, потому что плотность пользователь узнать не сможет.
* только аномальный разряд, только сравнения в пределах одной модели индикатора (а то и одного катода этой модели), изолированная арматура, забота производителя о равномерности плотности тока (а не как в индитронах)
___
Ещё в тему: первый индикатор Далибора Фарни. Неон-аргон, изоляция катодной арматуры, но неадекватное напряжения зажигания (320 В) и дальний катод не зажигается целиком.
Рабочий ток около 2 мА. При пропускании через неё 7-8 мА в течение нескольких десятков минут, Ni проволочные электроды заметно распылились.
Читал, что "the rate of sputtering increases as the 3rd or higher order function of cathode current" (страница / весь апноут), это даёт аналогичное распыление за 20+ часов на 2 мА.
7.5[мА]^3 * 1/3 [часа] = 2[мА]^3 * x[часов] x ~= 20 часов
Ту лампу ещё специально адаптировали под динамическую индикацию, поднимая давление для уменьшения распыления (предыдущая страница).
Ещё они сильно хвалили ртуть как средство от катодного распыления в своих патентах. Не знаю, как это работает. (также патентовали пары органического полимера, но патент бесполезен - он говорит лишь, что это полимер, органический и испаряющийся во время работы).
>> Про URE можно не вспоминать - сортировку RAID'ов по надёжности она не меняет.
Конечно же, меняет. Вот у вас RAID-5, один диск вылетел, пошел ребилд, и бац - ошибка. Или на сохранившейся половине зеркала. Что дальше? А в случае RAID-6?
Не меняет "RAID6 > RAID5", потому что если забыть про URE, то всё равно остаётся вероятность смерти диска (MTBF/AFR).
В сравнении "RAID6 > RAID10" ненулевой URE играет на пользу RAID6 (в degraded RAID10 у нас degraded-зеркало не защищено от URE), а ненулевой AFR может играть на пользу RAID10 (быстрее ребилд - меньше шанс смерти диска; есть шанс пережить смерть >2 дисков в большом массиве), а может не играть (degraded-зеркало не защищено от потери диска). Тот калькулятор говорит, что последний фактор в разумных условиях (не "2 диска чётности на 100 дисков с данными") перевешивает, то есть "RAID6 > RAID10" независимо от URE.
Кто начал? Точно не я.
"А на одиночном диске вы эту ошибку при чтении просто не увидите. Читающее приложение получит некорректные данные" - это утверждение о том, что в RAID мы её увидим при чтении (а не только при scrub'е).
Нам, в конечном счете, нужна не только информация о том, что данные побились, но и, крайне желательно, коррекция этих данных. RAID-6 коррекцию "тихих" может обеспечить сам по себе. 5 - нет, вот и всё. Я не понимаю, в чем тут может быть предмет спора.
Не знаю, как вы перешли к этому от "Учитывая, что scrub как функция присутствует примерно в любом массиве, большинство считает, что все-таки полезное".
Наверное, мы оба сойдёмся на том, что scrub (тот, который сверка копий или чётности) не должен быть первой линией обороны от тихих ошибок (типа "а между scrub'ами пусть читается мусор").
5 - нет, вот и всё
Кстати, случайно наткнулся на утверждение Dell (habr/archive.org), что они могут: "For example, three drives in a RAID 5 array will be compared to ensure that the data and the parity are using the correct values. If a single error[*] is detected, the remaining data and/or parity will be used to re-write and correct the bad value".
[*] и вокруг уточняется:в том числе "logical error", "logical data errors"; "The physical LBA is good" (у-у-у, физико-логический сектор).
И за это спасибо. Но там видится два больших подвоха:
Проверка чётности во время scrub'а может обнаружить ошибку, которую в ходе обычного чтения перехватила бы проверка Identity ("Note that data scrubs are unable to validate the extra file system identity information")
Misdirected read не упоминается среди причин. Scrub мог обнаружить непостоянную ошибку, которая связана с запуском scrub'а. В этом случае scrub бесполезен - нет пользы от того, что мы "вышли на себя", поможет только проверка Identity.
UPD: вообще говоря, непонятно, может ли проверка чётности обнаружить хоть какую-то ошибку из тех, которые пропустит проверка Identity. Статья интересна сама по себе, но как доказательство, что "не обнаружат" вроде бы не годится.
К слову о жабах. При отказе двух дисков в RAID5 мы теряем все данные из-за страйпинга, а не только данные одного диска.
Жаба спрашивает: почему бы тогда не выкинуть страйпинг? Но мы всё равно будем терять часть данных на выживших дисках как в JBOD (aka Span) - на живых дисках не будет целой файловой системы и файлы могут простираться между дисками (выживут лишь обрывки). Чтобы этого избежать, нужно объединение на файловом уровне, а не блочном (как mergerfs вместо JBOD/Span).
Жаба спрашивает: почему бы тогда не объединять диски на файловом уровне вместо блочного? В итоге жаба своими вопросами достала людей и они сделали Unraid и SnapRAID.
Сравнивать термояд с орбитальными кипятильниками - это пошло. Запихнуть звезду в бублик - сложно. Запульнуть кипятильник - дорого. Орбитальные кипятильники упираются в бюджет, под них надо планировать масштабную миссию на внешних планетах, а на них деньги не дают. Как на марсианский пилотируемый облёт или флаговтык - не можем, что ли? Можем, больше 60 проектов было, но дорого и недостаточно престижно, надо лететь надолго.
И еще раз - исходная картинка в целом не про то, что там может или не может md или еще какая-то софтина для организации рейдов. Она про то, что вероятность получить неисправимый косяк на рейде с одиночной четностью или зеркалом значительно выше, чем получить его же на рейде с двойной четностью.
Да при чём тут это, я указал на ошибку составителя картинки - он не смог связать в голове теоретический URE и практическую частоту ошибок, получаемую при scrub'е. Похоже на фейнмановское "Я обнаружил очень странное явление: я задавал вопрос, и студенты отвечали, не задумываясь [не задумываясь брали 10^-14 из даташита]. Но когда я задавал вопрос еще раз - на ту же тему и, как мне казалось, тот же самый вопрос, они вообще не могли ответить! [не понимают последствия числа за пределами сценария degraded RAID]".
Указал, потому что меня задевает религиозно-мифический характер этой ошибки. Имею в виду статью о том, что RAID0 надёжнее, чем RAID5 и исступлённые реакции на неё (в ответ иронизируют: "Using RAID-5 Means the Sky is Falling!").
Да, несмотря на эту ошибку RAID5 опаснее, чем RAID6, нам здесь не о чем спорить. Одно дело, когда мы можем пережить отказ 1 диска. Другое дело, когда 2 диска. Про URE можно не вспоминать - сортировку RAID'ов по надёжности она не меняет.
Потом переключились на обсуждение тихих ошибок.
это уже решать тому, кто массив эксплуатирует
А я откажу ему в таком праве. Начали с того, что RAID при чтении на лету сверяет копии (чётность). Оказалось, что нет. Теперь цепляемся за шанс получить информацию о том, что данные побились в прошлом. Это слишком сомнительный подход, если нас волнуют тихие ошибки и непостоянные ошибки вроде misdirected read он не обнаружит.
большинство считает, что все-таки полезное.
Нет, большинство не считает, что scrub существует для борьбы с тихими ошибками в условиях отсутствия контрольных сумм для данных.
Это сугубо вопрос конкретной реализации.
Ars Technica утверждает, что "most arrays don't check parity by default on every read". Где сделано не так?
Если кто-то использует md в корпоративных хранилках или на больших массивах - ну, это его личный выбор.
В таких условиях могут зародиться контрольные суммы для данных (T10-PI и т.д.), которые и обнаружат тихие ошибки. Обнаружат независимо от RAID'ов, о которых мы говорим.
Они существуют, потому что общая вероятность получить сбои мала
Или потому что она для нас велика, иначе зачем нам вообще RAID. Причём адекватно среагировать классический RAID может только на "громкую" ошибку, о которой сообщит сам диск. Если их не гораздо больше, чем тихих - зачем нам RAID? Мне эта версия кажется более логичной.
Только во время scrub'а. А при обычной работе будет выдавать мусор. md: "RAID1 ...Changes are written to all devices in parallel. Data is read from any one device".
Знание, что данные побились месяц назад - не очень полезное. Если данные горячие, то они к моменту scrub'а могли перезаписаться и даже этого знания не будет. Если холодные, то толку как от прикладывания md5 к файлам на одиночном диске (без массива).
А в две - уже сможет и исправить.
Но в том же md не станет. Соседняя ветка комментариев.
Ну очевидно же, что это не так - в рейде не совпадет четность или данные на зеркалах.
Уже который раз пишу - она проверяется только во время scrub'а.
И да, реальные вероятности ошибок, возможно, и сильно ниже, чем там на скрине написано, но качественной картины это не меняет.
Не вижу смысла.
Касательно долей "громких" (бэд-блоки) и "тихих" ошибок в URE: классические RAID'ы и классические файловые системы (без контрольных сумм для данных) ещё существуют, потому что URE в основном состоит из "громких" ошибок.
Диск обычно справляется со своей работой (обнаруживать ошибки) и проблема тихих ошибок становится чем-то вроде проблемы памяти без ECC.
Касательно последствий того, что URE ниже верхней границы заявленного: RAID5 в 2009 не переехал в учебник* к RAID2-4 именно поэтому. Крупные диски без массива удаётся использовать тоже поэтому.
* Тут не нужен virtue signalling на тему опасности RAID5, скрытого подтекста нет, там буквальное "не переехал в учебник".
Это заблуждения №1 + №3 по первой ссылке (или здесь в соседней ветке о том, что классическому RAID'у нет дела до тихих ошибок - то есть тоже бы не увидели). URE - частота ошибок, которые не исправились с помощью ECC.
Unrecoverable Error — A read error that cannot be overcome by an ECC scheme or by rereading the data when host retries are enabled - westerndigital.com
Давайте аналогию с ECC RAM проведём.
Там SECDED ECC обнаруживает и исправляет ошибки в 1 бите.
Обнаруживает ошибки в 2 битах.
А ошибки в 3 и более битах может принимать за однобитные или пропускать. Silent data corruption начинается тут.
У вас получилось так, словно второго этапа не существует. Перескочили на третий пункт, вероятность которого гораздо ниже и отдельно не указывается (URE включает в себя в себя второй).
Ещё к 1: например, для md RAID есть подтверждение, что он игнорирует проблему "тихих" ошибок. "If a mismatch is detected in a RAID-6 configuration, it should be possible to figure out what should be fixed", но это требует допущения, что данные побились только на одном диске и этой возможностью не пользуются. check лишь отмечает, что на дисках есть несоответствие, repair лишь заново считает чётность.
От остальных реализаций логично ждать примерно того же, тихими ошибками занимается другой слой (T10-PI / dm-integrity / zfs-btrfs-bcachefs / никакой).
Если бы массивы сверяли содержимое дисков не только время scrub'а, то они имели бы скорость одного диска, даже на линейном чтении. UPD: я тоже их допускаю, в полной мере замедление касалось бы RAID1.
Если бы они это делали, то и на RAID1 и RAID5 - тоже. Потому что иметь ошибку при расхождении данных на дисках лучше, чем иметь неверные данные.
UBER (aka URE) в основном состоит из "громких" ошибок, которые за счёт ECC обнаруживает сам диск. То есть он выдаёт не неверные данные, он выдаёт ошибку.
И одну не дурацкую - термин BER используют в том числе для "сырых" ошибок (RBER), которые штатно исправляются через ECC на диске. UBER/URE точнее.
В серверах есть ускорители с 48 вольт, но там питание через материнку передаётся и мощности другие (400 Вт * 8 ускорителей на материнку = 3.2 кВт) и с обратной совместимостью ситуация другая.
Это будет совсем другой разъём, а Molex Mini-Fit Jr. из 80-х в компьютеры ставило не одно поколение людей. И мы поставим (только уменьшим его). В компьютерах много этого "мы сделаем так, потому что так уже делали в нашей сфере".
Такой вариант 12VHPWR/12V-2x6 есть, но есть и классический "провод -> клемма -> обжать -> усиками в колодку".
Странно, что никто тут* не заметил фатальную ошибку.
Событие в 2002 - это уплата пошлины за продление патента, платит её владелец патента (AMD и потом GloFo) в USPTO. По правилам USPTO её необходимо платить на четвёртом, восьмом и 12-м году, что там и написано.
Википедия в качестве первого (?) патента называет патент Sun 1994 года. Кто патентами атаковал, кто патентами защищался, кто кому лицензировал право пользования - неизвестно и на patents.google.com не отмечается.
* гугл сообщает, что на overclockers.ru заметили.
(Некропост)
Двоичные приставки в статью попали по ошибке. Ёмкость накопителей измеряют с десятичными приставками*. В этом можно убедиться, глядя на ёмкость, указанную без приставок.
"50000 records of only 100 characters each" - старый IBM Systems Journal. То есть 5 миллионов 6-битных символов, 3.75 десятичных МБ. Это первый жёсткий диск, дальше правило не нарушали.
Возьмём его версию на 11.2 каких-то МБ. 14660 bytes per track * 768 tracks per drum = 11 258 880 байтов ~= 11.3 десятичных МБ ~= 10.7 двоичных МБ. То есть его паспортные мегабайты - десятичные (всё как и у HDD-аналога, тоже по ссылке).
Единственное исключение из-за его RAMDisk'овости. Видно намёк на двоичную круглость, при этом тип памяти не тот, чтобы в разницу между приставками прятать служебный объём (256 КиБ - 256 КБ = 6144 байт), как это делается в SSD на флеш-памяти. Также он позиционируется как блок оперативной памяти (отличная замена для жёстких дисков DEC, а также отличная замена для блоков памяти DEC; короче, купите уже), а в этой сфере приставки
более двоичны и менее десятичныдвоичные.Неграмотно - биты в секунду имеют десятичные приставки (но биты ёмкости микросхем - двоичные приставки). Накопители, опять же. На них не давит желание задействовать всё адресное пространство, потому что у них большие ёмкости. Также они появились во времена плюрализма на тему количества битов в байте; если тебя не окружают степени двойки (см. 6-битные символы выше, а также 36-битные архитектуры и BCD) - значит, ещё минус одна причина придерживаться двоичных приставок.
И в статье мы видим последствия этого. Эти прапорщики от академий думали, что смогут заставить весь мир отказаться от старых контекстно-зависимых приставок и поэтому не стали придумывать новые однозначно-десятичные приставки. "Мир, от старых приставок откажись! Раз-два". Теперь у нас есть мегабайты, которые могут новыми, точно десятичными, а могут быть старыми, контекстно-зависимыми.
* исключения есть, но не в случае с HDD и SSD-помимо-RAMDisk'ов. Дискеты на 1.44 рекламных двоично-десятичных МБ, CD на 700 двоичных МБ.
В 0.2e1 раз.
А травить жизнь не дешевле? Что будет, если использовать более обычную воду и ЧАС? И ингибитор коррозии вроде уротропина, если я правильно предполагаю следующую проблему. Или один уротропин, если полагаться на его биоцидные свойства.
Он и не на 4090 из обзора играть будет, вероятно. Так что для настоящего обзора надо хотя бы три разрешения, четыре видеокарты...
и шапочку.А если упрощать работу обозревателя - то хотя бы 1080p на старшей карте. Упор в видеокарту в реальных условиях можно будет прикинуть иначе.
Второй смысл - попытаться заглянуть в будущее на тот случай, если менять видеокарты чаще процессора. Скажем, раньше занижение разрешения показало перспективы AMD FX, но будущую недостаточность 4/4 не показало.
Так это ссылка на вентиляторы, а он про кулеры.
Картинка
Noctua берёт много денег за то, что она чуть-чуть лучше остальных, но в данном случае даже не лучше. Сначала Noctua работала на репутацию, а теперь репутация работает на Noctua.
В компьютерных вентиляторах ли? Там постоянно ставят обычные подшипники скольжения и называют их гидродинамическими (гидравлическими, гиперпоточными...), чтобы ассоциировались с условно-вечными подшипниками HDD.
Смазка есть? Есть. Крутится? Крутится. Значит гидродинамический. "Ну? Что я тебе говорил? Я тебе продал цветной телевизор".
Быстро изнашиваются, получаем биения, вибрации, шум.
Фото решётки, которую она заменяет
Раньше было сравнение, где проволочная то ли лидировала, то ли почти ("technically the quietest grill, but it raises the pitch of the fan noise making it more noticeable").
Noctua ещё бюрократию упоминает: пальцы важнее ушей, приходится соблюдать требования к минимальному размеру отверстий.
Видимо, говорят о токе в рамках таких-то* допущений, потому что плотность пользователь узнать не сможет.
* только аномальный разряд, только сравнения в пределах одной модели индикатора (а то и одного катода этой модели), изолированная арматура, забота производителя о равномерности плотности тока (а не как в индитронах)
___
Ещё в тему: первый индикатор Далибора Фарни. Неон-аргон, изоляция катодной арматуры, но неадекватное напряжения зажигания (320 В) и дальний катод не зажигается целиком.
https://www.daliborfarny.com/first-sample-nixie-tube/
Читал, что "the rate of sputtering increases as the 3rd or higher order function of cathode current" (страница / весь апноут), это даёт аналогичное распыление за 20+ часов на 2 мА.
7.5[мА]^3 * 1/3 [часа] = 2[мА]^3 * x[часов]
x ~= 20 часов
Ту лампу ещё специально адаптировали под динамическую индикацию, поднимая давление для уменьшения распыления (предыдущая страница).
Ещё они сильно хвалили ртуть как средство от катодного распыления в своих патентах. Не знаю, как это работает. (также патентовали пары органического полимера, но патент бесполезен - он говорит лишь, что это полимер, органический и испаряющийся во время работы).
Не меняет "RAID6 > RAID5", потому что если забыть про URE, то всё равно остаётся вероятность смерти диска (MTBF/AFR).
В сравнении "RAID6 > RAID10" ненулевой URE играет на пользу RAID6 (в degraded RAID10 у нас degraded-зеркало не защищено от URE), а ненулевой AFR может играть на пользу RAID10 (быстрее ребилд - меньше шанс смерти диска; есть шанс пережить смерть >2 дисков в большом массиве), а может не играть (degraded-зеркало не защищено от потери диска). Тот калькулятор говорит, что последний фактор в разумных условиях (не "2 диска чётности на 100 дисков с данными") перевешивает, то есть "RAID6 > RAID10" независимо от URE.
"А на одиночном диске вы эту ошибку при чтении просто не увидите. Читающее приложение получит некорректные данные" - это утверждение о том, что в RAID мы её увидим при чтении (а не только при scrub'е).
Не знаю, как вы перешли к этому от "Учитывая, что scrub как функция присутствует примерно в любом массиве, большинство считает, что все-таки полезное".
Наверное, мы оба сойдёмся на том, что scrub (тот, который сверка копий или чётности) не должен быть первой линией обороны от тихих ошибок (типа "а между scrub'ами пусть читается мусор").
Кстати, случайно наткнулся на утверждение Dell (habr/archive.org), что они могут: "For example, three drives in a RAID 5 array will be compared to ensure that the data and the parity are using the correct values. If a single error[*] is detected, the remaining data and/or parity will be used to re-write and correct the bad value".
[*] и вокруг уточняется: в том числе "logical error", "logical data errors"; "The physical LBA is good" (у-у-у, физико-логический сектор).
Спасибо, интересно. Хотя написано так расплывчато и подозрительно, что надо читать диплом с сайта СПбГУ (pdf), чтобы убедиться.
И за это спасибо. Но там видится два больших подвоха:
Проверка чётности во время scrub'а может обнаружить ошибку, которую в ходе обычного чтения перехватила бы проверка Identity ("Note that data scrubs are unable to validate the extra file system identity information")
Misdirected read не упоминается среди причин. Scrub мог обнаружить непостоянную ошибку, которая связана с запуском scrub'а. В этом случае scrub бесполезен - нет пользы от того, что мы "вышли на себя", поможет только проверка Identity.
UPD: вообще говоря, непонятно, может ли проверка чётности обнаружить хоть какую-то ошибку из тех, которые пропустит проверка Identity. Статья интересна сама по себе, но как доказательство, что "не обнаружат" вроде бы не годится.
К слову о жабах. При отказе двух дисков в RAID5 мы теряем все данные из-за страйпинга, а не только данные одного диска.
Жаба спрашивает: почему бы тогда не выкинуть страйпинг? Но мы всё равно будем терять часть данных на выживших дисках как в JBOD (aka Span) - на живых дисках не будет целой файловой системы и файлы могут простираться между дисками (выживут лишь обрывки). Чтобы этого избежать, нужно объединение на файловом уровне, а не блочном (как mergerfs вместо JBOD/Span).
Жаба спрашивает: почему бы тогда не объединять диски на файловом уровне вместо блочного? В итоге жаба своими вопросами достала людей и они сделали Unraid и SnapRAID.
Сравнивать термояд с орбитальными кипятильниками - это пошло. Запихнуть звезду в бублик - сложно. Запульнуть кипятильник - дорого. Орбитальные кипятильники упираются в бюджет, под них надо планировать масштабную миссию на внешних планетах, а на них деньги не дают. Как на марсианский пилотируемый облёт или флаговтык - не можем, что ли? Можем, больше 60 проектов было, но дорого и недостаточно престижно, надо лететь надолго.
Да при чём тут это, я указал на ошибку составителя картинки - он не смог связать в голове теоретический URE и практическую частоту ошибок, получаемую при scrub'е. Похоже на фейнмановское "Я обнаружил очень странное явление: я задавал вопрос, и студенты отвечали, не задумываясь [не задумываясь брали 10^-14 из даташита]. Но когда я задавал вопрос еще раз - на ту же тему и, как мне казалось, тот же самый вопрос, они вообще не могли ответить! [не понимают последствия числа за пределами сценария degraded RAID]".
Указал, потому что меня задевает религиозно-мифический характер этой ошибки. Имею в виду статью о том, что RAID0 надёжнее, чем RAID5 и исступлённые реакции на неё (в ответ иронизируют: "Using RAID-5 Means the Sky is Falling!").
Да, несмотря на эту ошибку RAID5 опаснее, чем RAID6, нам здесь не о чем спорить. Одно дело, когда мы можем пережить отказ 1 диска. Другое дело, когда 2 диска. Про URE можно не вспоминать - сортировку RAID'ов по надёжности она не меняет.
Потом переключились на обсуждение тихих ошибок.
А я откажу ему в таком праве. Начали с того, что RAID при чтении на лету сверяет копии (чётность). Оказалось, что нет. Теперь цепляемся за шанс получить информацию о том, что данные побились в прошлом. Это слишком сомнительный подход, если нас волнуют тихие ошибки и непостоянные ошибки вроде misdirected read он не обнаружит.
Нет, большинство не считает, что scrub существует для борьбы с тихими ошибками в условиях отсутствия контрольных сумм для данных.
Ars Technica утверждает, что "most arrays don't check parity by default on every read". Где сделано не так?
В таких условиях могут зародиться контрольные суммы для данных (T10-PI и т.д.), которые и обнаружат тихие ошибки. Обнаружат независимо от RAID'ов, о которых мы говорим.
Или потому что она для нас велика, иначе зачем нам вообще RAID. Причём адекватно среагировать классический RAID может только на "громкую" ошибку, о которой сообщит сам диск. Если их не гораздо больше, чем тихих - зачем нам RAID? Мне эта версия кажется более логичной.
Только во время scrub'а. А при обычной работе будет выдавать мусор. md: "RAID1 ... Changes are written to all devices in parallel. Data is read from any one device".
Знание, что данные побились месяц назад - не очень полезное. Если данные горячие, то они к моменту scrub'а могли перезаписаться и даже этого знания не будет. Если холодные, то толку как от прикладывания md5 к файлам на одиночном диске (без массива).
Но в том же md не станет. Соседняя ветка комментариев.
Уже который раз пишу - она проверяется только во время scrub'а.
Не вижу смысла.
Касательно долей "громких" (бэд-блоки) и "тихих" ошибок в URE: классические RAID'ы и классические файловые системы (без контрольных сумм для данных) ещё существуют, потому что URE в основном состоит из "громких" ошибок.
Диск обычно справляется со своей работой (обнаруживать ошибки) и проблема тихих ошибок становится чем-то вроде проблемы памяти без ECC.
Касательно последствий того, что URE ниже верхней границы заявленного: RAID5 в 2009 не переехал в учебник* к RAID2-4 именно поэтому. Крупные диски без массива удаётся использовать тоже поэтому.
* Тут не нужен virtue signalling на тему опасности RAID5, скрытого подтекста нет, там буквальное "не переехал в учебник".
Это заблуждения №1 + №3 по первой ссылке (или здесь в соседней ветке о том, что классическому RAID'у нет дела до тихих ошибок - то есть тоже бы не увидели). URE - частота ошибок, которые не исправились с помощью ECC.
Давайте аналогию с ECC RAM проведём.
Там SECDED ECC обнаруживает и исправляет ошибки в 1 бите.
Обнаруживает ошибки в 2 битах.
А ошибки в 3 и более битах может принимать за однобитные или пропускать. Silent data corruption начинается тут.
У вас получилось так, словно второго этапа не существует. Перескочили на третий пункт, вероятность которого гораздо ниже и отдельно не указывается (URE включает в себя в себя второй).
Ещё к 1: например, для md RAID есть подтверждение, что он игнорирует проблему "тихих" ошибок. "If a mismatch is detected in a RAID-6 configuration, it should be possible to figure out what should be fixed", но это требует допущения, что данные побились только на одном диске и этой возможностью не пользуются.
checkлишь отмечает, что на дисках есть несоответствие,repairлишь заново считает чётность.От остальных реализаций логично ждать примерно того же, тихими ошибками занимается другой слой (T10-PI / dm-integrity / zfs-btrfs-bcachefs / никакой).
Вы три дурацкие ошибки допускаете.
Если бы массивы сверяли содержимое дисков не только время scrub'а, то
они имели бы скорость одного диска, даже на линейном чтении. UPD: я тоже их допускаю, в полной мере замедление касалось бы RAID1.Если бы они это делали, то и на RAID1 и RAID5 - тоже. Потому что иметь ошибку при расхождении данных на дисках лучше, чем иметь неверные данные.
UBER (aka URE) в основном состоит из "громких" ошибок, которые за счёт ECC обнаруживает сам диск. То есть он выдаёт не неверные данные, он выдаёт ошибку.
И одну не дурацкую - термин BER используют в том числе для "сырых" ошибок (RBER), которые штатно исправляются через ECC на диске. UBER/URE точнее.