Раньше было сравнение, где проволочная то ли лидировала, то ли почти ("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 точнее.
Более того, по таблице он развалится из-за того, что его невозможно прочитать без исправления-ошибок-на-лету. То есть при нормальной эксплуатации каждый scrub с вероятностью ~97% встречает ошибки, но они исправляются за счёт избыточности*, а когда массив degraded, то они ведут к потере данных**.
А если scrub не встречает ошибок? То настоящий URE гораздо ниже заявленного производителем - враньё спрятано в этом месте.
* А одиночные диски как, без массива? Полное чтение 8 ТБ тогда должно встречать ошибку в половине случаев.
** Перечисляют такие варианты: - Худший: заменили диск, запускается восстановление, контроллер решает прибить массив после встречи битого сектора. - Чуть лучше: процесс прерывается на битом секторе, успешно завершить без простоев и ручной работы с сыпящимся диском нельзя. - Лучший: битый сектор пропускается и на уровне массива тоже помечается как нечитаемый.
1.65 au до Солнца, то есть энергии там в 1.65^2 = 2.7 раза меньше. Вроде всё равно лучше реакторов и беспроблемнее (радиация, механика, хладагент, температуры, радиационно-безопасная орбита, перегрузка топлива в космосе...). Про цены ещё ничего не известно. Космический реактор - космически дорого. Новейшие тонкоплёночные панели какой-то огромной площади - космически дорого.
Если с другой стороны посмотреть, то когда-то жила идея, что C++ сможет заменить C и почти все на него перейдут. И у Страуструпа, вроде как, жила.
А потом умерла. И уже первый стандарт C++ как бы хоронил идею, требуя поддержку исключений в freestanding-режиме ("bare metal", не hosted). Можно найти высказывания Страуструпа, что C++ в ядрах ОС следует использовать именно с исключениями и в Linux тоже, он ссылался на чей-то эксперимент.
250 кг тонкоплёночных панелей на 2000 Вт/кг, выше ведь написал.
Проблема скорее в том, что спешить есть смысл только для доставки людей, а доставка людей на столь облегчённом корабле будет с кучей пересадок. Сначала пересесть на этот SEP-буксир (Solar Electric Propulsion) где-то за радиационными поясами, потом пересесть на спускаемый модуль около Марса, на обратном пути ещё две пересадки.
void memstream_done(MemStream *m) {
assert(m);
/* First, close file stream, as the buffer may be reallocated on close. */
safe_fclose(m->f);
/* Then, free buffer. */
free(m->buf);
}
Разбросано по файлам, но memstream_done переиспользуется около 40 раз.
С RAII-на-std::optional было бы что-то в духе этого:
// ...
std::optional<MemStream> m = MemStream::TryCreate();
// Вместо memstream_done - деструктор MemStream
// memstream_init пусть будет статическим методом TryCreate
if (!m)
return log_oom();
// ... (используем m->f)
Атрибут cleanup (GNU C) считают за RAII. Его используют в systemd.
Если это у вас три вызова new, то всё нормально, С++ за вами приберёт
Если мы вручную вызвали new, то нам вручную и вызывать delete. RAII нет.
Если мы как угодно получили ресурс в конструкторе RAII-контейнера, то нам его и освобождать в деструкторе, фокус на new не нужен.
Замена исключений (в конструкторе) на std::optional (в функции, создающей объект) - это, вроде как, лишь замена одного способа обработки ошибок на другой. if'ы вместо try-catch.
И ещё RAII вместо goto exit_N (но оно требует исключений, так что вероятно нет).
Основная идея RAII в освобождении ресурсов в ходе автоматического удаления объекта (поэтому, собственно, в названии идиомы нет ни освобождения, ни уничтожения...).
Почему отсутствие исключений не очень важно:
Не важно в деструкторе, потому что из него в любом случае не следует кидать исключения. Ещё RAII требует, чтобы освобождение ресурсов не могло сломаться, ядро Linux обычно тоже из этого исходит.
А что до acquisition & initialization, то придётся, например, удалить конструктор и собирать объект функцией, возвращающей std::optional (или как-нибудь погрязнее).
Фото решётки, которую она заменяет
Раньше было сравнение, где проволочная то ли лидировала, то ли почти ("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 точнее.
Более того, по таблице он развалится из-за того, что его невозможно прочитать без исправления-ошибок-на-лету. То есть при нормальной эксплуатации каждый scrub с вероятностью ~97% встречает ошибки, но они исправляются за счёт избыточности*, а когда массив degraded, то они ведут к потере данных**.
А если scrub не встречает ошибок? То настоящий URE гораздо ниже заявленного производителем - враньё спрятано в этом месте.
* А одиночные диски как, без массива? Полное чтение 8 ТБ тогда должно встречать ошибку в половине случаев.
** Перечисляют такие варианты:
- Худший: заменили диск, запускается восстановление, контроллер решает прибить массив после встречи битого сектора.
- Чуть лучше: процесс прерывается на битом секторе, успешно завершить без простоев и ручной работы с сыпящимся диском нельзя.
- Лучший: битый сектор пропускается и на уровне массива тоже помечается как нечитаемый.
1.65 au до Солнца, то есть энергии там в 1.65^2 = 2.7 раза меньше. Вроде всё равно лучше реакторов и беспроблемнее (радиация, механика, хладагент, температуры, радиационно-безопасная орбита, перегрузка топлива в космосе...). Про цены ещё ничего не известно. Космический реактор - космически дорого. Новейшие тонкоплёночные панели какой-то огромной площади - космически дорого.
Если с другой стороны посмотреть, то когда-то жила идея, что C++ сможет заменить C и почти все на него перейдут. И у Страуструпа, вроде как, жила.
А потом умерла. И уже первый стандарт C++ как бы хоронил идею, требуя поддержку исключений в freestanding-режиме ("bare metal", не hosted). Можно найти высказывания Страуструпа, что C++ в ядрах ОС следует использовать именно с исключениями и в Linux тоже, он ссылался на чей-то эксперимент.
Да им не привыкать.
Нет, с Си так и поступили. Он тоже много всякого позволяет, но договорились об определённом подмножестве.
Например: The Linux Kernel Is Now VLA (Variable-Length Array) Free
250 кг тонкоплёночных панелей на 2000 Вт/кг, выше ведь написал.
Проблема скорее в том, что спешить есть смысл только для доставки людей, а доставка людей на столь облегчённом корабле будет с кучей пересадок. Сначала пересесть на этот SEP-буксир (Solar Electric Propulsion) где-то за радиационными поясами, потом пересесть на спускаемый модуль около Марса, на обратном пути ещё две пересадки.
К слову о том, что делает systemd.
В одном файле:
В другом файле (а структура MemStream тут):
Разбросано по файлам, но
memstream_doneпереиспользуется около 40 раз.С RAII-на-std::optional было бы что-то в духе этого:
Атрибут cleanup (GNU C) считают за RAII. Его используют в systemd.
Если мы вручную вызвали new, то нам вручную и вызывать delete. RAII нет.
Если мы как угодно получили ресурс в конструкторе RAII-контейнера, то нам его и освобождать в деструкторе, фокус на new не нужен.
Замена исключений (в конструкторе) на std::optional (в функции, создающей объект) - это, вроде как, лишь замена одного способа обработки ошибок на другой. if'ы вместо try-catch.
Основная идея RAII в освобождении ресурсов в ходе автоматического удаления объекта (поэтому, собственно, в названии идиомы нет ни освобождения, ни уничтожения...).
Почему отсутствие исключений не очень важно:
Не важно в деструкторе, потому что из него в любом случае не следует кидать исключения. Ещё RAII требует, чтобы освобождение ресурсов не могло сломаться, ядро Linux обычно тоже из этого исходит.
А что до acquisition & initialization, то придётся, например, удалить конструктор и собирать объект функцией, возвращающей std::optional (или как-нибудь погрязнее).