> сэкономленные зарплаты можно установить картонных серверов (или из чего они там
> у пейсбука, картонные были у гугля) Для них зарплата нескольких файлушников - сущая фигня на фоне толпы админов, скриптомакак и прочего сброда. И если скриптомакак можно в случае чего новых нанять из очереди за забором, то вот с парнями занимающимися ФС и блочным уровнем это не работает. Достаточно посмотреть на пируэты RH с XFS-ом. Видимо там очереди за забором не нашлось и редхат выкручивается как умеет, пытаясь сделать какое-то подобие прямо из скриптомакак. Идея прикольная, конечно, но, ух, некоторым менеджерам видимо не сказали что идеальная взаимозаменимость сотрудников - это все же немного миф и желаемое состояние дел, а не действительное.
> А вот редгада не поймут-с, если он данные клиентов превратит в тыкву,
> им индуса стимулировать придется.
Ну так к особо крупным клиентам - может и первым самолетом кто-нибудь относительно вменяемый прилететь. Он таки сможет и в хексэдиторе посмотреть, по месту, и худо-бедно допинает до кондиции. Но на всех такого сервиса явно не хватит. Поэтому им будут наслаждаться только те в состоянии отвалить чемодан баксов. Остальные отфильтруются и пойдут в пень. А нагрузка на саппорт придет в норму как раз. Заодно и совсем отказаться от шляпного саппорта будет чревато. Для крупняка. А мелочь и их проблемы редхат мало интересуют, если кто не заметил. Это еще старина Ульрих прямым текстом глаголил :)
> все равно не нужен - на своей любимой домашней машине с
> котиками ты заметишь раньше, чем сработает оповещалка smart.
Да щас. Вон там юзери с глючным железом заметили что с нтфс что-то не то. К моменту когда они это заметили - половина файлов уже в состоянии трухи. Битые блоки в середине картинок, так что вот вам фото до пояса - а дальше decode error, сбойный блок. И кучка зипушников с CRC error. И сетапы которые не запускаются, падают или вопят про corrupt installer. Ну вот заметили. И обтекли. Потому что бывает поздняк метаться. При таком уровне дестроя пролюблено довольно много данных. С чексумами они бы это заметили гораааааздо раньше. Соьссно было бы достаточно запустить изредка тест на зипарях - он все скажет. Но это ж надо явно заморочиться. А тут и матюки в логах сами, про scrub слышали все кто минимально интересовался темой, и это все ж стандартная процедура, а не ее эрзац из самоличного теста зипов по всему диску.
> Правда, со времен "щелкающих" дятлов я подобных дисков не видал - сейчас,
> обычно, чпок - и все твои данные превращаются в тыкву без
> объявления войны и долгих предисловий,
Зато я видел предостаточно такого. В многих случаях винч начинает плавно осыпаться. А бывают глюки железа, ну там SATA кабель поганый например. Да что там, даже если по винчу #$%нули или уронили, он чаще всего скопытится не сразу. Пыль от head slap по гермозоне разлетаться, конечно, начнет, данные будут рушиться, если долетит до служебки и накроет все копии - "ойпи...ц". Потому что после этого винч даже стартануть не сможет, с точки зрения юзеря будет полным трупиком. Но ДО этого момента можно успеть вынуть многое, если руки и голова на правильных местах. Профи могут потрепыхаться и опосля, забутявив хард с внешнего интерфейса, если тот не может модули с блинов читануть.
> а признаком беды является медленная запись или чтение, когда рано или поздно прочитывается.
Smart к этому моменту скорее всего будет содержать уже полдюжины индикаторов проблем. Даже у дубовых и глючных фирмварин. И если уж кого признаки интересовали - в smart они обычно виднее. Хотя замер времени чтения вполне себе известный метод оценки общего состояния пациента. Есть специализированные проги которые это делают более-менее правильно.
> да нет, с чего это.
А с того что очень зависит что именно там грохнется и как на это среагирует код ФС. Это нестандартная ситуация и в целом там может быть все что угодно. Кормить софт нестандартными ситуациями - на редкость дерьмовая идея, если интересовал результат. Кроме случая когда ты тестированием занят и запустил AFL и прочие Syzkaller'ы конечно, так что тебе за дестрой еще и зарплату платят. А вот на своих данных что-то такое сделать - офигенный способ их резко и больно пролюбить, в случае если упомянутые именно вот так почему-то еще не попробовали.
> Ключевые метаданные так или иначе дублируются в любой fs, начиная с ms fat (как,
> по-твоему, вообще работает fsck на тех fs где ее осилили написать?).
Угу. И работает это зачастую так: вот тебе 75% от второй таблицы FAT, и более - нифига, даже партишна нетути. Потому что FAT по eraseblock-ам неудачно попал. По законам мерфи, потерли eraseblock, а записать взад не успели, питание чих-пых как раз. И отлетел весь первый FAT с партишном, и кус второго. На фабричной ФС такого пытались избежать, но умная клава отформатила флеху. И теперь неаккуратное выдергивание без размонтирования - это вот так. Спасибо если так. Потому что может и транслятор у контроллера развалиться - и тогда ты получишь своих котяток причудливо нарезанной зеброй. И хрен сам что сделаешь. Да и про могут многое но - не волшебники, и если транслятор совсем уж пролюбился - собрать из котлеты корову можно лишь какой-нибудь угадайкой, для пары самых нужных файлов.
> Либо файл испортит, либо каталог, а файлы найдешь потом в lost+found.
Угу, при том если порушится какое-нибудь описание размещения файла, по законам мерфи, самого ценного и нужного, конечно же (его поди часто телепают, если это БД какая, так что там много метаданных, их часто трогают, так что отклонения от идеала как раз где-то там и случатся) - искать его придется по всей площади диска. Без полноценной инфо о размещении файла. Очень увлекательно. И хранить вообще всего по, допустим, два - ну как бы можно но усложняет и замедляет ФС и так делают не все, не всегда и не везде. И как там Мерфи сложится в вот конкретно этом бэде вот конкретно здесь - проверять на своих данных не рекомендуется, если они нужны. Ну да, может быть дестрой будет и небольшой. А может и большой. Это будет очень экспериментальный запрыг на грабли с крайне негарантированным результатом.
А если там реально всего по два так что ФС тупо вынула копию блока из другой локации - вот тут метаданные не пострадали, как там будет крючиться в глюках парсер - мы таки к счастью не узнаем. И это таки очень полезно для сохранности данных.
> Правда, современные (в смысле, после ext2) fs и дисковые драйверы еще и
> очень неадекватно работают (совсем я бы сказал не работают) с нечитаемыми секторами,
Да как сказать? Если например инфо о размещении файла утрачено - как адекватная работа с файлом вообще может выглядеть, интересно? Ну если метаданные дублированы - логично попытаться починить проблемную копию из второй. Винч при записи ремапнет проблемный сектор (или не ремапнет, если тот запишется и прочтется) и дело с концом.
Самое умное - выпасть в ридонли да констатировать факап, чтобы сильнее все не испортить. Собственно большинство ФС что-то такое и предпочитают - и это очень хорошая и умная реакция на проблему. Ну и ядро обычно делает несколько попыток читануть сектор. Если тот за несколько попыток не того - вот честно, лучше оставить его в покое. Потому что если долбить проблемную область попытками чтения - есть шансы что механика или кто там сбоил - окончательно склеит ласты и тогда данные вынуть напрягутся даже эксперты по восстановлению. Поэтому если за несколько попыток не проканало - это лучше вытаскивать уже вообще совсем другим софтом. Специализированным. Реализующим весьма специфичные паттерны доступа, нацеленные на постепенную реконструкцию образа. Пхать ЭТО в логику обычного ФС-а ни к чему - это для махровых датареков, когда все уже плохо, рядовой юзерь с этим уже не справится и даже не оценит проблему адекватно. А потом пролюбит вообще все, резко и больно, и вот тогда это даже про уже не вынут.
> который на современном винте получить - достаточно выключить питание в момент записи.
Ну да, странная хня иногда случается. Многие типа-сбойные (UNC) сектора после перезаписи - вполне исправные оказываются. Особенно актуально для глючных питальников. Но вообще это чревато именно резкой кончиной девайса. Там еще и сервометки, видите ли, и если при глюках винч их вынесет - он потом вообще не будет знать где у него что. И вот просишь ты сектор - а тебе в ответ бабах - IDNF. Нет такой буквы в этом слове. Хотя запрошенное и было в верном диапазоне.
А случае с флешовыми штуками все хуже - они крупноблочные и апдейт любых структур, что ФС, что внутренней трансляции подразумевает RMW больших блоков. При этом они неизбежно висят в RAM накопителя на момент патчинга и если питание пролюбится... в лучшем случе механика сделает cow-like фокус и откатится на вариант до начала этого маневра. А в хучшем будет очень чудесатый трупик, отдающий очень чудесатые данные. Или ничего не отдающий - фирмварь может и не взлететь без критичных таблиц.
