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

Для мордокниги надо все и сразу. Надежность снижает затраты на обслуживание. А производительность еще никому не мешала.

> А надежность - вон, у оракла много лишних денег, правда, он их никому не дает, потому и много...

Оракл не есть активные разработчики линукса. Судя по всему для линуксных разработчиков это за проклятое место считается. Репутация у фирмы в опенсорсной среде - не ахти.

> ну прилетит, а дальше-то что? Если разведет руками и скажет "ой, оно
> тут уже не чинится" - так я тоже умею.

Ну может он и соберет что-то и закатит солнце вручную. А может и не соберет. Откуда я знаю что редхат планирует делать? Это их бредовые идеи, кто на них купится тот и будет в саппорте редхата узнавать как они себе это представляют.

> и вероятностью внезапного отказа на большой выборке, увы.

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

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

Кроме того чтобы объективно узреть состояние поверхности, надо тест гонять. Это производительность просадит. Поэтому так делают не все и не всегда. А фирмвара соответственно сама по себе статистику может и не набрать адекватно. Потом при чтении со всей поверхности опа - а там ошибок оказывается уже. И тут read error rate фигась резко вверх! Особенно если повторять попытки чтения сбойных секторов.

> Может с тех пор смарт и стал получше, но вряд ли что глобально изменилось.

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

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

Неправда ваша, кернель как раз таки сделает 2-3 попытки прочесть, не прокатило - оставляет в покое, возвращает наверх read error и даже кеширует походу, так что повторные попытки мигом вызывают отлуп с read error совсем без насилия над девайсом вроде.

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

> Поэтому вместо одного ненужного файла в tmp - получаем убитый диск.

Если диск собирался скопытиться - то уж собирался. Ну подложил бы он тебе свинью чуть позже, тебе сильно полегчало бы? Ты бы ошибочно думал еще пару месяцев что все ок. Сомнительная радость.

> А бегать при любом мелком сбое за специализированным софтом и хардом мало кто может
> себе позволить.

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

И таки при проблемах чтения стандартная логика ФС и кернела не расчитана на продвинутый рекавери с полудохлого носителя с минимизацией урона. Это специальная отдельная область, под это специально пишут программы для DR-ов. А в обычной логике ОС это явный перебор.

> (да и толку, если это экзотическая система, а не fat)

Ну я народу чаще всего EXTы выколупывал... хотя немного и FAT, конечно. И даже слегка нтфс-ы.

> В каком-нибудь 2004м в подобных случаях я переключал диск в pio (чтобы
> нормально работали таймауты, а не dma reset по всей роже),

Read dma multiple - хуже чем чтение единичных секторов. Но не сильно роялит. С правильным софтом один черт при начальном чтении скипается большой кус после налета на проблему, чтобы быстро выйти из порушеной области. А в следующих заходах можно и более активно долбить проблемные области, чем позднее итерация, тем агрессивнее. В удачном случае так даже может получиться lossless. Потому что с цатой попытки нестабильный сектор может взять и прочитаться. А может и винч вместо этого скопытиться. Фирвари нервно относятся к RAW ERROR RATE. Если все время просить проблемные сектора, можно случайно устроить накрутку, в какой-то момент фирмварь решит что устройство запредельно поломано. Уйдет в safe mode - и тогда ты точно пойдешь к профессионалам, если данные нужны. Потому что сектора то оно отдает, но даже на identify может не отвечать. И вот это для хомячка уже обломно - оно ни биосом, ни осью не детектится, а если и детектится то не подцепляется. Те как-то не готовы что 90% команд будет отлуплено/проигнорено, только read sector. Не multiple.

> искал в логе сбойный блок, оно там обычно было, и добавлял его в badlist - те fs так умели.

Современные винчи, да и SSD умеют remap. Фимрварь сама проблемные сектора переназначит, большинство фирмварей это даже достаточно сносно умеют. Если есть куда. А если уже некуда - прекратите насиловать труп. Или вы ждете пока служебка перестанет читаться? Вот тогда и останетесь без данных, резко и внезапно. Не выйдет на режим после очередного включения - и вы пролетаете.

> Хрен с ним, с тем файлом, он уже мертвенький - зато остальной сервер я не
> буду переустанавливать, а просто склонирую.

При попытке это сделать обычным софтом в обычном виде есть шанс что пациент в этом процессе откинет ласты окончательно. Иногда конечно может прокатить. Но вот это уже поиск проблем на свой окорок. Если оно реально надо - образ лучше софтом типа ddrescue/myrescue/whdd/... снимать за несколько итераций. И даже так - что он прочтется lossless не факт, поэтому безбашенно его влупить как есть куда-то еще чревато глюками или ВНЕЗАПНЫМ отвалом файлухи. Оно надо? Сэр очень талантлив в раскладывании грабель, теперь я понимаю почему у него линуксы так глючат.

> Попробуйте повторить этот фокус с lvm, xfs или чем там модно? Даже если в файл попало, а
> не в чортов журнал.

Журнал иной раз можно и аннигилировать к чертям, если проблема в нем, зачастую с маргинальными потерями. Но в этом случае речь не идет о flawless восстановлении и 100% сохранности данных. Это ок для аварийного восстановления, когда выбор нифига совсем, или хотя-бы это, вот так. А если ФС так будет в крейсерском режиме - юзер будет постепенно пролюбливать данные. Чем неполный журналинг и плох.

> ничего странного - ibm запатентовала sector marks, [пере]записываемые вместе с данными,
> еще в 97м году. Нет метки - нет сектора, вообще нет его такого.

Там все хитрее. У голосовой катушки нет треков. Она аналоговая, линейная, ей все-равно куда. Сервопривод по сервометкам понимает в какую сторону напряжение крутить, чтобы нужный трек найти. И даже вроде держит головы на дорожке, даже если та не идеально расположена, активно трекая размещение. И начала секторов помечены.

Если это все слетит, запросто и целой группы секторов не будет. Вот вам IDNF - и гудбай. Нет такого сектора на этом накопителе. При том возможности фирмвари по ремапу таких областей весьма лимитированы и когда они закончатся, фирмварь сдастся. Обычно это никто не перезаписывает, потому что себе дороже. Более того - наносят это на фабрике, прецизионным серворайтером, который таки может отмерять мелкие дорожки и нанести разметку, в отличие от винча. Сам винч это не может, поэтому фирмвара боится перспективы снести это как огня. По этой причине настоящий low level format технически невозможен без, хы-хы, серворайтера.

А вот глючное питание например может на раз помочь перезаписать сервометки. Фирварь прикладывает серьезные усилия чтобы это "should never happen", там много фокусов на тему. Вплоть до того что оставлен отступ от области данных, хоть это и пролюбливает место. Но если помочь - глючащая механика и электроника таки может сделать что-то не то.