The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

В OpenZFS выявлена ошибка, которая может привести к повреждению файлов, opennews (??), 23-Ноя-23, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


73. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +1 +/
Сообщение от пох. (?), 23-Ноя-23, 14:16 
> Выкинуть бы всё это "творчество", но проблема только в том, что другого
> решения для raid5/raid6 с хешами для проверки целостности данных на дисках

тебе решение для локалхоста или данные хранить? Для второго "другое" - не-open solaris, или хотя бы вот FreeBSD до эры тяпляперов (т.е. 11.1 какая-нибудь)

> в общем-то и нет, а обнуление секторов или просто их порча
> даже при не особо большом объёме данных происходят регулярно...

э... понятно...


Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

111. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  –2 +/
Сообщение от fidoman (ok), 23-Ноя-23, 15:55 
>> в общем-то и нет, а обнуление секторов или просто их порча
>> даже при не особо большом объёме данных происходят регулярно...
> э... понятно...

В смысле, ты даже не читал статьи на тему того, зачем вообще контрольные суммы в ZFS ввели?
И не встречал дисков, которые побитые сектора вместо того, чтобы записать в pending, тупо их ремапят, заполняя нулями? И не понимаешь почему стандартный RAID5 такое изменение не может корректно отработать?

Ответить | Правка | Наверх | Cообщить модератору

188. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Tron is Whistling (?), 23-Ноя-23, 23:21 
> И не встречал дисков, которые побитые сектора вместо того, чтобы записать в
> pending, тупо их ремапят, заполняя нулями?

Это как правило диски под линейную циклическую видеозапись, зачем вы их такие берёте?
Плюс стандартный RAID5 такое щщастье замечательно отработает.

Ответить | Правка | Наверх | Cообщить модератору

265. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от нах. (?), 24-Ноя-23, 13:40 
>> И не встречал дисков, которые побитые сектора вместо того, чтобы записать в
>> pending, тупо их ремапят, заполняя нулями?
> Это как правило диски под линейную циклическую видеозапись, зачем вы их такие

причем прошлого десятилетия. Я не слышал о подобных проблемах у пресловутых wd purple. Ремап как ремап.

> Плюс стандартный RAID5 такое щщастье замечательно отработает.

нет. как он тебе его отработает если там нули вместо данных и неизвестно, где?
Специальных проверок что если считались нули то считать этот сектор битым пока не предусмотрено (да и где гарантия что нули и не были там на самом деле)

data checksums тут помогут, только вот не лучше ли не использовать настолько неадекватное оборудование?

Я за свои тридцать лет работы в околоит ни разу не видел никакого битрота. И даже настолько неисправные диски что превращают данные в кашу  (это не битрот, битрот сказочка о другом белом бычке - якобы-единичном перевороте битика где-то в середине стотридцатого терабайта очень нужных данных [которых у сказочника никогда не было]) мне не попадались. Вероятнее всего в виду не покупания их на помойках.


Ответить | Правка | Наверх | Cообщить модератору

223. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +1 +/
Сообщение от Аноним (-), 24-Ноя-23, 02:32 
> И не встречал дисков, которые побитые сектора вместо того, чтобы записать в
> pending, тупо их ремапят, заполняя нулями?

Это вообще - unspecified. Фирмвара что хочет - то и делает. Нет никаких требований что должно случиться если энный сектор прочитать не удалось. Ну а поскольку корректных данных нет - упс, сохранить данные неизменными, как записано как раз и не получится. Хоть как.

> И не понимаешь почему стандартный RAID5 такое изменение не может корректно отработать?

Он вообще не в курсе parity это кривой или данные. RAID1 тоже при этом без понятия - какая из копий правильная. При обычном подходе вы видите что 2 копии не совпадают - но это ничего не говорит о том какая из 2 правильная. С чексумами, однако, этот пазл и решаем, и чинится в фоне, позволяя заодно и ремап сделать без проблем.

Ответить | Правка | К родителю #111 | Наверх | Cообщить модератору

236. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  –1 +/
Сообщение от Tron is Whistling (?), 24-Ноя-23, 09:51 
>> И не понимаешь почему стандартный RAID5 такое изменение не может корректно отработать?

RAID 5/6 и не надо быть в курсе - и вменяемые контроллеры делают проверку при регулярных прогонах Patrol Read / Consistency Check. Нет, не при каждом хостовом чтении естественно, но при каждом чтении оно и не нужно - оно нужно чтобы как раз найти сектора, которые вот такие вот гнилые диски забили фигнёй.

Ответить | Правка | Наверх | Cообщить модератору

237. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +1 +/
Сообщение от Tron is Whistling (?), 24-Ноя-23, 09:52 
В любом случае подобные диски и данные, которые жалко - это неюзабельный кейс, который не вижу смысла далее рассматривать.
Ответить | Правка | Наверх | Cообщить модератору

359. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Аноним (319), 27-Ноя-23, 02:35 
> RAID 5/6 и не надо быть в курсе

У меня другие идеи на этот счет. С чексуммами соотношения явно лучше, при том достаточно малой ценой. И даже RAID5 в небольших инсталляциях может иметь какой-то смысл, а RAID1 и подавно.

> - и вменяемые контроллеры делают проверку при регулярных прогонах Patrol Read
> / Consistency Check.

Ну да, ну да, специальное железо за дохреналион, с мутной фирмварой делающей хз что, в которой отсутствие багов гарантирует - ахз, наверное Пушкин. А знаете что господа, вы такими требованиями и свойствами - в усмерть уже задолбали много кого. За что и повылетите почти отовсюду, имхо. Вместе с железками за дохраналион. Ибо "кайф то в том и заключается чтобы вовремя их с рельсы убрать!" - сделать дешево и круто. И это - на ваше горе возможно.

И даже не только на уровне 1 тазика. Более глобально, из ненадежных тазиков можно собирать надежные гипер-структуры. Чем вон те энтерпрайзники и занимаются. Ну а вы на этом фоне - пушистые мамонты, над которыми летают звездолеты более разумных существ. А климат уже не в вашу пользу.

> Нет, не при каждом хостовом чтении естественно, но при каждом чтении оно
> и не нужно - оно нужно чтобы как раз найти сектора, которые вот такие вот гнилые
> диски забили фигнёй.

Гнилость диска понятие весьма широкое. Может и 1 бэд в 5 лет вылезти. Вон то его прозрачно парирует, и поедет дальше. И если следующий будет через 5 лет - возможно не такой уж диск и гнилой.

Ответить | Правка | К родителю #236 | Наверх | Cообщить модератору

366. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Tron is Whistling (?), 27-Ноя-23, 10:04 
Я тут уже пару раз писал, и в третий тебе напишу: за 15 лет ни одного обращения к бэкапам.
Но вы продолжайте получать удовольствие.

Из ненадёжных тазиков никакие надёжные структуры вы не соберёте. Нет - соберёте. До первого залетевшего дятла. Не вы первые, не вы последние. Даже гугл тазики такого типа ставит только на GGC, который потерять не жалко.

Ответить | Правка | Наверх | Cообщить модератору

374. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Аноним (319), 27-Ноя-23, 21:25 
> Я тут уже пару раз писал, и в третий тебе напишу: за
> 15 лет ни одного обращения к бэкапам.

Вы ни разу не ответили мне на 1 простой вопрос - как вы вообще проверяли целостность данных. Как это происходит с фоновыми сканами типа scrub - я понимаю. Как это у вас - не совсем. Откуда у меня подозрения насчет "технологии страуса" и следствий из законов Мерфи.

> Но вы продолжайте получать удовольствие.
> Из ненадёжных тазиков никакие надёжные структуры вы не соберёте. Нет - соберёте.

Гугл собрал. Там отказ 1 сервера - вообще ни на что не влияет. При этом все равно почему он скопытился. Более глобальная структура делает резервирование рассматривая каждый тазик как юнит.

Да вы и сами - собраны из ненадежных клеток. Каждый день у вас умирает куча клеток. А вы тут пописываете на опеннетик и в ус не дуете о проблемах отдельных "юнитов".

> До первого залетевшего дятла. Не вы первые, не вы последние.
> Даже гугл тазики такого типа ставит только на GGC, который потерять не жалко.

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

Ответить | Правка | Наверх | Cообщить модератору

375. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Tron is Whistling (?), 27-Ноя-23, 23:08 
> Гугл собрал.

Ничего гугл не собрал. Вы их самодельные тазики, которые сервис, а не no-problem-to-drop кешик видели? Ваши супермикры или что там у вас сейчас китайское модно - рядом не валялись. Там даже платы, ***а, кастомные...

Ответить | Правка | Наверх | Cообщить модератору

377. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Аноним (-), 28-Ноя-23, 04:12 
>> Гугл собрал.
> Ничего гугл не собрал. Вы их самодельные тазики, которые сервис, а не
> no-problem-to-drop кешик видели? Ваши супермикры или что там у вас сейчас
> китайское модно - рядом не валялись. Там даже платы, ***а, кастомные...

Вы не понимаете (хотя это нормально, когда уровень обсуждаемого превышает способности обсуждающего).

Основная круть гугла (что конкуренты никак не могут содрать, вебманкам слабо, как впрочем и вам) - overlay алгоритмы, позволяющий хранить данные "распределенно" в "мегаструктурах". Вылет плюс-минус пары серваков пофиг, из-за наличия избыточности на ЭТОМ уровне, "в сети". Сетевая мегаструктура просто самовосстановится. Может что-то где-то пару реплик на другие узлы раскидает.

Для юзеров это будет как максимум кратковременная просадка перфоманса. А в остальном оно самопочинится, все продолжит работать, техники где-то в фоне заменят плюс-минус пару серверов. И если алгоритм сформулирован вот так - в эту формулу вообще не входит какая там плата, и по какой причине сдох сервак.

Вы не соберете такое ни из супермикр, ни из чего там - потому что это "глобальный сетевой алгоритм" прежде всего. И гугл разумеется в жизни вам ЭТО не даст в полном и работающем виде. Что они, глупые себе конкурентов взращивать.

Пох, или кто там, периодически пиндит про какие-то патчи для EXT, которые гугол зажал. Гугол вообще гонял ФС без журнала, и их integrity в вон том кейсе - ниипет вообще, чек блоков и ререпликация рюхается сетевым уровнем, а сервер опознается как испорченый и по отгрузке трухи по любой причине и по уходу в даун, это не важно - запрос будет просто повторен на другие узлы и завершится успехом. Но вам такой EXT вообще нафиг не упал, ибо плевал он на целостность данных. Особенно с вашим пониманием как делать те или иные вещи. Это просто не ваш уровень технологий. В отличие от вас я немного понимаю как делать такие штуки. По каким-то своим причинам, столь же за гранью вашего понимания как и сами такие технологии. Даже если вам дать те EXT патчи - куда вы это? У вас же нет такого сетевого оверлей-алгоритма. И врядли будет. Не дают инопланетяне продвинутые космические корабли всяким питекантропам. А с вашим EXT4 и энтегпгайз хагдвагом соотношения примерно вот такие.

А меня продвинутые ФС с чексуммами интересуют потому что вон то поднять локально, таки, очень накладное мероприятие и "вниз" такое сложно масштабировать и соотношения портятся. Одно дело пережить отказ 3 серваков из 1000, другое 3 из 5, допустим. Если мы про FEC - это требует более другой уровень оверхеда для парирования. Да, FEC можно делать в разных масштабах. Очень разных. А "страйпом" может быть и "узел сети". При этом пофиг на его внутренние проблемы и китайский он там и проч - единственное что меняется, гимор с заменой и возможность глобально управлять этим в желаемом формате (последнее и является настоящим поводом разработать свое).

Ответить | Правка | Наверх | Cообщить модератору

383. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Tron is Whistling (?), 28-Ноя-23, 09:27 
Вы просто не понимаете, что это целый комплекс мер.

Распределённые структуры очень медленно ворочаются как на запись, так и менее - на чтение, а при отказах имеют свойство ворочаться ещё медленнее, потому что начинается тот самый процесс восстановления. А при отказе большего, чем ожидалось, числа нод - могут лечь совсем до ручного вмешательства. У гугла сервисных нод очень много, но пренебрегать их надёжностью они при этом не рискуют. А вот на кеш (который пишется исключительно с сервисных нод и далее работает в режиме read-mostly) - ставят хлам, да.

И если вы считаете, что из хлама можно собрать космический корабль - ну вот да, Луна-25 - примерно ваш уровень.

Ответить | Правка | Наверх | Cообщить модератору

388. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  –1 +/
Сообщение от Аноним (-), 28-Ноя-23, 15:50 
> Вы просто не понимаете, что это целый комплекс мер.

На мой вкус - сперва извольте ответить на вон тот простой вопрос, как вы вообще на ващих EXT'ах узнавали что данные не побились - а потом будете щеки надувать. Поставить фирмачей на дохреналион, надув щеки, ума много не надо. А вот сделать "недорого и круто" - это и есть state of art.

> Распределённые структуры очень медленно ворочаются как на запись,

Вообще ниоткуда не следует. В энных допущениях может быть ограничено только каналом writer'а по сути.

> так и менее - на чтение,

Тоже ниоткуда не следует. Там можно параллелить запросы и проч - и в предельном случае это может забить любой канал. Характерным примером является допустим торент. Да, это специфично, но общие идеи чем это может быть при правильном подходе - иллюстрирует. Попробуйте перефлудить сидеров исошки убунты вообще. Они круче любого CDN. Вот гугл какие-то такие моменты - понял.

> а при отказах имеют свойство ворочаться ещё медленнее, потому
> что начинается тот самый процесс восстановления.

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

> А при отказе большего, чем ожидалось, числа нод - могут лечь совсем
> до ручного вмешательства. У гугла сервисных нод очень много, но пренебрегать
> их надёжностью они при этом не рискуют.

У гугла серверов не много а очень много. И failure rate примерно одинаковый, чего ему резко меняться. И избыточность разумеется его покрывает с запасом. А чтоб мануально - или видимо юзерам? Ну вот не припоминаю каких-то ощутимых сбоев основных сервисов гугли в последнее время.

> А вот на кеш (который пишется исключительно с сервисных нод и далее работает
> в режиме read-mostly) - ставят хлам, да.

Там может и не быть такого деления. От задач зависит. Из хлама можно и всю структуру сделать, единственная трабла - несколько чаще заменять серваки. Ну вон торентовщики - могут любой мусор использовать. Для вас все просто: хеш блока или совпал и тогда все ок, или нет, и тот кто его налил идет в баню (или "маркируется как проблемный сервер" в тех терминах). Какой мусор вам налил блок в этой парадигме вообще не интересно. И "writer"-у в виде initial seeder тоже похрен какой мусор что использует. Круто, да? А таки верификация больших даунлоадов - сильно круче любых HTTP и проч. Те кто поумнее поняли что сравнимые технологии и для иного IO можно практиковать.

> И если вы считаете, что из хлама можно собрать космический корабль -
> ну вот да, Луна-25 - примерно ваш уровень.

Мой уровень на вон тот манер выглядел бы иначе - стайка дронов. Даже если половина развалится и сломается, остальная половина успешно завершит миссию, достроив базу или что там. А не так что 1 супер-дорогой агрегат, а если он сломался то плана вообще нет.

И это... ширпотребный квалкомм с линухом довольно долго рассекал на марсе в виде вертолетика. Я даже со счета сбился, помер он совсем или до сих пор живой. И так то - вот - первый летательный аппарат на другой планете, даром что из ширпотреба.

Ответить | Правка | Наверх | Cообщить модератору

393. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Tron is Whistling (?), 28-Ноя-23, 21:24 
Недорого и круто - это вообще не про гугл.
Следует. Накладные расходы на распараллеливание не учитывать невозможно.
Нет, если вы туда что-то просто пишете, читать не собираясь - параллелится до бесконечности.
Но вот если надо ещё индекс к этому строить - он неизбежно встанет в блокировки.
Всё остальное - беллетристика.
Ответить | Правка | Наверх | Cообщить модератору

398. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Аноним (390), 28-Ноя-23, 22:34 
> Недорого и круто - это вообще не про гугл.

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

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

> Следует. Накладные расходы на распараллеливание не учитывать невозможно.

При правильном подходе к делу - все в пределах разумного.

> Нет, если вы туда что-то просто пишете, читать не собираясь - параллелится
> до бесконечности. Но вот если надо ещё индекс к этому строить - он неизбежно
> встанет в блокировки. Всё остальное - беллетристика.

Это просто очень олдовое и классическое мышление. Уже появились и другие. Вы вот так - даже кравлер веба более-менее реалтаймный не напишете. А иногда индексом вообще может быть - внезапно - сам контент, или запрос. Man "content addressable network" если мозг вдруг не порвется. Те кто поумнее - и сделали себе системы на совсем других принципах. А всякие похи жалуются что им патчик для генератора энергии не дали. Куда они этот генератор без остального крейсера и варпдрайва интерфейсить собирались - кто его знает. Воинственно трясти копьем это ж не мешает.

Ответить | Правка | К родителю #393 | Наверх | Cообщить модератору

403. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Tron is Whistling (?), 29-Ноя-23, 09:38 
Да, пока оно в пустоту пишется, инопланетяне сидят и строят индексы.
Ничего не изменилось по сути. И принципы всё те же.

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

Ответить | Правка | К родителю #398 | Наверх | Cообщить модератору

409. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Tron is Whistling (?), 01-Дек-23, 21:37 
> хеш блока или совпал и тогда все ок, или нет, и тот кто его налил идет в баню

В распределёнках самое интересное начинается именно тогда, когда НЕ совпал.
Вот там приключения Чиполлино в стране крокодилов развёртываются в полный рост.
А если внезапно связность между нодами ушаталась - то начинаются приключения снежка в аду.

Ответить | Правка | Наверх | Cообщить модератору

287. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от пох. (?), 24-Ноя-23, 19:38 
> Это вообще - unspecified. Фирмвара что хочет - то и делает. Нет никаких требований что должно
> случиться если энный сектор прочитать не удалось.

казалось бы - очевидно, что - вернуть ошибку чтения, а не произвольные данные с потолка.

Если вы напоролись на диски которые вместо этого возвращают какие-то там нули - назовите конкретную модель.

И да, никакой raid5 от этого не поможет. Там дальше очередные фантазии каких-то местных экспертов.

Ответить | Правка | К родителю #223 | Наверх | Cообщить модератору

295. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Tron is Whistling (?), 24-Ноя-23, 22:03 
Не, такая серия у сигейта действительно была. Video-only. Этот треш действительно забивал сектора при ремапе (видеопотоку-то фиолетово), в рейды его категорически ставить было нельзя.
Ответить | Правка | Наверх | Cообщить модератору

310. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  –1 +/
Сообщение от Аноним (309), 25-Ноя-23, 12:45 
> Не, такая серия у сигейта действительно была. Video-only.

Названия модели или серии так и нет, зато есть обобщение на все диски под видео.
> Диски под видео - отдельный экземпляр, их здесь где-то ниже упомянули - вот эти да, страшное дело - могут просто смахнуть сектор и сделать вид, что прочиталась фигня. Эти диски лучше никуда больше не ставить.

ATA Streaming feature set появился не позже 2004, со специальными командами для "priority on the time to transfer the data rather than the integrity of the data". Заявление о дисках, которые переносят поведение специальных команд на обычные, звучит совсем неубедительно. Эти команды были придуманы, чтобы не менять поведение обычных, нужна конкретная багованная модель без обобщений.

Ответить | Правка | Наверх | Cообщить модератору

346. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от пох. (?), 26-Ноя-23, 17:07 
>> Не, такая серия у сигейта действительно была. Video-only.
> Названия модели или серии так и нет, зато есть обобщение на все

да какая разница? все равно ты в розницу это чудо не купишь. Что-то специфичное с whitelabel (или как у сигейтов выглядит аналог) ставившееся только в dvrы подключенные к камерам наблюдения. Чтоб видимо использовать там шва6одное по а не самим писать драйвер с чудо-фиче-сетом.

Ну будешь такой на помойке расковыривать - прояви осторожность. А в остальных случаях знание малополезное.

Ответить | Правка | Наверх | Cообщить модератору

351. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Tron is Whistling (?), 26-Ноя-23, 22:49 
А вот это - да, верно.
Ответить | Правка | Наверх | Cообщить модератору

361. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Аноним (319), 27-Ноя-23, 03:07 
>> Это вообще - unspecified. Фирмвара что хочет - то и делает.
>> Нет никаких требований что должно случиться если энный сектор
>> прочитать не удалось.
> казалось бы - очевидно, что - вернуть ошибку чтения, а не произвольные
> данные с потолка.

А кто его знает что в голове у тех разработчиков фирмварей. Они решили делать вот так. Это поведение найдено в диком виде для целой кучи девайсов всех мастей и направлений. Чаще всего так flash based прикалывается, для HDD это скорее исключение.

Видимо идея в том что сектор не так уж сильно испорчен и несколько битых битов не такой уж и ужас, даже если FEC и лоханулся, так что может лох и не заметит. Как видим, с господами любящими EXT4 это до некоторой степени катит, чексум же нету! Они и будут уверены что все ЗБС. Если б при частых ошибках такого вида не разлеталось внезапным роялем на бошку, может никто и не заметил бы. Но вон те - вылезающие из дырки по форме тушки и удивленно спрашивающие что случилось и где их данные таки стали вызывать определенные вопросы, эффект и был опознан и классифицирован.

> Если вы напоролись на диски которые вместо этого возвращают какие-то там нули
> - назовите конкретную модель.

Это больше характерно для флешастых девайсов, особенно заезженных, а быстро заездить энтерпрайзный SSD можно воткнув его в bcache например. Популярный способ. Девайсы - разные бывают. Самсуни всякие например. У них вообще фирмвар - стремный по жизни. А еще раньше они от trim себе харакири пытались делать. Достаточно успешно, чтобы загреметь в блеклисты линукс кернела, которые, так то - забавный клад на тему quirk'ов самой разной хрени.

> И да, никакой raid5 от этого не поможет. Там дальше очередные фантазии
> каких-то местных экспертов.

В чистом виде? Умрет в корчах. С чексумами - таки определенные шансы имеет. Ибо за счет чексум известно где левак.

Ответить | Правка | К родителю #287 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру