Подскажите про надежность HDD
 

День добрый! Кто-то разбирается в жестких, подскажите, пожалуйста!

Может ли на HDD или SSD повредиться файл, так что я об этом не узнаю? Например, появится бэд или еще какой косяк в том месте, где файл записан. Я скопирую файл, а он окажется испорченным. Если так, то архивирование информации на другой носитель не дает гарантий.

Прошу прощения за такой простой вопрос, просто сейчас для работы придется делать архивные копии очень большого количества файлов (на USB HDD), и не хотелось бы, чтобы они повредились, а я случайно узнал об этом, только когда придется восстанавливать эти файлы с внешнего HDD, открывать их, и они окажутся испорченными, а другой архивной копии не будет. Ну или файл повредится на основном HDD, и я скопирую на архивный уже испорченную версию.

я бакаплю ежедневно на железки (автоматом) плюс раз в неделю (вручную выборочно) на яндекс облако там сто рублей террабайт или около того

Было однажды что жопеги на диске попортились. Несколько файлов всего. Узнал потом случайно. Ошибок чтения не было, так по бэкапам они битые и расползлись. Диск тот работал с перегревом. В нормальных условиях такое в теории тоже вероятно, но не встречал. Поэтому для ценной информации нужно как минимум 2 бэкапа + архивы.

[quote=Еще год на этом форуме;47050755] я бакаплю ежедневно на железки (автоматом) плюс раз в неделю (вручную выборочно) на яндекс облако там сто рублей террабайт или около того [/quote]
зачем это делать ежедневно?

3-no_name > Это разве не очевидно? У вас наверное ещё ssd не подыхали?
При критической поломке диска можно будет восстановить весь комп за полчаса. Ежедневно (ну или еженочно) бекапятся только изменения. wbadmin ковыряйте - там всё просто.
Ежу понятно, ежели у вас фотоархив (или чтонибудь такое) то проще залить всё на облако или на носитель и никогда не доставать

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

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

Интересно... Если есть еще какие советы по созданию архивов на внешних HDD в домашних условиях, напишите.

7-Volodik > Не впадай юноша в ПАРАНОЮ
Просто делай бекапы как ты считаешь нужным в зависимости от важности даты

Смотря что у тебя за данные. По классике, архивируется первичка (исходники) на read-only носители (диски, ленты). Потом они обрабатываются, делаются копии оперативного бекапа по необходимости (например в конце дня) поочередно на 2 разных носителя. Потом когда обработка завершена, делается бэкап результата одновременно с архивом. Так, по крайней мере, у тебя будет первичка. Если же речь идёт только об оперативных данных без первички (прямой ввод с клавиатуры, например), то делать множество бекапов с определенным интервалом. Количество и интервалы определяются ценностью информации. Если не ценная, то надежности накопителей хватает, чтобы вообще не делать бекапы.

[quote=Rat;47055656] 5-Еще год на этом форуме > не всегда ошибки контрольной суммы обнаруживаются, [/quote]
думаю такое исчезающе мало

[quote=Еще год на этом форуме;47063586]думаю такое исчезающе мало[/quote] :)))) Наводящий вопрос на засыпку - а средствами ОС контрольные суммы файлов контролируются?

Самой частой причиной ситуации с ошибками резервных копий являются сбои памяти! Файл скачивается в память при резервном копировании, и только оттуда переносится на резервный носитель! Разумеется, ни каких "контрольных сумм" при считывании из кэша не проверяется...

не делаю бэкапы вообще.

12-As > а как же ECC? Если речь зашла о бекапах, разумеется, мы наверное говорим о сколь-либо приличном оборудовании, а не о ноутбуке из ближайшего магазина «все для быта».

[quote=Wlad;47064811]:)))) Наводящий вопрос на засыпку - а средствами ОС контрольные суммы файлов контролируются? [/quote]
Не понял вопроса( Что за контрольные суммы которые контроллируются?
Если речь о сообщении Rat, очевидно, что он не понимает что такое хэш-функция. Так же очевидно, присутствующие не совсем понимают как устроена весьма отказоустойчивая ntfs.

[quote=Еще год на этом форуме;47068435]Не понял вопроса( Что за контрольные суммы которые контроллируются?[/quote] Ну не я заявил за "контрольные суммы файлов". Так вот - их нет в ОС "по умолчанию". Можно поставить софтинку которая будет считать хэш у выбранных файлов и в дальнейшем сравнивать хэши сиюминутно посчитанные для конкретного файла с сохраненными в базе этой софтинки, но это все медленно, печально и поэтому в общеупотребительных ОС не используется в принципе.
И любой юзер просто НАДЕЕТСЯ на то что забэкапленый им файл был правильно перенесен с одного носителя на другой.
[quote=Еще год на этом форуме;47068435]Так же очевидно, присутствующие не совсем понимают как устроена весьма отказоустойчивая ntfs.[/quote] А при чем здесь отказоустойчивость файловой системы как таковая, причем вообще вне зависимости от того что это за ФС? Вопрос в СОДЕРЖИМОМ ФАЙЛА, а не в тех координатах по которым он находится с точки зрения ФС.
Ведь как исходно поставлен вопрос? [quote=Volodik;47044065]Например, появится бэд или еще какой косяк в том месте, где файл записан. Я скопирую файл, а он окажется испорченным.[/quote] Все правильно, волшебная процедура autoreassign которая выполняется в фоне и незаметно для юзера обнаружила что такой-то физический сектор не читается. А поскольку это внутренняя процедура исполняемая системой самодиагностики накопителя то ей по глубокому барабану, содержит ли информацию этот сектор и связан ли с каким файлом для файловой системы - этот сектор тупо замещается на сектор из резерва. Естественно, без всякого переноса в этот замещающий сектор тех данных которые были в замещенном секторе. И вот у нас появился БИТЫЙ ФАЙЛ. С точки зрения ОС компа он АБСОЛЮТНО ЦЕЛЫЙ, причем покашлять с высокой колокольни какая файловая система у нас там с этой ОС арбайтает - отказоустойчивая NTFS али некошерный FAT. Все сектора которые числятся за этим файлом в файловых таблицах успешно считаны - но при этом один сектор (ну или несколько) не содержат тех данных которые были в этом файле исходно.
Возьмем на пример вот это фото
[img]https://a.radikal.ru/a20/1908/e8/1993d5c47099.jpg[/img]
А сотворили с ним такое всего-навсего 4 поврежденных 4-х килобайтных сектора - 16 384 байта из 2 858 794 байт содержимого файла, чуть больше чем 0,5% от его объема. И при этом файл по прежнему великолепно читается средствами "отказоустойчивой NTFS" и великолепно переносится куда угодно, в том числе и в интернет-облака, белогривые лошадки. Но можно ли считать такой файл ЦЕЛЫМ?

[quote=Wlad;47069638]Ну не я заявил за "контрольные суммы файлов". Так вот - их нет в ОС "по умолчанию"[/quote]
А при чём тут ОС? Я вроде написал:
[quote=Еще год на этом форуме;47055162] комп при считывании проверяет целостность данных, и если файл считался то на источнике он точно не повреждён. [/quote]
Что не так-то? Контроллер любого жёсткого диска (Комп) при записи файла высчитывает "код контроля ошибок" (ECC), или как тут поминали "контрольную сумму" и записывает его вместе с файлом, при считывании файла происходит тот же расчёт и коды сравниваются. Это вроде как основы. Всё происходит на уровне контроллера, и полностью для ос и софта прозрачно, хотя доступ из ос и софта к этим рассчётам контроллера есть и можно косвенно сказать что "Да, контролируются".

Про отказоустойчивость ntfs я просто указал что кто-то писал про ошибки в момент выключения напруги.

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

хм, я не совсем внимательно прочитал пост 16, там пугаете молодёжь BADом?
Ситуация когда контроллер сталкивается с несоответствием контрольных кодов чтения и записи это отдельная и большая тема.
Но то что производители и разработчики втихаря от пользователя ремапят сектора и повреждённые файлы выдают как целые мне кажется сильно натянутой историей

[quote=Еще год на этом форуме;47070040] Контроллер любого жёсткого диска (Комп) при записи файла высчитывает "код контроля ошибок" (ECC),[/quote] Не надо путать теплое с мягким. Для накопителя нет ФАЙЛА, есть СЕКТОРА, которые надо записать или считать. И ЕСС проверяется при чтении сектора, и именно по совпадению или не-совпадению ЕСС сектора сектор выводится из обращения - сперва в Relo, а потом в пользовательский лист дефектов. И при этом накопителю по барабану, к какому файлу относился сектор, и на ЕСС всего файла ему тоже пофик.
Так что наивная уверенность в том что "если файл читается то он в порядке" исходит именно из того что кое-кто не понимает принципиальной разницы между ЕСС файла и ЕСС сектора у накопителя. Я показал конкретный пример файла, в котором накопитель вывел из обращения и заменил на резервные 4 сектора - два поряд с 74000(Н) по 75FFF(H) и два подряд с 29F000(H) по 2AFFFF(H). Поскольку у конкретного накопителя сектора имели размер 4 килобайта то суммарно заремаплено 16 384 байта - что изменило КОНТРОЛЬНУЮ СУММУ САМОГО ФАЙЛА. Но не повлияло на возможность прочитать этот файл с накопителя, поскольку с точки зрения ОС все сектора имевшие отношение к файлу успешно считаны.
[quote=Еще год на этом форуме;47070104]Но то что производители и разработчики втихаря от пользователя ремапят сектора и повреждённые файлы выдают как целые мне кажется сильно натянутой историей[/quote] Ну да, смотрим в книгу а видим фигу... То что система самодиагностики накопителя втихаря от пользователя занимается выводом из обращения поврежденных секторов это секрет Полишинеля, и некоторые пользователи даже знают о чем говорят значения атрибутов 05, 196 и 197 в SMART. Но почему-то считают что все что делает накопитель "втихаря" не имеет никакого отношения к хранящейся на накопителе пользовательской информации. Вы уж определитесь - если в секторе появились проблемы и накопитель без согласия пользователя вывел сектор из обращения и заменил его на резерв это страшилка али наоборот, фактическое положение вещей? А если это фактическое положение вещей находящее отражение в изменении соответствующих атрибутов SMART то как юзер может быть уверен в том что из обращения выведен сектор который не занят а не относящийся к конкретному файлу? А если из обращения выведен сектор относящийся к конкретному файлу то остался ли файл в целкости и сохранкости? :)))))))

19-Wlad >

Я вот не уверен, но по-моему вы не правы.
При офлайн сканировании, сектор с которого всеми физическими способами вычитка невозможна ставится во временный дефект-лист и всё, точка. Пока тот файл...СЕКТОР не понадобится для чего-нибудь хосту. Вот тогда и будут реализовываться дальнейшие сценарии.
Вы же утверждаете если я правильно понял, что микрокод контроллера замаскированно ремапит UNC сектора, произведя деструктивные действия в отношении ОС. Полагаю это запрещено всеми логиками всех производителей.

[quote=Еще год на этом форуме;47070418]Я вот не уверен[/quote] [quote=Еще год на этом форуме;47070418] сектор с которого всеми физическими способами вычитка невозможна ставится во временный дефект-лист и всё, точка.[/quote] Зашибись! А ИНФОРМАЦИЯ которую невозможно вычитать из этого сектора - что, Всевышний ее заранее заботливо забэкапил и всемилостивше вернул в тот сектор которым заместился перемещенный в Relo? :))))) Определитесь таки наконец - если сектор низзя прочесть то все, на этом месте в файле к которому относится этот сектор БУДЕТ ДЫРА. И заполнится эта дыра содержимым резервного сектора, то бишь 00. А исходно содержавшаяся в этом месте файла информация ПОГИБЛА. Для методов юзера - безвозвратно. Я допустим могу опираясь только на заводской лист дефектов накопителя пересчитать транслятор и попытаться вычитать содержимое тех секторов которые накопитель вывел из обращения - но толку как правило от этого немного, хотя бывают и приятные исключения, на пример в тех случаях когда у накопителя начинается деградация голов и он тупо начинает метать в глисту те сектора которые еще вполне читаемы.
В общем, не нужно обольщаться и выдавать желаемое [quote=Еще год на этом форуме;47070418]Полагаю это запрещено всеми логиками всех производителей.[/quote] за действительность. А действительность проста как семейные трусы - производителя накопителя очень мало колышыт целостность-сохранность пользовательских данных. Производитель даже особо отмечает что [b]Настоящая гарантия не распространяется на утрату данных[/b] - пункт [b]На что данная ограниченная гарантия не распространяется?[/b] в условиях гарантии на пример Сигейта, читать до слез по ссылке [url]https://www.seagate.com/ru/ru/support/warranty-and-replacements/limited-consumer-warranty/[/url]
Итак, юзеру стоит принять за данность что его данные производителю харда по барабану, и у производителя совсем другие интересы - и первый из них [b]МИНИМИЗИРОВАТЬ КОЛИЧЕСТВО ВОЗВРАТОВ НАКОПИТЕЛЕЙ ПО ГАРАНТИИ.[/b] Поэтому система внутренней самодиагностики накопителя заточена именно на это, а не на то чтобы уберечь пользовательские данные.
Ну и еще один веселый момент: на производителя работает статистика больших чисел. В том же терабайтном накопителе имеется почти два миллиарда секторов по 512 байт - ну подумаешь, сотня-две из них перестали читаться и находящиеся там данные утратились! Часть секторов попадет в незанятое место, часть в занятое бесполезными и не влияющими на работоспособность системы данными, часть в файлы которые заменяются операционной системой, как на пример системные dll замещаемые при повреждении из dll-cash. Часть угодит в аудио-видеофайлы, где на один поврежденный сектор в 99,99999% случаев посрать и розами засыпать и о том что в кинухе "имеются повреждения" никто никогда не подумает. Часть угодит в файлы обладающие большого уровня избыточностью, на пример в те же изображения в Raw, и опять таки останется маленьким белым пятнышком на которое юзеру покласть с посвистом. А те пара-тройка десятков секторов которые попали в те файлы в которых их появление критично, навродя представленного выше jpeg будут в основном кочевать из одного накопителя в другой, пока след откедова они появились не затеряется окончательно и бесповоротно. И обнаружится трабла через пятилетку, и то нежданно-негаданно, когда юзер наконец-то решит посмотреть фотку....
И в любом случае к производителю накопителя юзер не может предъявить претензию - производитель не отвечает за сохранность данных.

Влад, а вас не затруднит в конце каждого невменяемого потока сознания отдельной строкой писать: [b]Резюме[/b] - и там десять слов.

Весь прикол в том что описанная ДЫРА появляется в момент изготовления диска, и при первичной разметке такие сектора выводится из работы. При эксплуатации сектор никогда не сдыхает прям нафик сразу, он с первого оборота может не читаться, это да, такие сектора вполне восстановимы аппаратными ресурсами, сдвиг головок, изменение токов чтения, применение есс и тд. Именно подозрительные сектора авторемап и переносит втихоря, изменяя только показатели смарт. А вот совсем-совсем дохлые - маркированные как бэды, без уведомления ОС не переносятся никогда.

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

[quote=Лысый;47074007]Ситуация, когда накопитель записал без ошибки данные в сектор, а потом из этого сектора прочитал другие данные также без ошибки - из ряда вон выходящая[/quote] Ну не такая у "из ряда вон" - тот же самый карамболь у 2.5 Тошиб, тот же самый карамболь у Хитачей с неснятой у паспорте галчонкой начинающейся с буквы "a". Ну а про Самцов ты в курсе и сам! ;) Так может тогда алгоритм [quote=Еще год на этом форуме;47072749]Именно подозрительные сектора авторемап и переносит втихоря, изменяя только показатели смарт[/quote] относятся к WD, у которых есть Relo, куды самодиагностика сбрасывает сектора которые еще не перешли в состояние "савсэм мёртвий!"? А там где только один лишь пользовательский лист дефектов имеется а таблицу для кандидатов .[quote=Лысый;47074007]кривые руки программистов - разработчиков софта накопителя[/quote] не заложили там эта возможность имеется и намного выше шанс на эту граблю наступить?
В том то и замес что для работы с накопителем в формате "юзер обыкновенный" когда никакие методы отключения всех этих дурацких самодиагностических процессов у накопителя невозможно для юзера априори процессы вывода из обращения секторов которые "савсэм мёртвий" и обнаруженных при автоскане все равно происходит, только вот юзер нифига это не понимает. Ну затупил чегось комп, завис, юзер его ребутнул и счастливо продолжил работу. А почему так - темна вода во облацях. Вспомни "волшебные" галки в паспорте Сигеля, и как там вторая сверху строчка называется, та, которая с "А"? И если убрать галку с третьей сверху строки то мы вообще все это Авто "влет" получим, а не в момент новой инициализации харда с соответствующими изменениями в трансляторе.
К тому же не будем рассматривать ситуевину когда мы записали файл и тут же к нему обращаемся. Нет, рассмотрим ситуацию именно когда мы файл сбросили на накопитель, а потом к этому файлу никогда не обращаемся, и лезет к нему лишь самодиаг в режиме оффлайн скана.
Кратко резюмирую - ситуации с замещением исходных данных ВОЗМОЖНЫ. Редко-часто это в общем то другой вопрос. Главное что они есть, они не могут не есть - и в результате ИНОГДА получается погрызенный файл.

[quote=Wlad;47074079] Кратко резюмирую - ситуации с замещением исходных данных ВОЗМОЖНЫ. Редко-часто это в общем то другой вопрос. Главное что они есть, они не могут не есть - и в результате ИНОГДА получается погрызенный файл. [/quote]
Эти ситуации возможны, когда пациент скорее мертв, чем жив, например мне встречались при почти дохлых головках или нестандартных "галочках" в паспорте, которые обычный пользователь никогда не поставит.
Замещать данные и не уведомить хост о проблеме - нонсенс или же явный баг в фирмваре.
Иначе можно докатиться до того, что нафиг нужны эти контрольные суммы, ECC и прочая лабуда. Ну и что, что иногда данные будут не те, зато работать будет быстрее и по гарантии не вернется, пока совсем не умрёт:-)

[quote=Лысый;47074089]Эти ситуации возможны, когда пациент скорее мертв, чем жив[/quote] А к нам какие попадают? Те самые, с которыми школоло с Р-Студией нихрена не смогло сделать! :)))))
Причем не один и даже не десять раз была ситуация, когда помимо файлов конкретно битых и занесенных в Problem в виду того что некоторые их сектора были не прочитаны среди вычитанных без ошибок тоже имеет место битое. Как ты это объяснишь, а? С точки зрения "если все прочлось без ошибок то файл целый" нихрена объяснение не вытанцовывается, все прочлось но файл битый! При этом все методы по отключению "автомата" выполнены, то есть заведомо в процессе вычитки тобой уже нихрена не подменялось. То есть какой вывод? А простой и логичный - все [s]уже украдено до нас[/s] произошло еще тогда, когда хард трудился у пользователя или при его вычитывании дядей Ламером, пилящим поверхность тупой Р-Студией до потери пульса.

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

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

сначала происходит вот это:
[IMG]https://a.radikal.ru/a39/1909/bf/b3a79ccc2cc7.jpg[/IMG]

затем происходит вот это:
[IMG]https://c.radikal.ru/c22/1909/cc/2d1344f03f28.jpg[/IMG]

Всё остальное я хз откуда вы берёте. Уж сколько петабайт данных я перехранил не сосчитать... НИ РАЗУ НЕ ВИДЕЛ битой картинки если её перед этим сервисной программой не прогнать.

31-Еще год на этом форуме > Полный пипец.... Человече, у тебя походу даже с банальной логикой проблемы! Ты привел скрин
[img]https://c.radikal.ru/c22/1909/cc/2d1344f03f28.jpg[/img]
Попробуй ПОДУМАТЬ что дальше! Не на уровне дяди Кипящего Чайника, а исходя из внутренней логики работы накопителя. Во первых, исходим из предположения что сектор на котором споткнулся накопитель поврежден настолько что содержащаяся в нем информация не может быть считана, никакие ЕСС не помогают, чтобы не было [quote=Еще год на этом форуме;47072749]такие сектора вполне восстановимы аппаратными ресурсами, сдвиг головок, изменение токов чтения, применение есс и тд.[/quote] Хотя головки накопитель не "сдвигает", это вам не дисковод где можно винтиком покрутить положение головок, головка наглухо привязана к серворазметке и "вправо-влево" от сервы будет ваще бодрый стук - в реальности нагревом слайдеров изменяется высота полета головки над поверхностью, и соответственно параметры чтения. Так же никаких "токов" не изменяется, какие нахрен "токи" в полупроводниковом кристалле созданном по проектным нормам 5-7 нанометров? Просто тупо делается энное количество циклов чтения, при разной высоте полета головы над поверхностью, и если хотя бы одна из попыток удачна то алилуйя! - данные вычитаны. Но у нас сектор поврежден, и информация в нем утрачена окончательно и бесповоротно! Все, ЕЕ БОЛЬШЕ НЕТ. Так что будет в тот момент когда дядя Ламо жмакает в очередной раз "Повторить попытку"? А это уже зависит от производителя накопителя, и конкретно примененых там принципов замещения трупного сектора из резерва. У уже вышеупомянутого Самца M8E следующая попытка чтения будет удачной, но вычитан будет файл в битом виде, поскольку система самодиагностики накопителя оперативненько подменила битый сектор на целый. У WD и Сигеля можно жмакать "Повторить" хоть до посинялова - накопитель пометил сектор как битый, но в текущем сеансе работы ничего не может сделать - для этого ему нужно пересчитать транслятор. Говорить о принципах трансляции считаю излишним, это вообще тема не для рядовых юзеров, скажу лишь что харды в которые разработчик заложил динамический транслятор в легкую ремапят не читаемые сектора в процессе работы, там где транслятор статический и применение новой таблицы трансляции возможно лишь при новой инициализации харда замещение сектора откладывается до пересчета транслятора, которое произойдет при следующем включении питалова.
Но что в первом что во втором варианте в отношении конкретного файла результат монописуален - ФАЙЛ УЖЕ БИТЫЙ. И то что его можно вычитать "после того как" это всего-навсего тонкий намек на ту граблю о которой говорилось выше, а именно ПОЯВЛЕНИЕ БИТЫХ ФАЙЛОВ СРЕДИ ВЫЧИТАННЫХ БЕЗ ОШИБОК.
Оно понятно что рассуждения у парадного подъезда исходящие от человеков которые в своей жизни сделали пяток-десяток копий с собственной пары-тройки накопителей вообще не должны приниматься во внимание, но наш благословенный интернет населяют сотни миллионов таких юзверей, а вот тех кто восстанавливал данные с накопителей с проблемами в лучшем случае десток человек на миллион, а тех кто при этом соображает что делает и разбирается в процессах происходящих в накопителе и того меньше. И фигли мне показывать на
[img]https://a.radikal.ru/a39/1909/bf/b3a79ccc2cc7.jpg[/img]
? На каком основании Винда выдала эту картинку? Посмотрев показания SMART, нарвавшись на битый файл среди тех которые загружала и который был заменен имеющейся в распоряжении Винды резервной копией? Ну и какое это отношение вообще имеет к пользовательским данным, тем самым которые уникальны и неповторимы в отличии от Винды которую может переустановить любое школоло? Винда своими тупыми мессагами лишь сообщает о том что В ЕЕ РАБОТЕ есть траблы, и пытается пнуть юзверя в каком-то направлении. Но при этом думать Винда естественно не умеет, а реагирует на заложенные при ее написании сценарии. И если сценарий не предусмотрен то юзверь ваще не в курсах о том что у накопителя имеются проблемы - как на пример накопитель в режиме оффлайн скана обнаружил битый сектор, влет заремапил или отложил до перезагрузки с пересчетом трансляции - но Винда о этом ни сном ни духом, поскольку оффлайн скан осуществлялся в тот момент когда с точки зрения Винды накопитель находится В ПРОСТОЕ.
В общем, смысл разговора с слепыми о радуге считаю нулевым, и предоставляю им оставаться при собственном мнении о том что их данные в целкости и сохранкости потому что они прочитались...

Wlad вы уж простите, но читать ваши излияния даже до половины я больше не могу. Однако держите пару тезисов:
1. Ваши "выпады" а каждом посте настолько же наивны насколько и неуместны. Если желаете услышать вашу характеристику в ответ, пожалуйста: фрагментированность знаний и неумение выражать научное мышление говорит о вас как о мартышке, которая ударив по ЭЛТ-телевизору заставила его работать и уверена что починила. Слишком уж видно что ни системного образования в области носителей информации, ни углубленной подготовки от производителей у вас нет. И ремонтируете вы их почитывая сервис мануалы или другую лежащую на поверхности инфу

2. По роду деятельности, я не умею возможности досконально изучать все аспекты ИТ, и углубляюсь только когда сталкиваюсь с проблемой. Я правильно понял, все ваши посты вы тупо оспариваете тезис: "если файл прочитался то он не повреждён"? Итак. Вы готовы поставить свою бессмертную душу на спор, что микрокод контроллера после невычитывания сектора и маркировки его как unc или bad выпиливает данные НЕ СООБЩАЯ ОБ ЭТОМ ХОСТУ (ОС)?

Wlad вы уж простите, но читать ваши излияния даже до половины я больше не могу. Однако держите пару тезисов:
1. Ваши "выпады" а каждом посте настолько же наивны насколько и неуместны. Если желаете услышать вашу характеристику в ответ, пожалуйста: фрагментированность знаний и неумение выражать научное мышление говорит о вас как о мартышке, которая ударив по ЭЛТ-телевизору заставила его работать и уверена что починила. Слишком уж видно что ни системного образования в области носителей информации, ни углубленной подготовки от производителей у вас нет. И ремонтируете вы их почитывая сервис мануалы или другую лежащую на поверхности инфу
По роду деятельности, я не умею возможности досконально изучать все аспекты ИТ, и углубляюсь только когда сталкиваюсь с проблемой.
2. Я правильно понял, все ваши посты вы тупо оспариваете тезис: "если файл прочитался то он не повреждён"? Итак. Вы готовы поставить свою бессмертную душу на спор, что микрокод контроллера после невычитывания сектора и маркировки его как unc или bad выпиливает данные НЕ СООБЩАЯ ОБ ЭТОМ ХОСТУ (ОС)?

34-Еще год на этом форуме > [quote=Еще год на этом форуме;47092494]ни углубленной подготовки от производителей у вас нет[/quote] А у вас есть? :))))) Меньше включая лапшенаухонавесочную машину будете меньше выглядеть дураком. Производители накопителей вообще не поощряют копания в их продукции, и академиев по датарекавери нет. Запишите это в мемориз, чтобы больше никогда на эту тему не умничать.
А в качестве второго тезиса вопрос - сами вы на каком уровне? В нутро накопителя заглядывали хоть раз, или начитавшись статей таких же как и вы ламеров рассуждаете? Контрольный вопрос на засыпку: почему модуль 6F у накопителей WD всегда читается с ошибкой и какая эта ошибка?

[img]https://3dnews.ru/assets/external/illustrations/2015/12/25/925853/sm.Synology.800.JPG[/img]

воткнул [b]2х2 Tb HDD [u]RAID1[/u][/b] (плюс USB 2 Tb и 500 Gb), доступ из любого места и с любого устройства (кроме микроволновок, чайников и тп)

полтора года не кашляет.

Божечки, вы всё пенитесь как я посмеялся над вами в теме про 3битные ячейки в ssd накопителях? Ну так производители же услышали ваши стоны и сделали ... 4х битные.

Отсутствие академических знаний, ранимость, зависимость от чужого мнения ... у вас женщина-то есть?

[quote=Wlad;47069638]волшебная процедура autoreassign которая выполняется в фоне и незаметно для юзера обнаружила что такой-то физический сектор не читается. А поскольку это внутренняя процедура исполняемая системой самодиагностики накопителя то ей по глубокому барабану, содержит ли информацию этот сектор и связан ли с каким файлом для файловой системы - этот сектор тупо замещается на сектор из резерва. Естественно, без всякого переноса в этот замещающий сектор тех данных которые были в замещенном секторе. И вот у нас появился БИТЫЙ ФАЙЛ.[/quote]

Чушь упоротая.

И так как пари из п.2 поста 35 не заключено, то можете смело наклеить вашуже цитату себе на лоб

[quote=Wlad;47092826]Меньше включая лапшенаухонавесочную машину будете меньше выглядеть дураком.[/quote]

Господа, прошу, подключайтесь:

Я утверждаю: при подыхании сектора микрокод контроллера в процессе диагностики пытается его вычитать и перенести, а если вычитывание невозможно контроллер заносит сектор в стоплист и ждёт пока ОС не обратится к этому файлу/сектору, дабы решение принял юзер. Предоставил пруф в виде "невозможности считывания файла".

По заверению Wlad, вы никогда не узнаете что ваши файлы биты, фотки будут неожиданно крошится, музыкальные треки будут заикаться как на царапаном сидюке... ибо микрокод будет переносить невычитываемые сектора в резерв не спрашивая вашего разрешения. Пруфом предоставлена некая фотка, и показания Rat. Хотя тут пологаю авто запуск chkdsk просто прогнал диск и спросив разрешения исправил ошибки.

[quote=Еще год на этом форуме;47097527]Отсутствие академических знаний, [/quote] Академик, ваша позиция ясна - вы нихрена не знаете ни теорию ни практику. Говоря о TLC вам прямо и недвусмысленно говорилось о гораздо более низкой надежности по сравнению с MLC. И о том что QLC при технологиях по которым делалось на тот момент TLC нихрена не вытанцовывалось, бо надежность была нулевой. Применение 3D увеличило надежность TLC практически до уровня "одномерных" MLC - и надо же, производители таки смогли получить рабочие QLC - правда с надежностью куда более говенной чем у современных TLC. Но для ламеров это мега-прорыв, раньше TLC было полным говном, а сейчас таковым стало QLC. Но на деле то ничего не изменилось - надежность хранения падает по мере увеличения уровней хранения, и никакие технологии это не в силах изменить.
Так что умничайте в детском саду, академик. А я предпочитаю разговоры о том что происходит с накопителями вести с людьми которые в отличии от вас ПРАКТИКИ, то есть понимают о чем я говорю. Вас спросили элементарщину, то о чем знает любой человек работавший с накопителями WD на уровне технокоманд. Вы же проигнорировали мой вопрос [s]относительно магнитофона[/s]. Из чего я делаю вполне закономерный вывод - вы НИХРЕНА НЕ ЗНАЕТЕ КАК РАБОТАЕТ НАКОПИТЕЛЬ. Вы никогда с ним не работали иначе чем на уровне чайника, который записывает и считывает файлы абсолютно не задумываясь о том как сам накопитель устроен и как работает. И отсюда ваша баранья упертость, академик. Вы просто вообще не знаете предмета, что-то слышали, что то там такое в интернете читали. Но сами вы - НОЛЬ. Такой круглый, обтекаемый со всех сторон потоками ламеризма. Спорить о вкусе устриц можно только с теми кто их ел - вы же эти устрицы даже в глаза не видели, не то что нюхали. Я уважаю мнение Лысого, поскольку мы с ним начали заниматься датарекавери прктически одновременно, еще в конце прошлого века - и с ним я могу разговаривать о нюансах работы конкретного накопителя конкретного производителя. А с вами то о чем разговаривать? Вы же просто не понимаете обо что я, академик! Вам уже сказали - по датарекавери академиев нет, и вам неоткуда взять знания в этом вопросе, академик. ВЫ ПИТАЕТЕСЬ СЛУХАМИ. Я же практически работаю с восстановлением данных, через мои руки прошла не одна тысяча накопителей различных производителей и моделей.
И ваше заявление [quote=Еще год на этом форуме;47097589]сли вычитывание невозможно контроллер заносит сектор в стоплист и ждёт пока ОС не обратится к этому файлу/сектору, дабы решение принял юзер[/quote] это вершина ламеризма, масло масляное, набранное вумными буквами человеком который нихрена в реальности не знает. Какой [b]КОНТРОЛЛЕР[/b], академик? Слово вы умное употребили, да жаль в том месте где оно нихрена не подходит! Если вы имели в виду PCB накопителя с стоящей на ней микросхемой микропроцессора то вам банально неведомо, что сама по себе PCB не функциональна, и накопитель работоспособен только после того как поднимет с блинов и построит в ОЗУ PCB ту ОС(микропрограмму) под управлением которой работает. И все что делает накопитель происходит согласно микропрограмме. Так что если вы пытаетесь умничать за накопитель то не употребляйте слово "контроллер", оно сразу же палит вас как знатного ламера - говорите "микропрограмма". По крайней мере будете выглядеть не совсем чайником, академик.
Далее - какое нахрен решение может принять юзер если сектор битый? Вы хотя бы попробуйте понять, что вы несете! Юзеру доступно три варианта, и те определяет операционная система . И когда вы привели воэ это
[img]https://c.radikal.ru/c22/1909/cc/2d1344f03f28.jpg[/img]
то в общем-то знатно лоханулись, поскольку вообще-то в реальности варианты звучат как "Abort, Retry, Fail?" и то что Беня Гей-тс их перетолмачил на русский через задницу и забыл объяснить ламерам что Fail происходит от английского слова failed означаюшее "неудачно" и для ламерья это стало почему-то "Отмена" вместо того чтобы ПРИЗНАТЬ ЗА ДАННОСТЬ НЕУДАЧНОЕ ЗАВЕРШЕНИЕ ОПЕРАЦИИ. Итак, академик, у нас имеется три варианта:
1. ретрить, то бишь повторять до посинения.
2. игнорить, то есть пропустить ошибочно считываемый файл.
3. признать то что операция закончилась с ошибкой.
Все три варианта по сути одно и то же - ФАЙЛ НЕ ВОЗМОЖНО СЧИТАТЬ БЕЗ ОШИБКИ. То есть ОШИБКА ИМЕЕТ МЕСТО, от нее никуда не деться, она УЖЕ ЕСТЬ[s] и не может не есть[/s]. Файл УЖЕ БИТЫЙ, академик. И можете больше не распинаться, это факт а не реклама. Вы обратились к битому файлу и получили отлуп. На этом ваша история как история ламера которому недоступна работа с накопителем на уровне технокоманд окончена, отойдите в сторонку и тихо покурите бамбук, пока взрослые дяди-датарекаверисты достают то на чем вы сломали свои молочные зубки. Ибо вы влипли в ситуацию когда система самодиагностики накопителя НЕ МОЖЕТ САМОСТОЯТЕЛЬНО УСТРАНИТЬ ПРОБЛЕМУ. Помните я выше говорил за атрибуты SMART? Там спешиал для умных людей есть такой 198, называется он Uncorrectable Sector Count. Перевести для вас, академик, бо судя по вашему уровню вам составляет мега-трудность понимание англицкого диалекту? Так вот, на русском ошибка звучала бы как "не корректируемые сектора". И появляется эта ошибка тогда когда система самодиагностики накопителя не смогла засунуть поврежденный сектор в пользовательский лист дефектов. А если смогла то у нас уменьшится значение атрибута 5 - Reallocated Sectors Count, или по русски "Количество переназначенных секторов". И сделает эту операцию накопитель абсолютно незаметно для вас, академик. Ни мессагу не пошлет на е-майл, ни в ватсап не напишет.
Вот так то, академик. Булькайте дальше, мне с вами говорить не о чем, вы НЕУЧ, МНОГО О СЕБЕ ВОЗОМНИВШИЙ.