Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 162
В том же NTFS есть штатно есть спец файл в котором хранятся бэды, чтобы туда ничего не писалось. И вроде бы есть ключ
чтобы эти бэды найти и пометить.
/R Locates bad sectors and recovers readable information
(implies /F).чтобы эти бэды найти и пометить.
Викторией точно результата не даст.
А винда в конце должна написать сколько секторов посечено как бэды, по крайне мере раньше так делала.
А винда в конце должна написать сколько секторов посечено как бэды, по крайне мере раньше так делала.
Если лезут уже ФС-ные бэды, то хард лучше в помойку, это значит, что G-List уже забит под завязку, а он весьма приличного объёма. Ну или пересчитать транслятор, чтобы G-List в P-List перенесло, но толку мало — винт уже начал активно осыпаться.
Мне это вполне понятно, это больше к автору. Ну и с другой стороны для эксперементов вполне годятся подубитые винты.
Если G-List забит под завязку, вряд ли ОС уже будет в состоянии вообще что-то делать. Обычно это всё же софт-бэды.
Имею опыт (правда древнего, современные может уже так не выживут) обращения с WD на 120Gb (купленного в те времена, когда эти 120Гб были супер-круто и вообще почти максимумом), который навернулся и как в песне «Весь покрытый бэдами» шустро начал сыпаться. Благо это был WD и удалось ему своеобразный LowLevel Format сделать с пересчётом. Он после такого стал на 80Гб, далее через две недели снова прилично сыпаться стал, и с повторением стал чем-то вроде 60Гб. На этом я предпочёл «закопать стюардессу» и купить таки под «инфернетики и музычку поставить» новый диск.
Или просто бэды попали в системную область. Есть у меня такой винт. В итоге сделал ему раздел, начинающийся дальше, чем идут бэды. Ещё был вариант с дохлой серединой — там решилось созданием 2х разделов, до начала бэдов и после них. Использую иногда как дискету — пока работают. Правда со вторым проблема в том, что вында (по умолчанию?) не видит второй раздел. Хотя 10ка может и видит уже.
Если участок диска был поврежден в результате падения, то есть вероятность, что на его сроке жизни это не скажется (когда при повреждении не образовался мусор) если не обращаться к поврежденному участку. В таком случае плохие блоки на уровне NTFS/ext4 как раз могут помочь использовать его будто бы повреждения и не было. Разумеется не для критически важных данных.
Потому что вместо этой «bad» ячейки используется другая из зарезервированной области диска. Вроде облать около пары процентов от емкости диска.
Есть область резервная на диске, которая постепенно расходуется.
Просто обозначу минусы такого решения
1. Не проверяется (и остается под угрозой смерти) служебная зона файловой системы — MFT, директории…
2. Остается риск работы головки в поврежденном цилиндре, вызывая дальнейшую деградацию диска (расширяя задир, например).
Если уж так сильно охота использовать потенциально дохлый винт — правильно будет определить дефектную зону, покрыть её отдельным дисковым разделом с запасом в несколько десятков ГБ (минимум), который не форматировать и никак не трогать — тогда может быть винт и поживет какое-то время, если повезет.
1. Не проверяется (и остается под угрозой смерти) служебная зона файловой системы — MFT, директории…
2. Остается риск работы головки в поврежденном цилиндре, вызывая дальнейшую деградацию диска (расширяя задир, например).
Если уж так сильно охота использовать потенциально дохлый винт — правильно будет определить дефектную зону, покрыть её отдельным дисковым разделом с запасом в несколько десятков ГБ (минимум), который не форматировать и никак не трогать — тогда может быть винт и поживет какое-то время, если повезет.
А зачем нужно покрывать разделом, а почему бы не оставить просто неразмеченное пространство?
PS:
mft еще и увеличиваться в размере будет
PSS: Еще один минус, если HDD подключен к Windows, нужно будет отключить дефрагментацию и, подозреваю, службу индексирования, чтоб избежать перемещения/чтения файла.
PS:
Не проверяется (и остается под угрозой смерти) служебная зона файловой системы — MFT
mft еще и увеличиваться в размере будет
PSS: Еще один минус, если HDD подключен к Windows, нужно будет отключить дефрагментацию и, подозреваю, службу индексирования, чтоб избежать перемещения/чтения файла.
Еще лучше, когда используется чистая зона только до или после бэдовой, чтобы голова через нее не скакала (не считая вкл-выкл).
Логические бэды рассматривать вообще нет смысла. Есть либо реальные бэды (те, что в SMART под номером 05, Reallocated sector count), но они от хоста уже спрятаны в дефект-лист, либо софт-бэды, которые, в зависимости от их поведения, либо будут восстановлены, либо также проследуют в дефект-лист. Вывод: заниматься восстановлением всё же стоит, а автор занимается ерундой.
Есть ещё 197 Current_Pending_Sector — сектора которые не получается прочитать (чек-сумма не сходится), но которые ещё не переназначены (а вдруг когда-то прочитается).
Их можно перезаписать поверху, после этого такой сектор может начать работать нормально (или будет переназначен, если ему кранты), а может и дальше заглючить в самый неподходящий момент.
Их можно перезаписать поверху, после этого такой сектор может начать работать нормально (или будет переназначен, если ему кранты), а может и дальше заглючить в самый неподходящий момент.
Подскажите пожалуйста, а как тогда быть в ситуации, когда количество бэдов не растет годами?
Есть WD Red, на котором 3 бэда вылезло примерно в первый год эксплуатации, и он с ними так и живёт уже почти 5 лет. На нём растет количество «подозрительных» сектором, но когда его форматируешь и заливаешь инфой по новой — они сбрасываются.
Есть WD Red, на котором 3 бэда вылезло примерно в первый год эксплуатации, и он с ними так и живёт уже почти 5 лет. На нём растет количество «подозрительных» сектором, но когда его форматируешь и заливаешь инфой по новой — они сбрасываются.
С появившимися и не увеличивающимися бэдами — забить (особенно если их три штуки, для нынешних объёмов это ничто). Следует учитывать, что с завода диск и так приходит с несколькими сотнями или тысячами бэдов, только они находятся в т.н. P-List, этот список пользователю без сервисных утилит недоступен. Считайте, что эти три сектора — недовыявленные.
В постоянном появлении подозрительных секторов, особенно с учётом того, что это WD, 50/50 виновато окисление контактов на плате. Просто картинка:
В постоянном появлении подозрительных секторов, особенно с учётом того, что это WD, 50/50 виновато окисление контактов на плате. Просто картинка:
Про это я в курсе, когда пошли глюки при обращении к винту разобрал и
протер стёркой — сразу нормализовалось.
протер стёркой — сразу нормализовалось.
Вот каждые полгода-год (в зависимости от условий эксплуатации) и придётся повторять. Это WD, ничего не поделать.
Ну или принимать какие-то меры (люди лудят, смазывают, я не пробовал).
Ну или принимать какие-то меры (люди лудят, смазывают, я не пробовал).
Достаточно припаять
Чтобы потом точно ничего не прочитать? Припой окисляется на воздухе ещё быстрее, чем эта бодяга, которой площадки покрывают.
Или имеется в виду припаять прямо туда клеммную колодку гермоблока, насовсем? :-)
Или имеется в виду припаять прямо туда клеммную колодку гермоблока, насовсем? :-)
Если бы контакты были позолоченные, проблемы бы и не было. Но производитель сэкономил на… сколько там? 0,0001 граммах?
Вообще, это реально выглядит, как злой умысел. На PCI-платах ведь всегда покрывали контакты золотом (палладием, чем там ещё) — даже на китайской дряни.
Вообще, это реально выглядит, как злой умысел. На PCI-платах ведь всегда покрывали контакты золотом (палладием, чем там ещё) — даже на китайской дряни.
Офигеть! Почти сценарий "Идиократии". «Инженеры» с «дипломами» «успешно» работают не только в отдельно взятых странах.
Кстати, у нас была та же проблема с недорогими мобильными телефонами — не принимали сим-карты. Решение было похожее, но чуть жёстче. Там даже лак был не снят. Но партию, тем не менее, сертифицировали и запустили в продажу).
Будущее наступает быстрее, чем мы ожидали.
Кстати, у нас была та же проблема с недорогими мобильными телефонами — не принимали сим-карты. Решение было похожее, но чуть жёстче. Там даже лак был не снят. Но партию, тем не менее, сертифицировали и запустили в продажу).
Будущее наступает быстрее, чем мы ожидали.
3,5" WD, Seagate, Toshiba — весь этот зоопарк имеет схожую проблему. Большинство начало так делать на винтах объема после 80гб. С 2.5" тоже самое, целая пачка ноутбучных тошиб лежит с такими же проблемами. Старые винты редко этим грешили 20-гиговые остались живы и имеют нормальные контактные площадки, даже не намека на окисление. Когда перебирал свои думал статью запилить с картинками, но как обычно лень победила.
А с «Паспортами» такой трюк проходит?
Это самая важная картинка в статье. Хотя бы раз в два-три года старые диски необходимо чистить ластиком. Чтобы они не сдохли раньше времени. Т.к именно это фото — наиболее частая причина преждевременной смерти диска.
А для этого надо диск разбирать, верно?
И что с SSD, не скажете, они имеют ту же проблему? А то у меня есть один глючный, то месяцами норм работает, то каждый день материться начинает и файлы теряет.
И что с SSD, не скажете, они имеют ту же проблему? А то у меня есть один глючный, то месяцами норм работает, то каждый день материться начинает и файлы теряет.
Есть такая утилита MHDD и ее наследник Victoria, делают то, что вы хотите, только корректно. А еще используются штатную систему ремапа, которая есть в каждом жестком диске. Суть — та-же что у вас, запомнить сбойные сектора, и назначить вместо них сектора из резерва. Резерв большой. Если резерв закончился и сектора не могут быть переназначены — значит диск сыпется и очень активно, умрет скоро и внезапно.
А теперь почему ваш метод работать не будет. Коротко — проблема в таймауте. Утилиты используют таймаут в 1с и не делают повторных обращений если он истек. А вот ваша утилита будет пробовать прочитать этот сектор ооочень долго. Если сбойных секторов 100 шт — то это не проблема. А вот если сбойный целый гигабайт — вы просто залипните на нем на всегда.
Более того, это увеличит износ механизма умирающего диска, и долбить он будет самую слабую зону. Что еще хуже. Есть такая штука — как запил дорожки, тогда выпадает много секторов подряд. И лучше тогда эту дорожку не трогать, нужно найти ее начало, и обрезать отдельным разделом с запасом с обоих сторон.
Еще один минус вашего метода — дефрагментация, она все сломает. Вернее она будет зависать, т.к. дефрагментатор попробует получить доступ к сектору и зависнет.
Еще один минус — система может решить проиндексировать файлы, или проверить их на вирусы, или просто-так их считать. И зависнет.
Итого: пользуйтесь штатными средствами. Сначала СМАРТ диагностикой и СМАРТ ремапом через Викторию. Если бедов мало но смарт не смог, то проверкой встроенной в винду с галочкой проверки секторов. Если много — вырезанием целыми разделами.
А теперь почему ваш метод работать не будет. Коротко — проблема в таймауте. Утилиты используют таймаут в 1с и не делают повторных обращений если он истек. А вот ваша утилита будет пробовать прочитать этот сектор ооочень долго. Если сбойных секторов 100 шт — то это не проблема. А вот если сбойный целый гигабайт — вы просто залипните на нем на всегда.
Более того, это увеличит износ механизма умирающего диска, и долбить он будет самую слабую зону. Что еще хуже. Есть такая штука — как запил дорожки, тогда выпадает много секторов подряд. И лучше тогда эту дорожку не трогать, нужно найти ее начало, и обрезать отдельным разделом с запасом с обоих сторон.
Еще один минус вашего метода — дефрагментация, она все сломает. Вернее она будет зависать, т.к. дефрагментатор попробует получить доступ к сектору и зависнет.
Еще один минус — система может решить проиндексировать файлы, или проверить их на вирусы, или просто-так их считать. И зависнет.
Итого: пользуйтесь штатными средствами. Сначала СМАРТ диагностикой и СМАРТ ремапом через Викторию. Если бедов мало но смарт не смог, то проверкой встроенной в винду с галочкой проверки секторов. Если много — вырезанием целыми разделами.
Запил дорожки опасен еще и тем, что он может повредить головку. Что приведет к невозможности считать целую пластину, и если по несчастливой случайности это оказалась первая пластина со служебными данными — к выходу из строя сразу всего жесткого диска. Он просто перестанет определяться в системе и будет бесконечно пытаться инициализироваться…
Кстати, не понимаю, почему производители жестких дисках в своих прошивках не предусмотрели таймаута. Ведь если сектор не считался за секунду, то дальше его пытаться считывать бессмысленно…
Кстати, не понимаю, почему производители жестких дисках в своих прошивках не предусмотрели таймаута. Ведь если сектор не считался за секунду, то дальше его пытаться считывать бессмысленно…
На серверных как раз предусмотрели.
Если брать винты «RAID Edition», то там оно штатно очень быстрое (WD сами писали, что их серия RE не пытается по секунде прочитать сектор — не прочитался — отрапортовать как битый).
Таймаут есть, но он большой, как раз потому, что домашние диски редко в рейде, а значит с них намного важнее скачать таки файл, чем корректность работы в состоянии отказа.
В дисках рассчитанных на работу в рейде таймаут намного короче, потому-что они обычно в рейде. И чем раньше контроллер поймет что сектор умер, тем раньше возьмет резервную копию.
Насчет того, что шанс не считать сектор с Н попытки равны нулю, вы не правы. На считывание сектора влияет точность позиционирования головки, может оказаться что с Н попытки повезет таки стать немного не так и считать.
В дисках рассчитанных на работу в рейде таймаут намного короче, потому-что они обычно в рейде. И чем раньше контроллер поймет что сектор умер, тем раньше возьмет резервную копию.
Насчет того, что шанс не считать сектор с Н попытки равны нулю, вы не правы. На считывание сектора влияет точность позиционирования головки, может оказаться что с Н попытки повезет таки стать немного не так и считать.
MHDD и Victoria а также HDDScan думается всё-таки «одногодки» чем кто-то чей-то наследник. И хотя появились немного в разное время, идеологически относятся к одному поколению.
А так да — сплошная запись всей поляны с последующей проверкой, и если жесткий диск ещё на что-то годен, бэды он должен скрыть. И если повезёт, дальше будет работать нормально. Но для современных моделей, остановка деградации поверхности — редкость.
А так да — сплошная запись всей поляны с последующей проверкой, и если жесткий диск ещё на что-то годен, бэды он должен скрыть. И если повезёт, дальше будет работать нормально. Но для современных моделей, остановка деградации поверхности — редкость.
А есть какое то более современное решение, но под linux?
Ещё со студенческих времен у меня стояла куча жестких дисков
Да, десятки дисков тоже были.
И даже исправные…
Подумал, посчитал и выкинул.
Ибо те размеры сейчас…
Нужен BigTower, чтобы получить какой-то смешной объем 700Г с этих десятков дисков.
Да «корпус-мать-блок питания-контроллер дополнительный-прочее» обойдутся дороже, чем купить новый современный диск в разы больше.
Как-то жалко выкидывать 4ТБ винт когда на нем всего с десяток бэдов. Причем в большинстве случаев их количество растет не быстро
А это очень даже непредсказуемо, к сожалению.
А у меня лежит куча клиентских с бэдами + USB-адаптер для их подключения. Работать на них уже нельзя, храню то, что не жалко потерять: сериалы, фильмы, музыку. Меньше места, чем DVD занимают.
Подумал, посчитал и выкинул
Я из старых дисков еще неодимовые магниты вытаскивал. Они очень мощные, правда в быту почти бесполезны. Но как-то рука не поднялась их выкинуть.
Они прекрасно справляются с людским любопытством: кладёшь магнит у таблички «не пытайся разъединить, особенно с помощью ногтей и пальцев» и с любопытством наблюдаешь, сколько людей умеют читать и осознавать прочитанное.
На хабре не принято спрашивать за что минус) Но вот просто интересно, разбор старого жесткого диска с целью извлечения магнитов это какой-то харассмент?)
Подарите их в ближайший гаражный(самого низкого уровня) сервис, который сваркой и жестянкой занимаются — они вам спасибо скажут.
Ну не скажите.
1. Пара магнитов прекрасно скрепляет открытые пакеты с сыпучим содержимым(кофе/мука/сухие завтраки/специи и т.д.)
2. Не заменимы для студента(фиксация листов бумаги даже через толщину стола и прочее)
Думаю, ещё много чего можно добиться просто смекалкой. У меня дома штук 20 магнитов и все в деле. Раз в пару месяцев приходится вскрывать очередного кандидата(благо старья навалом) исключительно ради магнитов.
1. Пара магнитов прекрасно скрепляет открытые пакеты с сыпучим содержимым(кофе/мука/сухие завтраки/специи и т.д.)
2. Не заменимы для студента(фиксация листов бумаги даже через толщину стола и прочее)
Думаю, ещё много чего можно добиться просто смекалкой. У меня дома штук 20 магнитов и все в деле. Раз в пару месяцев приходится вскрывать очередного кандидата(благо старья навалом) исключительно ради магнитов.
Раз решения нет, значит будет. Немного подумав решил поступить самым простым способом — написать консольную утилитку забивающую винт файлами, а потом проверяющую эти файлы на чтение. Файл прочитался? Отлично, сектор под файлом целый, файлик удаляем. Не читается? Вот и нашли бэд блок, файл оставляем на этом бэде чтобы ничего больше на него не писалось.
Как это нет?
Это делает сама файловая система, это делает и firmware диска.
Все делается автоматически.
А ваш вариант несерьезны.
Ибо автоматика оптимизации-дефрагментации в современных файловых системах запросто эти ваши «спец. файлы» переместит куда ей надо, а не куда вам надо.
И пока она будет это делать — файлы-то с бэдами — вся работа с диском будет в лучшем случае тормозить дико. А то и вообще дисковые операции подвиснут (скорее всего так и будет)
Большинство утилит пытаются эти сектора восстановить.
Штатная утилита операционной системы — эти сектора долго-тщательно проверяет и заносит в BAD block list файловой системы.
О, некромантия над битыми дисками — это моё, это я люблю. :)
Но ваше решение, как уже справедливо заметил sysd, не очень: винда может вдруг решить, что файлы на диске слишком фрагментированы, и перенесет заглушки в другое место.
Что касается бэдов. Если они появляются в малом количестве и редко, то лучший способ — заставить контроллер диска подменить их. Я лично использую для этого пару скриптов и утилиту hdparm под линуксом (конкретно — команды --read-sector и --repair-sector). Причина проста: посекторная проверка большого диска может занять пару суток. Под линуксом у меня круглосуточно крутится NAS, а виндовую машину приходится выключать на ночь, так что выбор платформы очевиден.
Если битых секторов становится слишком много и подменять их становится нечем, или если битые сектора появляются слишком часто, то проще такой диск разобрать на магнитики.
Впрочем, если хочется помучиться, то можно попытаться использовать помехоустойчивое кодирование (тот же код Рида-Соломона). Тогда можно подобрать параметры кодирования таким образом, что файл(ы) можно будет восстановить даже после выпадения нескольких подряд идущих секторов. Правда, придется заморочиться со специальными утилитами для кодирования-декодирования файлов на ненадежном диске. А в идеале — вообще наваять помехоустойчивую файловую систему. :)
Но ваше решение, как уже справедливо заметил sysd, не очень: винда может вдруг решить, что файлы на диске слишком фрагментированы, и перенесет заглушки в другое место.
Что касается бэдов. Если они появляются в малом количестве и редко, то лучший способ — заставить контроллер диска подменить их. Я лично использую для этого пару скриптов и утилиту hdparm под линуксом (конкретно — команды --read-sector и --repair-sector). Причина проста: посекторная проверка большого диска может занять пару суток. Под линуксом у меня круглосуточно крутится NAS, а виндовую машину приходится выключать на ночь, так что выбор платформы очевиден.
Если битых секторов становится слишком много и подменять их становится нечем, или если битые сектора появляются слишком часто, то проще такой диск разобрать на магнитики.
Впрочем, если хочется помучиться, то можно попытаться использовать помехоустойчивое кодирование (тот же код Рида-Соломона). Тогда можно подобрать параметры кодирования таким образом, что файл(ы) можно будет восстановить даже после выпадения нескольких подряд идущих секторов. Правда, придется заморочиться со специальными утилитами для кодирования-декодирования файлов на ненадежном диске. А в идеале — вообще наваять помехоустойчивую файловую систему. :)
>помехоустойчивое кодирование (тот же код Рида-Соломона)
Есть файловые системы с контролем целостности, а с избыточностью, насколько я знаю, нету.
Как вариант можно попробовать RaidZ массив на ZFS, он, вроде, может обнаруживать поврежденные участки и заменять их неповрежденными с соседних дисков.
Есть файловые системы с контролем целостности, а с избыточностью, насколько я знаю, нету.
Как вариант можно попробовать RaidZ массив на ZFS, он, вроде, может обнаруживать поврежденные участки и заменять их неповрежденными с соседних дисков.
Мощная утилита, впечатен. Может поделитесь скриптами hdparm или посоветуете еще что то под linux для решения проблем с бэдами (тоже люблю некромантию), кроме достаточно быстро нагуглившихся smartctl и badblocks. Моя любимая — HDD Regenerator, но грузится из под DOS, что достаточно неудобно при современных объемах.
Скрипты, наверное, выложу на гитхаб попозже — сейчас я от них далеко. :)
Джентльменский набор — это smartctl, dd, scrounge-ntfs и hdparm.
smartctl позволяет проконтролировать количество бэдов.
dd позволяет сдампить образ диска для последующего выдирания с него файлов (если указать параметр conv=noerror). Также dd позволяет быстро найти сбойный сектор на диске (читаем все подряд блоками по 4 кб, при сбое чтения — dmesg|tail и смотрим, в каком физическом секторе произошел сбой).
hdparm позволяет переписать этот сектор и заново проверить его (и окружающие сектора) более пристально.
scrounge-ntfs — прекрасная утилита, умеющая выдирать файлы из образов дисков c NTFS. К сожалению, в 32-битном Debian она собрана неправильно (без -D_FILE_OFFSET_BITS=64), в результате чего практически неюзабельна. Приходится вытягивать исходники и собирать с нужными флагами.
Badblocks, к сожалению, при большом количестве бэдов может работать неделями, так что я ее пощупал и отказался от нее.
Джентльменский набор — это smartctl, dd, scrounge-ntfs и hdparm.
smartctl позволяет проконтролировать количество бэдов.
dd позволяет сдампить образ диска для последующего выдирания с него файлов (если указать параметр conv=noerror). Также dd позволяет быстро найти сбойный сектор на диске (читаем все подряд блоками по 4 кб, при сбое чтения — dmesg|tail и смотрим, в каком физическом секторе произошел сбой).
hdparm позволяет переписать этот сектор и заново проверить его (и окружающие сектора) более пристально.
scrounge-ntfs — прекрасная утилита, умеющая выдирать файлы из образов дисков c NTFS. К сожалению, в 32-битном Debian она собрана неправильно (без -D_FILE_OFFSET_BITS=64), в результате чего практически неюзабельна. Приходится вытягивать исходники и собирать с нужными флагами.
Badblocks, к сожалению, при большом количестве бэдов может работать неделями, так что я ее пощупал и отказался от нее.
Отлично, благодарю за направление. Будет очень интересно попробовать покурить скрипты. По тому что нагуглил возник вопрос — в чем преимущество dd перед GNU ddrescue?
Преимущество только одно — dd есть в любом дистрибутиве, а ddrescue надо ставить.
Ну и, если честно, возможности ddrescue мне показались излишними: какие стратегии чтения, какие карты? Задача была — прочитать образ диска «в лоб», а если что-то прочитать не удалось — забитьболт непрочитанное место в образе нулями. С этой задачей dd справляется неплохо.
Ну и, если честно, возможности ddrescue мне показались излишними: какие стратегии чтения, какие карты? Задача была — прочитать образ диска «в лоб», а если что-то прочитать не удалось — забить
ddrescue отличается одной значительной возможностью — он предназначен для восстановления данных. Он не пытается читать один и тот же блок до посинения — не запиливает диск. Не смог что-то прочитать — пропустил и побежал дальше. Потом вернётся, когда всё легко читаемое будет прочитано — это максимизирует количество информации, которая будет спасена. Ну и бонусом есть ещё опции. Например, если диск зависает при чтении определенной области — можно продолжить чтение в тот же образ с конца диска, например.
Мой комментарий неактуален.
Если не принципиальен линукс — есть отличная софтина r.saver под вынду. Весьма удобная для выдирания файла с дохлого винта, умеет нтфс и(вроде) даже какую-то маковскую фс. Правда есть нюанс — современная версия не работает с образами. Надо искать старую, которой это не отключили.
Хм. А чем она кроме сигнатурного поиска отличается? R-Saver халявная, а сигнатурный не всегда нужен.
UPD: ну и наличия нативной версии под линух :)
UPD: ну и наличия нативной версии под линух :)
Ну, эм… Тем что, например, R-Studio это промышленное (доказано опытом) решение для восстановления файлов. Из коробки есть куча функциональности: и работа с образами, и сигнатурный поиск, и поддержка многих (но, к сожалению, не всех) файловых систем…
И еще — я R-Studio и под линукс запускал через wine, если уж совсем надо было.
И еще — я R-Studio и под линукс запускал через wine, если уж совсем надо было.
Так r-saver вроде тоже не абы кем написан. У них там даже какой-то программно-аппаратный комплекс есть для совсем запущенных случаев.
И еще — я R-Studio и под линукс запускал через wine, если уж совсем надо было.Зачем? Так у них на сайте указана версия для линуха (и даже мака). Или это за отдельную плату? Кстати через вайн и r-saver, наверно, можно запустить, если не работать напрямую с диском.
В сейвере есть сигнатурный поиск, по умолчанию включен. Причём он не сплошной, а «умный», ищет только в секторах, не отнесённых уже к каким-либо файлам на основе найденных метаданных ФС.
Сейвер со студией сравнивать не совсем корректно. Это решение для быстрого и качественного восстановления «здесь и сейчас». Нужно восстановить — скачал бесплатно, запустил визард и восстановил. Без залезания в дебри.
Если уж сравнивать с R-Studio — то UFS Explorer Pro, они уже из одной категории.
Сейвер со студией сравнивать не совсем корректно. Это решение для быстрого и качественного восстановления «здесь и сейчас». Нужно восстановить — скачал бесплатно, запустил визард и восстановил. Без залезания в дебри.
Если уж сравнивать с R-Studio — то UFS Explorer Pro, они уже из одной категории.
Какая-нибудь тщательно проверяющая диск файловая система типа ZFS и ее встроенный RAID-Z на нескольких дисках дают куда как большую надежность.
Читаешь такой «что делать с HDD с бэдами со студенческих времен?», и такой «waaaat?» А потом читаешь 4ТБ, и такой «а, ну да, я старый пердун...» мои HDD со студенческих времен – 256MB )))
Да ладно вам…
«4ТБ со студенческих времен» — это и для современных студентов довольно круто
мои HDD со студенческих времен – 256MB )))
Какой то размер странный.
SSD что ли?
были и на 5МБ, большие, шумные и так сказать не очень быстрые. Однокурсник в autoexec.bat прописал строчку из песни «Ой мороз, мороз!», потому что и в самом деле можно было спеть минимум пару куплетов пока все загрузится и нортон командер покажет синие панельки.
Согласен, какой то странный обьем. 40Мб были, 80Мб помню, даже 100 и 120 Мб стояли у нас в 486-тых. А потом как то сразу Гиг на К6-том. А таких странных обьемов не помню.
40Мб были, 80Мб помню, даже 100 и 120 Мб стояли у нас
5, 10, 20 (ST-225), 40 (Western Digital 93044A), 140 ( Caviar AC140), 340 (Conner CFA 340A), 840 (Caviar AC2850) — из того, с чем непосредственно работал.
Полагаю автор комментария имел ввиду приближённое значение. Хабр не умеет в метафоры и сравнения, увы.
мои HDD со студенческих времен – 256MB )))
...20 МБ, MFM (Seagate ST-225)
Невнимательно читали. Во время студенчества старые диски не доживали до смерти, а менялись на более емкие. По сути умер у меня только один винт WD на 40GB. Проблемы с бэдами полезли только при покупке емких винтов и отпадения надобности в таких больших объемах. Бэдами покрылись уже 5 винтов: 1,5, 2, 3, 4, 4 TB. Все лежат на полочке пустые. Вот и захотелось их использовать под что-то не очень нужное (игры, например).
мои давно померли))
а в компе щаз 1тб и 750.
а в компе щаз 1тб и 750.
Ого, какая роскошь. У меня только пачка по 1,44МиБ сохранилась.
Используем старые HDD с бэдами
1. Для начала, возьмём отвёртку…
Был винчестер в руках, когда он ко мне попал, то Reallocated sector count было в районе 5000. Пока спасал с него информацию стало в районе 70000. Мне его отдали, он долго валялся, потом понадобился в качестве временного пристанища для Ubuntu. И количество бэдов больше не росло. Был под наблюдением около года, я его потом еще знакомому айтишнику за 500 р. продал, честно предупредил, что он сыпался, но перестал.
Интересно, а есть какое-нить Open source решение, которое на куче глючных винтов может построить надежное хранилище (в дублированием, контролем целостности и пр)?
Лучше некрофилией не заниматься.
Нет. Беды вылезают тогда, когда кончился резерв секторов (это сотни или даже тысячи секторов). Пока резерв есть — каждый диск чинит сам себя, и обычный рейд на них работает прозрачно. Когда диск не может уже сам себя чинить — то его лучше выбросить. Я пробовал продолжить их использовать, в течении месяца высыпались полностью. При этом таймауты при обращениях к таким секторам происходит на уровне САТА контроллера, т.е. даже не на уровне ОС. А значит возможные подвисания и лаги, вы ни как не можете контролировать. Т.е. просто присутствие такого винта в системе дает лаги даже в ходе загрузки биоса. Такой пк будет работать очень плохо. А ради чего?
Нет. Беды вылезают тогда, когда кончился резерв секторов (это сотни или даже тысячи секторов). Пока резерв есть — каждый диск чинит сам себя, и обычный рейд на них работает прозрачно.
В теории все так.
На практике нечитаемый сектор далеко не сразу подменяется резервным. Какое-то время он болтается в pending reallocated sectors. А уж когда там его контроллер соблаговолит переназначить, зависит от многих факторов. У меня в экспериментах такие вот «недопереназначенные» сектора висели по полгода (и что характерно — все это время не читались). Лучший способ заставить контроллер переназначить такой сектор — это попытаться что-нибудь туда записать напрямую. Есть, конечно, и специальные команды для этого, но они вендор-специфик.
Или дохнет головка.
Raid 5 + 0
Лучше всего диск с бэд блоками подходит для точилки
Похвально! но перед изысканиями — полезно ознакомится с существующими решениями.
А то будет как с Остапом Бэндером.
«Всю ночь! соченял —
Я помню чудное мгновенье, передомной явилась Ты!...»
и только на утро вспомнил, что все это написал до меня А. эС. — Пушкин!
А то будет как с Остапом Бэндером.
«Всю ночь! соченял —
Я помню чудное мгновенье, передомной явилась Ты!...»
и только на утро вспомнил, что все это написал до меня А. эС. — Пушкин!
Пользуясь случаем, задам два вопроса знатокам.
1. Чисто теоретически (на практике точно не удастся проверить, железо не позволит). Имеем, например, диск с долгочитаемыми и бэдами, равномерно расположенными по всему объёму. Если переформатировать его, скажем, с 300 дорожек (ну или сколько их там бывает) на 100 дорожек- мы получим вечный диск меньшего объёма?
2. Со старыми дисками (не более 20 Гб) несколько раз встречал картину, когда диск просто усыпан «красными» секторами. И становился совершенно нормальным после обычного полного форматирования. То есть до этого, в моём понимании, информация была просто «размагничена» от времени, по аналогии с магнитной лентой. Может ли такое быть? Подтверждения никогда нигде не встречал, везде утверждается, что информация хранится «вечно».
1. Чисто теоретически (на практике точно не удастся проверить, железо не позволит). Имеем, например, диск с долгочитаемыми и бэдами, равномерно расположенными по всему объёму. Если переформатировать его, скажем, с 300 дорожек (ну или сколько их там бывает) на 100 дорожек- мы получим вечный диск меньшего объёма?
2. Со старыми дисками (не более 20 Гб) несколько раз встречал картину, когда диск просто усыпан «красными» секторами. И становился совершенно нормальным после обычного полного форматирования. То есть до этого, в моём понимании, информация была просто «размагничена» от времени, по аналогии с магнитной лентой. Может ли такое быть? Подтверждения никогда нигде не встречал, везде утверждается, что информация хранится «вечно».
1. Нет. Если начал сыпаться настолько, что целые дорожки пришлось отключать — это вопрос времени, причём скорее небольшого. Вообще, раз уж вы подняли вопрос про «чисто теоретически» — любые новые бэды это с наибольшей вероятностью одно из двух:
Да и вообще, HDD по сути своей, будучи механическим устройством не могут быть вечными.
2. Такое может быть, да. Насколько я понимаю, заряд на ячейке при работе периодически обновляется, однако это происходит только при попытках записи-чтения (перезапись, дефрагментация, проверка на бэд-блоки, etc). В любом случае «вечно» информация не хранится — ячейка может размагнититься и это факт.
- Загрязнения во внутреннем объёме а учитывая, что фильтры в HHD не идеальны, да и атмосфера тоже оставляет желать лучшего, «чисто теоретически» — он рано или поздно выйдет из строя.
- Размагничивания сектора. Если поверхность начала размагничиваться, значит жить ей осталось тоже недолго.
Да и вообще, HDD по сути своей, будучи механическим устройством не могут быть вечными.
2. Такое может быть, да. Насколько я понимаю, заряд на ячейке при работе периодически обновляется, однако это происходит только при попытках записи-чтения (перезапись, дефрагментация, проверка на бэд-блоки, etc). В любом случае «вечно» информация не хранится — ячейка может размагнититься и это факт.
После долгих исследований пришёл к подобному костылю. Для начала надо пройтись Victoria HDD из под DOS (именно из под DOS, не под Windows. Понятия не имею какие). Режим advanced remap+butterfly. Ставим диск и ждём. Если всё завершилось хорошо, ок. Если всё плохо, возможно нужно два прохода на один диск. В среднем это занимает чуть меньше недели чистого времени. После того как этот тест прошёл. Запускаем linux и там используем это
Ждём ещё долгое время. Получаем список всех бэдблоков по их номерам. После этого создаём файловую систему в обход этих бэдблоков примерно так.
Большинство дисков после подобной операции уже можно будет запустить в работу. Диски которые зависают и не способны получить полноценный список бэдблоков подобным способом не оживают. Диски у которых более 50% поверхности бито бэдами восстанавливать не выгодно. Их будет больше, не поможет.
#!/usr/bin/env bash
Path="/dev/sdl"
# cat /sys/block/sdl/queue/physical_block_size # узнать размер блока вручную.
badblocks -v -s -w -t 0x00 -b 4096 ${Path} \
-o /home/oz/badblocks_Z1F2DBSG.txtЖдём ещё долгое время. Получаем список всех бэдблоков по их номерам. После этого создаём файловую систему в обход этих бэдблоков примерно так.
mkfs.ext4 -v -l /home/oz/badblocks_Z1F2DBSG.txt -b 4096Большинство дисков после подобной операции уже можно будет запустить в работу. Диски которые зависают и не способны получить полноценный список бэдблоков подобным способом не оживают. Диски у которых более 50% поверхности бито бэдами восстанавливать не выгодно. Их будет больше, не поможет.
(именно из под DOS, не под Windows. Понятия не имею какие)
Дурацкая опечатка которую невозможно отредактировать. * Понятия не имею какие слои абстракции накладывает операционная система для дисков. Они есть и уже много раз замечал, виктория из под windows полноценно не отрабатывает и не помогает. Виктория же из под DOS работает идеально. К сожалению альтернатив ей не существует, как и исходного кода к ней… Потрясающий софт. Версия 3.52.
Зря вы их в мусор выкидываете. Бывает у людей горит плата электроники, и чтоб достать данные нужна другая плата на запчасти. Лучше продавайте или дарите через сайты обьявлений. Там еще мотор и магниты могут пригодится самодельщикам.
4 ТБ Б\У на авито стоят примерно 4к рублей, это рабочие. Цена давно не меняется 1к рублей = 1 тб. С серьёзными повреждениями можно в живых сохранить терабайта 3. В простенькой дисковой полке аля DELL MD1000 на 15 дисков влезет 45 терабайтов. Ещё одна такая же полка идёт на резерв и в тот же рейд. Итого 30 дисков. Пусть наглухо убитых. Но ещё живых и способных ещё прожить, возможно год или более и в подобных условиях обеспечить более чем надёжное хранение. А это уже лишние тысяч 90 рублей экономии. И вот уже когда они действительно умрут ещё один раз и на них будет невозможно составить карту бэдблоков, тогда уже дербанятся на магнитики и платы… К сожалению я не настолько богат, чтобы позволить себе подобное расточительство… выкидывать…
Ого. Локальную копию интернета хотите сделать? :-)
А если серьезно — раньше тоже занимался накопительством. Но пару лет назад пересмотрел взгляды. Сейчас только SSD на 384ГБ и те на 2/3 пустые и нисколько не страдаю да и чистку уже очень давно не делал. Так что хлама тоже присутствует порядком всякого.
А если серьезно — раньше тоже занимался накопительством. Но пару лет назад пересмотрел взгляды. Сейчас только SSD на 384ГБ и те на 2/3 пустые и нисколько не страдаю да и чистку уже очень давно не делал. Так что хлама тоже присутствует порядком всякого.
WD Red 8Tb $250
У нас такие по 295, не так давно были по 320. Где сейчас такие вкусные цены?
И просто интересно, что у вас на 45 Тб лежит?
Практика показывает, что при наличии технической возможности — подобные объемы забиваются достаточно быстро )
Кстати, по 4,5 Тб новых файлов в год — это не так уж и много.
Амазон
В смысле — HDD через Амазон?
А как с гарантией в таком случае?
Мой текущий поставщик меняет HDD по гарантии в течении одной рабочей недели (отвез в понедельник — экспертиза — максимум в пятницу поехал, забрал новый со склада. При этом еще и спрашивает — надо ли восстанавливать данные).
Поделитесь статистикой, что у Вас там столько места занимает плз.
Что бы поделиться статистикой — надо ее собрать.
А так — 30 терабайт, скопившиеся с 2000 года. Скапливалось неравномерно, конечно, но в среднем — 1,5...2 терабайта в год.
Кстати, именно поэтому большинство моих хардов имеет емкость в 2 и 3 терабайта — новые покупались по факту заполнению старых.
Зачем плюсуете вредную/бесполезную статью?
Я лично с софт-бедами борюсь куда проще, сначала всю важную инфу перекатываем на свеженький винт, а потом делаем старому `dd if=/dev/zero of=/dev/sdX bs=1M`, переразмечаем и наслаждаемся новой помойкой для торрентов :-)
Какие-то всем идеальные харды попадаются, которые сами ремапят беды.
У есть несколько хардов Seagate и WD у которых всего несколько нестабильных секторов(появились в результате удара по диску во время работы, видимо), при чтении из которых хард возвращает ошибку в ОС, при этом заносить их в отремапленные он наотрез отказывается и викторией и вообще чем угодно. Полную перезапись и нулями и рандомными данными делал, эффекта нет. Вот просто есть всего несколько секторов, чтение из которых заставляет хард призадуматься и вернуть UNCR.
chkdsk прекрасная утилитка, которая помечает их как сдохшие и Windows перестаёт их использовать, но есть проблема: рядом с ними ещё 1-2 сектора, которые читаются, но с ощутимой задержкой в секунд 10 — харды их ремапить не хотят тоже.
Трюк автора хорош, но не технологичен, как уже сказали, правильным решением было бы читать диск в режиме прямого доступа и добавлять такие сектора, а также несколько соседних в специальный файл $BadClus, но таких тулз я не встречал в жизни, а написать самому — руки не доходят.
Зато в линуксе редактировать список проблемных секторов в той же ext4 — легче лёгкого, снял список секторов с помощью badblocks, расширил его в обе стороны на пару мегабайт и mkfs.ext4 — диски успешно работают уже долго без ошибок.
У есть несколько хардов Seagate и WD у которых всего несколько нестабильных секторов(появились в результате удара по диску во время работы, видимо), при чтении из которых хард возвращает ошибку в ОС, при этом заносить их в отремапленные он наотрез отказывается и викторией и вообще чем угодно. Полную перезапись и нулями и рандомными данными делал, эффекта нет. Вот просто есть всего несколько секторов, чтение из которых заставляет хард призадуматься и вернуть UNCR.
chkdsk прекрасная утилитка, которая помечает их как сдохшие и Windows перестаёт их использовать, но есть проблема: рядом с ними ещё 1-2 сектора, которые читаются, но с ощутимой задержкой в секунд 10 — харды их ремапить не хотят тоже.
Трюк автора хорош, но не технологичен, как уже сказали, правильным решением было бы читать диск в режиме прямого доступа и добавлять такие сектора, а также несколько соседних в специальный файл $BadClus, но таких тулз я не встречал в жизни, а написать самому — руки не доходят.
Зато в линуксе редактировать список проблемных секторов в той же ext4 — легче лёгкого, снял список секторов с помощью badblocks, расширил его в обе стороны на пару мегабайт и mkfs.ext4 — диски успешно работают уже долго без ошибок.
Если не ремапятся, может, ремапить некуда уже?
У есть несколько хардов Seagate и WD у которых всего несколько нестабильных секторов(появились в результате удара по диску во время работы, видимо), при чтении из которых хард возвращает ошибку в ОС, при этом заносить их в отремапленные он наотрез отказывается и викторией и вообще чем угодно. Полную перезапись и нулями и рандомными данными делал, эффекта нет. Вот просто есть всего несколько секторов, чтение из которых заставляет хард призадуматься и вернуть UNCR.После удара по диску может быть вообще всё, что угодно.
Диск из ноутбука, ударили ноутбук во время работы.
Такие ситуации вроде бы сплошь и рядом, просто чуть не повезло и головка зацепила поверхность.
После удара по диску может быть вообще всё, что угодно
Лежит у меня на полочке ноутбучный диск после автоаварии. При чтении смарта примерно каждые три секунды замирает и через пару секунд оживает снова. Соответственно на смарте куча красных секторов, но они не привязаны к адресам, то есть при следующем чтении будут в других местах. Количество не растёт. Информацию можно записывать и считывать без ошибок, но тоже с паузами каждые три секунды (соответственно видео не воспроизвести). Получилась флешка для хранения на 320 Гб.
Подозреваю, что проблема в электронике, но донора для проверки нет.
HDAT2 если не заремапит, то перевести контроллер SATA в IDE и еще раз HDAT2. Часто помогает.
sibvic… sibvic… sibvic…
Дружище, сабы к Initial-D не твоих рук дело?)
Дружище, сабы к Initial-D не твоих рук дело?)
Такой способ имеет право на существование только как крайняя мера перед тем как выбросить веник и после:
1. Ремапа битых секторов смартом
2. На что запаса не хватило — отрезать разделом, лучше с каким-то левым типом файловой системы
3. Пометить остаток програмно чекдисками
Только не плохо бы создаваемые файлы с бедами делать системными и r/o — - тогда их никто дефрагментировать не будет.
P.S. — самовосстанавливающие коды применять бессмысленно так как в самом винчестере они уже реализованы, а бед — это уже когда совсем не вышло восстановить. Конечно немного полегчает, но масло масляное получится.
1. Ремапа битых секторов смартом
2. На что запаса не хватило — отрезать разделом, лучше с каким-то левым типом файловой системы
3. Пометить остаток програмно чекдисками
Только не плохо бы создаваемые файлы с бедами делать системными и r/o — - тогда их никто дефрагментировать не будет.
P.S. — самовосстанавливающие коды применять бессмысленно так как в самом винчестере они уже реализованы, а бед — это уже когда совсем не вышло восстановить. Конечно немного полегчает, но масло масляное получится.
файл оставляем на этом бэде чтобы ничего больше на него не писалось.
ага. И любая дефрагментация — файл переезжает на новое место, а на место бэд-сектора — другой файл. Винт тупит. И в результате ошибки чтения/записи. ОК. Может не дефрагментация. Может у Вас очень умная файловая система (типа zfs, btrfs) и она вообще не гарантирует постоянство физических адресов секторов, в которых расположены файлы.
Надо понимать, что единственный надежный способ не дать операционной системе что-либо записать в бед-сектора — это не создавать поверх этих блоков файловую систему. Т.е. таблица разметки будет выглядеть так:
[MBR][раздел 1][раздел 2][блок с бэдами][раздел 3]
Далее если необходимо, то можно все разделы объединить в единое логическое пространство (напр., LVM в Linux).
Какова может быть природа софт-бэдов, если они появляются массово, и что можно сделать?
Тут просто лежит ST2000DL003 почти неюзаный, выбросить жалко. Выскакивают Pending Sectors в области размером с 200 Гб, я их перезаписываю — исчезают сразу, без релоков. Немножко полежит — и уже другие файлы не читаются (а вчера читались). Плюнул, отрезал эти 200 Гб, некоторое время пользовался, но потом зона расширилась… Занулял через security erase — не помогает…
Тут просто лежит ST2000DL003 почти неюзаный, выбросить жалко. Выскакивают Pending Sectors в области размером с 200 Гб, я их перезаписываю — исчезают сразу, без релоков. Немножко полежит — и уже другие файлы не читаются (а вчера читались). Плюнул, отрезал эти 200 Гб, некоторое время пользовался, но потом зона расширилась… Занулял через security erase — не помогает…
Сразу, как прочитал статью — в голову пришла мысль об автоматической дефрагментации. А еще если свет выключат и чекдиск запустится после ребута?
Всё ж как хорошо в линуксе — тупо запустил mkfs с параметром -c и всё…
Пустая трата времени, если на диске есть области с «плавающими» дефектами (когда сектора в определенной области то читаются, то нет). Мало того, что на проверку времени уйдет масса, так еще и часть секторов из нестабильных областей заюзается — со всеми вытекающими.
Это уже другой вопрос, так как согласен, что использовать относительно современные винты с бедами нет смысла.
Но вот то, что под винды надо писать подобный софт, так как штатный уже не позволяет (действительно не позволяет или автор не умеет в документацию?) — показатель.
Но вот то, что под винды надо писать подобный софт, так как штатный уже не позволяет (действительно не позволяет или автор не умеет в документацию?) — показатель.
Штатный позволяет. Chkdsk умеет искать бэды и помечать их на файловой системе, чтоб не использовались. Это, конечно, не совсем то, что mkfs -c, но близко.
Только толку от этого нет — он не берёт соседние сектора, которые читаются, но с ощутимой задержкой в секунды — таким диском всё равно пользоваться не получится полноценно.
Ну тогда это показатель грамотности автора описанного в топике :-)
Я, как легковерный человек, почему-то решил, что из винды подобное уже выпилили, хотя ещё в WinXP можно было поставить галочку при форматировании, чтобы поверхность проверилась.
Я, как легковерный человек, почему-то решил, что из винды подобное уже выпилили, хотя ещё в WinXP можно было поставить галочку при форматировании, чтобы поверхность проверилась.
Был винт с бэдами исключительно в пределах первых 40 Гб. Создал в этой части раздел, после нее еще один. Да — 40 Гб потерял, но зато уже несколько лет винт работает, но на 40 Гб меньше.
Идея очень классная, у самого лежат несколько винтов, совершенно не пригодных для постоянного использования, но идеально подходящих для хранения помойки. Chkdsk для них не пригоден, на одном из винтов, к примеру, был бэд вешающий винт. Находил его с помощью mp3шек, а потом в diskedit находил плохие сектора и помечал вручную.
Однако я не программист, и не понимаю что с этими исходниками делать. Найденный exeшник требует x64, которой у меня нет ни на одной машине. А если оно и под DOSом будет работать, и под WinXP…
И еще вопрос — файлы помечены как не перемещаемые?
Однако я не программист, и не понимаю что с этими исходниками делать. Найденный exeшник требует x64, которой у меня нет ни на одной машине. А если оно и под DOSом будет работать, и под WinXP…
И еще вопрос — файлы помечены как не перемещаемые?
Идея не классная, прочтите комментарии, там предложена куча адекватных вариантов, и не делайте как написано в статье. Ну или хотя бы самый популярный.
Чем для NTFS пометить сектора как bad?
Пометить вручную, а не тестировать!
Что бы брать номера тормознутых секторов из Victoria и помечать как сбойные.
Пометить вручную, а не тестировать!
Что бы брать номера тормознутых секторов из Victoria и помечать как сбойные.
«а что делать со старым? Как-то жалко выкидывать 4ТБ»
я только только купил 3Тб. А у вас уже 4 старый? Вы из будущего?
я только только купил 3Тб. А у вас уже 4 старый? Вы из будущего?
Отработали у меня 12 лет
По моим данным, 12 лет назад новыми были винты емкостью от 0,32 до 0,75 Тб.
(WD3200YS / WD7500AAKS)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Используем старые HDD с бэдами