Исходное сообщение
"В OpenZFS выявлена ошибка, которая может привести к поврежде..." Отправлено Аноним, 26-Ноя-23 05:19
> Обычно алгоритм ECC ловит немножко больше, чем способен исправить. 1) Сила FEC в роли абстрактной "чексуммы" совершенно не обязана быть чем-то этаким. Это вообще ниоткуда не следует. Например, насколько я помню, ReedSolomon(223,255) может исправить до 16 байтов на (223 данных + 32 парити), или до 32, если известно где ошибки. Но вот как "generic" чексумма бомбардируемая рандомом он может пропустить абсолютный левак как сошедшееся решение с вероятностью сравнимой с 40-битным CRC, чтоли, насколько я помню оценки (лучше перепроверить). В любом случае - вероятность пропуска левака там крайне далековата от 2^128 и тем более 2^256. Уход в конские плотности записи для HDD и всякие QLC для флеша - BER разумеется не улучшили. 2) FEC занимает место. И портит циферки в маркетинге, сжирая место под техническое добро которое юзер в заявляемой емкости не видит, а вот производителю за это место заплатить придется. Поэтому его корректирующие возможности разумеется делают по минимуму, необходимому для более-менее беспроблемной работы в гарантийный период, чтобы хранить минимум избыточности. Все остальное - от лукавого. А так чтобы вот прямо ломовой запас, "в космос летим" - только за космические цены. В остальных случаях - на минималках, поэтому уход в стресстестирование этой штуки запросто приведет к отгрузке левака.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> Обычно алгоритм ECC ловит немножко больше, чем способен исправить. > 1) Сила FEC в роли абстрактной "чексуммы" совершенно не обязана быть чем-то > этаким. Это вообще ниоткуда не следует. Например, насколько я помню, ReedSolomon(223,255) > может исправить до 16 байтов на (223 данных + 32 парити), > или до 32, если известно где ошибки. Но вот как "generic" > чексумма бомбардируемая рандомом он может пропустить абсолютный левак как сошедшееся решение > с вероятностью сравнимой с 40-битным CRC, чтоли, насколько я помню оценки > (лучше перепроверить). В любом случае - вероятность пропуска левака там крайне > далековата от 2^128 и тем более 2^256. > Уход в конские плотности записи для HDD и всякие QLC для флеша > - BER разумеется не улучшили. > 2) FEC занимает место. И портит циферки в маркетинге, сжирая место под > техническое добро которое юзер в заявляемой емкости не видит, а вот > производителю за это место заплатить придется. Поэтому его корректирующие возможности > разумеется делают по минимуму, необходимому для более-менее беспроблемной работы в гарантийный > период, чтобы хранить минимум избыточности. Все остальное - от лукавого. А > так чтобы вот прямо ломовой запас, "в космос летим" - только > за космические цены. В остальных случаях - на минималках, поэтому уход > в стресстестирование этой штуки запросто приведет к отгрузке левака.
	Введите код, изображенный на картинке: