Вот и возник вопрос, а что делать со старым? Как-то жалко выкидывать 4ТБ винт когда на нем всего с десяток бэдов. Причем в большинстве случаев их количество растет не быстро, и этот 4ТБ винт можно использовать для всякой ерунды ещё довольно долго. Встал вопрос, а как бы сделать так, чтобы данные на бэды не попадали. Большинство утилит пытаются эти сектора восстановить. Но при таком объеме напрашивается вопрос — зачем? Это процесс весьма долгий, а ± гигабайт на диске в 4ТБ особой роли не играет. Особенно когда накопилось несколько таких живых мертвецов. Немного погуглив способ быстрой маркировки бэдов наткнулся на несколько веток на форумах, где народ искал что-то похожее. Но нормального решения я так и не нашел.
Раз решения нет, значит будет. Немного подумав решил поступить самым простым способом — написать консольную утилитку забивающую винт файлами, а потом проверяющую эти файлы на чтение. Файл прочитался? Отлично, сектор под файлом целый, файлик удаляем. Не читается? Вот и нашли бэд блок, файл оставляем на этом бэде чтобы ничего больше на него не писалось.
Из минусов такого подхода — не проверяется место под уже имеющимися файлами, только свободное место на диске. Из плюсов — быстро и можно делать «порциями».
Всего есть 2 режима, полный, и режим чистки.
Полный режим забивает диск файлами, потом их проверят и удаляет. Для этого указываем диск и желаемый размер блока/файла.
BadBlocksPlaceholder [disk] [file_size_kb]
BadBlocksPlaceholder e:\ 4096Файлы создаются в папке BadBlockPlaceholders\yyyymmdd
Второй режим предназначен для продолжения проверки/чистки. Забить 4ТБ файлами и проверить их на чтение тоже не моментальный процесс, и иногда приходится разбивать его на пару дней. В этом режиме нужно указать папку с файлами-Placeholder'ами, созданными на первом этапе.
BadBlocksPlaceholder clean e:\BadBlockPlaceholders\20190110Естественно, после чистки оставляем BadBlockPlaceholders лежать на винте. Надеюсь кому-нибудь утилитка пригодится. Проверялся только happy-day сценарий, так что сильно не пугайтесь, и сильно не пинайте. Написано на .net core/C#.
Исходники лежат на github.
Комментарии (140)
zuborg
13.03.2019 18:50+5Просто обозначу минусы такого решения
1. Не проверяется (и остается под угрозой смерти) служебная зона файловой системы — MFT, директории…
2. Остается риск работы головки в поврежденном цилиндре, вызывая дальнейшую деградацию диска (расширяя задир, например).
Если уж так сильно охота использовать потенциально дохлый винт — правильно будет определить дефектную зону, покрыть её отдельным дисковым разделом с запасом в несколько десятков ГБ (минимум), который не форматировать и никак не трогать — тогда может быть винт и поживет какое-то время, если повезет.
sysd
13.03.2019 19:13+1А зачем нужно покрывать разделом, а почему бы не оставить просто неразмеченное пространство?
PS:Не проверяется (и остается под угрозой смерти) служебная зона файловой системы — MFT
mft еще и увеличиваться в размере будет
PSS: Еще один минус, если HDD подключен к Windows, нужно будет отключить дефрагментацию и, подозреваю, службу индексирования, чтоб избежать перемещения/чтения файла.zuborg
13.03.2019 19:22А зачем нужно покрывать разделом, а почему бы не оставить просто неразмеченное пространство?
Так проще было написать )
Разумеется, неразмеченное пространство даст точно такой же эффект.
LAutour
13.03.2019 19:26+2Еще лучше, когда используется чистая зона только до или после бэдовой, чтобы голова через нее не скакала (не считая вкл-выкл).
mistergrim
13.03.2019 19:12+7Логические бэды рассматривать вообще нет смысла. Есть либо реальные бэды (те, что в SMART под номером 05, Reallocated sector count), но они от хоста уже спрятаны в дефект-лист, либо софт-бэды, которые, в зависимости от их поведения, либо будут восстановлены, либо также проследуют в дефект-лист. Вывод: заниматься восстановлением всё же стоит, а автор занимается ерундой.
zuborg
13.03.2019 19:20+1Есть ещё 197 Current_Pending_Sector — сектора которые не получается прочитать (чек-сумма не сходится), но которые ещё не переназначены (а вдруг когда-то прочитается).
Их можно перезаписать поверху, после этого такой сектор может начать работать нормально (или будет переназначен, если ему кранты), а может и дальше заглючить в самый неподходящий момент.
DmSting
13.03.2019 21:27Подскажите пожалуйста, а как тогда быть в ситуации, когда количество бэдов не растет годами?
Есть WD Red, на котором 3 бэда вылезло примерно в первый год эксплуатации, и он с ними так и живёт уже почти 5 лет. На нём растет количество «подозрительных» сектором, но когда его форматируешь и заливаешь инфой по новой — они сбрасываются.mistergrim
13.03.2019 21:36+3С появившимися и не увеличивающимися бэдами — забить (особенно если их три штуки, для нынешних объёмов это ничто). Следует учитывать, что с завода диск и так приходит с несколькими сотнями или тысячами бэдов, только они находятся в т.н. P-List, этот список пользователю без сервисных утилит недоступен. Считайте, что эти три сектора — недовыявленные.
В постоянном появлении подозрительных секторов, особенно с учётом того, что это WD, 50/50 виновато окисление контактов на плате. Просто картинка:
DmSting
13.03.2019 21:51Про это я в курсе, когда пошли глюки при обращении к винту разобрал и
протер стёркой — сразу нормализовалось.mistergrim
13.03.2019 21:52Вот каждые полгода-год (в зависимости от условий эксплуатации) и придётся повторять. Это WD, ничего не поделать.
Ну или принимать какие-то меры (люди лудят, смазывают, я не пробовал).linux_id
13.03.2019 21:55Достаточно припаять
vladkorotnev
14.03.2019 03:58Чтобы потом точно ничего не прочитать? Припой окисляется на воздухе ещё быстрее, чем эта бодяга, которой площадки покрывают.
Или имеется в виду припаять прямо туда клеммную колодку гермоблока, насовсем? :-)konchok
14.03.2019 22:11Есть спец жидкости для очистки позолоченных контактов, оставляют защитную плёнку после себя. У DeoxIT например имеется.
caig.com/deoxit-gold-g-seriesmistergrim
15.03.2019 06:05Если бы контакты были позолоченные, проблемы бы и не было. Но производитель сэкономил на… сколько там? 0,0001 граммах?
Вообще, это реально выглядит, как злой умысел. На PCI-платах ведь всегда покрывали контакты золотом (палладием, чем там ещё) — даже на китайской дряни.konchok
15.03.2019 06:13Техническое золото никогда не было сверхчистым и покрывается налётом так или иначе
mistergrim
15.03.2019 06:15Между «так» или «иначе» большая разница. И между налётом и окислением тоже.
u010602
15.03.2019 06:36Тем не менее эти проблемы есть у всех контактных групп в ПК. Ластиком лечат и планки памяти и контроллеры и видеокарты. Чем оно там покрывается обычный человек узнать не может. Но то, что этот налет мешает работе — это факт.
ra3vdx
13.03.2019 23:34Офигеть! Почти сценарий "Идиократии". «Инженеры» с «дипломами» «успешно» работают не только в отдельно взятых странах.
Кстати, у нас была та же проблема с недорогими мобильными телефонами — не принимали сим-карты. Решение было похожее, но чуть жёстче. Там даже лак был не снят. Но партию, тем не менее, сертифицировали и запустили в продажу).
Будущее наступает быстрее, чем мы ожидали.
Tufed
14.03.2019 13:033,5" WD, Seagate, Toshiba — весь этот зоопарк имеет схожую проблему. Большинство начало так делать на винтах объема после 80гб. С 2.5" тоже самое, целая пачка ноутбучных тошиб лежит с такими же проблемами. Старые винты редко этим грешили 20-гиговые остались живы и имеют нормальные контактные площадки, даже не намека на окисление. Когда перебирал свои думал статью запилить с картинками, но как обычно лень победила.
toivo61
14.03.2019 16:40А с «Паспортами» такой трюк проходит?
mistergrim
14.03.2019 17:45Ну это надо снимать плату и смотреть. Далеко не на всех дисках такое, как раз на «паспортах» вроде нормально залужённые контакты. Но я этим занимался давно, утверждать не буду.
OZR
14.03.2019 07:03Это самая важная картинка в статье. Хотя бы раз в два-три года старые диски необходимо чистить ластиком. Чтобы они не сдохли раньше времени. Т.к именно это фото — наиболее частая причина преждевременной смерти диска.
zamboga
14.03.2019 12:46А для этого надо диск разбирать, верно?
И что с SSD, не скажете, они имеют ту же проблему? А то у меня есть один глючный, то месяцами норм работает, то каждый день материться начинает и файлы теряет.Kocmohabt314
14.03.2019 13:11Надо плату открутить от корпуса диска, она обычно держится на нескольких винтах с головкой типа torx. У SSD такой проблемы быть не должно, т.к. они состоит из одной только платы и контакты на ней есть только в интерфейсе подключения (например, SATA) и питания.
u010602
13.03.2019 19:29+19Есть такая утилита MHDD и ее наследник Victoria, делают то, что вы хотите, только корректно. А еще используются штатную систему ремапа, которая есть в каждом жестком диске. Суть — та-же что у вас, запомнить сбойные сектора, и назначить вместо них сектора из резерва. Резерв большой. Если резерв закончился и сектора не могут быть переназначены — значит диск сыпется и очень активно, умрет скоро и внезапно.
А теперь почему ваш метод работать не будет. Коротко — проблема в таймауте. Утилиты используют таймаут в 1с и не делают повторных обращений если он истек. А вот ваша утилита будет пробовать прочитать этот сектор ооочень долго. Если сбойных секторов 100 шт — то это не проблема. А вот если сбойный целый гигабайт — вы просто залипните на нем на всегда.
Более того, это увеличит износ механизма умирающего диска, и долбить он будет самую слабую зону. Что еще хуже. Есть такая штука — как запил дорожки, тогда выпадает много секторов подряд. И лучше тогда эту дорожку не трогать, нужно найти ее начало, и обрезать отдельным разделом с запасом с обоих сторон.
Еще один минус вашего метода — дефрагментация, она все сломает. Вернее она будет зависать, т.к. дефрагментатор попробует получить доступ к сектору и зависнет.
Еще один минус — система может решить проиндексировать файлы, или проверить их на вирусы, или просто-так их считать. И зависнет.
Итого: пользуйтесь штатными средствами. Сначала СМАРТ диагностикой и СМАРТ ремапом через Викторию. Если бедов мало но смарт не смог, то проверкой встроенной в винду с галочкой проверки секторов. Если много — вырезанием целыми разделами.
hssergey
13.03.2019 21:17Запил дорожки опасен еще и тем, что он может повредить головку. Что приведет к невозможности считать целую пластину, и если по несчастливой случайности это оказалась первая пластина со служебными данными — к выходу из строя сразу всего жесткого диска. Он просто перестанет определяться в системе и будет бесконечно пытаться инициализироваться…
Кстати, не понимаю, почему производители жестких дисках в своих прошивках не предусмотрели таймаута. Ведь если сектор не считался за секунду, то дальше его пытаться считывать бессмысленно…JerleShannara
13.03.2019 23:26Если брать винты «RAID Edition», то там оно штатно очень быстрое (WD сами писали, что их серия RE не пытается по секунде прочитать сектор — не прочитался — отрапортовать как битый).
u010602
14.03.2019 01:09+1Таймаут есть, но он большой, как раз потому, что домашние диски редко в рейде, а значит с них намного важнее скачать таки файл, чем корректность работы в состоянии отказа.
В дисках рассчитанных на работу в рейде таймаут намного короче, потому-что они обычно в рейде. И чем раньше контроллер поймет что сектор умер, тем раньше возьмет резервную копию.
Насчет того, что шанс не считать сектор с Н попытки равны нулю, вы не правы. На считывание сектора влияет точность позиционирования головки, может оказаться что с Н попытки повезет таки стать немного не так и считать.
lll000lll
14.03.2019 16:30MHDD и Victoria а также HDDScan думается всё-таки «одногодки» чем кто-то чей-то наследник. И хотя появились немного в разное время, идеологически относятся к одному поколению.
А так да — сплошная запись всей поляны с последующей проверкой, и если жесткий диск ещё на что-то годен, бэды он должен скрыть. И если повезёт, дальше будет работать нормально. Но для современных моделей, остановка деградации поверхности — редкость.
develop7
14.03.2019 19:23И лучше тогда эту дорожку не трогать, нужно найти ее начало, и обрезать отдельным разделом с запасом с обоих сторон.
у whdd есть как раз такая стратегия детекта бэдов
abmanimenja
13.03.2019 20:08+2Ещё со студенческих времен у меня стояла куча жестких дисков
Да, десятки дисков тоже были.
И даже исправные…
Подумал, посчитал и выкинул.
Ибо те размеры сейчас…
Нужен BigTower, чтобы получить какой-то смешной объем 700Г с этих десятков дисков.
Да «корпус-мать-блок питания-контроллер дополнительный-прочее» обойдутся дороже, чем купить новый современный диск в разы больше.
Как-то жалко выкидывать 4ТБ винт когда на нем всего с десяток бэдов. Причем в большинстве случаев их количество растет не быстро
А это очень даже непредсказуемо, к сожалению.
Miller777
14.03.2019 00:53+1А у меня лежит куча клиентских с бэдами + USB-адаптер для их подключения. Работать на них уже нельзя, храню то, что не жалко потерять: сериалы, фильмы, музыку. Меньше места, чем DVD занимают.
xaoc80
14.03.2019 15:15Подумал, посчитал и выкинул
Я из старых дисков еще неодимовые магниты вытаскивал. Они очень мощные, правда в быту почти бесполезны. Но как-то рука не поднялась их выкинуть.DrunkBear
14.03.2019 17:12Они прекрасно справляются с людским любопытством: кладёшь магнит у таблички «не пытайся разъединить, особенно с помощью ногтей и пальцев» и с любопытством наблюдаешь, сколько людей умеют читать и осознавать прочитанное.
xaoc80
14.03.2019 21:22+2На хабре не принято спрашивать за что минус) Но вот просто интересно, разбор старого жесткого диска с целью извлечения магнитов это какой-то харассмент?)
JerleShannara
15.03.2019 02:06Подарите их в ближайший гаражный(самого низкого уровня) сервис, который сваркой и жестянкой занимаются — они вам спасибо скажут.
abmanimenja
13.03.2019 20:10Раз решения нет, значит будет. Немного подумав решил поступить самым простым способом — написать консольную утилитку забивающую винт файлами, а потом проверяющую эти файлы на чтение. Файл прочитался? Отлично, сектор под файлом целый, файлик удаляем. Не читается? Вот и нашли бэд блок, файл оставляем на этом бэде чтобы ничего больше на него не писалось.
Как это нет?
Это делает сама файловая система, это делает и firmware диска.
Все делается автоматически.
А ваш вариант несерьезны.
Ибо автоматика оптимизации-дефрагментации в современных файловых системах запросто эти ваши «спец. файлы» переместит куда ей надо, а не куда вам надо.
И пока она будет это делать — файлы-то с бэдами — вся работа с диском будет в лучшем случае тормозить дико. А то и вообще дисковые операции подвиснут (скорее всего так и будет)
Большинство утилит пытаются эти сектора восстановить.
Штатная утилита операционной системы — эти сектора долго-тщательно проверяет и заносит в BAD block list файловой системы.
berez
13.03.2019 20:11+2О, некромантия над битыми дисками — это моё, это я люблю. :)
Но ваше решение, как уже справедливо заметил sysd, не очень: винда может вдруг решить, что файлы на диске слишком фрагментированы, и перенесет заглушки в другое место.
Что касается бэдов. Если они появляются в малом количестве и редко, то лучший способ — заставить контроллер диска подменить их. Я лично использую для этого пару скриптов и утилиту hdparm под линуксом (конкретно — команды --read-sector и --repair-sector). Причина проста: посекторная проверка большого диска может занять пару суток. Под линуксом у меня круглосуточно крутится NAS, а виндовую машину приходится выключать на ночь, так что выбор платформы очевиден.
Если битых секторов становится слишком много и подменять их становится нечем, или если битые сектора появляются слишком часто, то проще такой диск разобрать на магнитики.
Впрочем, если хочется помучиться, то можно попытаться использовать помехоустойчивое кодирование (тот же код Рида-Соломона). Тогда можно подобрать параметры кодирования таким образом, что файл(ы) можно будет восстановить даже после выпадения нескольких подряд идущих секторов. Правда, придется заморочиться со специальными утилитами для кодирования-декодирования файлов на ненадежном диске. А в идеале — вообще наваять помехоустойчивую файловую систему. :)
Bonio
13.03.2019 20:54>помехоустойчивое кодирование (тот же код Рида-Соломона)
Есть файловые системы с контролем целостности, а с избыточностью, насколько я знаю, нету.
Как вариант можно попробовать RaidZ массив на ZFS, он, вроде, может обнаруживать поврежденные участки и заменять их неповрежденными с соседних дисков.
sysd
13.03.2019 21:06Мощная утилита, впечатен. Может поделитесь скриптами hdparm или посоветуете еще что то под linux для решения проблем с бэдами (тоже люблю некромантию), кроме достаточно быстро нагуглившихся smartctl и badblocks. Моя любимая — HDD Regenerator, но грузится из под DOS, что достаточно неудобно при современных объемах.
berez
13.03.2019 22:02Скрипты, наверное, выложу на гитхаб попозже — сейчас я от них далеко. :)
Джентльменский набор — это 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, к сожалению, при большом количестве бэдов может работать неделями, так что я ее пощупал и отказался от нее.sysd
13.03.2019 23:36Отлично, благодарю за направление. Будет очень интересно попробовать покурить скрипты. По тому что нагуглил возник вопрос — в чем преимущество dd перед GNU ddrescue?
berez
14.03.2019 10:25Преимущество только одно — dd есть в любом дистрибутиве, а ddrescue надо ставить.
Ну и, если честно, возможности ddrescue мне показались излишними: какие стратегии чтения, какие карты? Задача была — прочитать образ диска «в лоб», а если что-то прочитать не удалось — забитьболтнепрочитанное место в образе нулями. С этой задачей dd справляется неплохо.DaemonGloom
14.03.2019 10:46ddrescue отличается одной значительной возможностью — он предназначен для восстановления данных. Он не пытается читать один и тот же блок до посинения — не запиливает диск. Не смог что-то прочитать — пропустил и побежал дальше. Потом вернётся, когда всё легко читаемое будет прочитано — это максимизирует количество информации, которая будет спасена. Ну и бонусом есть ещё опции. Например, если диск зависает при чтении определенной области — можно продолжить чтение в тот же образ с конца диска, например.
berez
14.03.2019 12:43Ну, dd с опцией conv=noerror тоже не запиливает диск. Для моих целей (слить по-быстрому образ диска, игноря ошибки) dd вполне подходит. Понадобится что-то более сложное — тогда и буду использовать что-то более сложное. :)
DrZlodberg
14.03.2019 09:22Если не принципиальен линукс — есть отличная софтина r.saver под вынду. Весьма удобная для выдирания файла с дохлого винта, умеет нтфс и(вроде) даже какую-то маковскую фс. Правда есть нюанс — современная версия не работает с образами. Надо искать старую, которой это не отключили.
gecube
14.03.2019 09:24DrZlodberg
14.03.2019 09:49Хм. А чем она кроме сигнатурного поиска отличается? R-Saver халявная, а сигнатурный не всегда нужен.
UPD: ну и наличия нативной версии под линух :)gecube
14.03.2019 09:54Ну, эм… Тем что, например, R-Studio это промышленное (доказано опытом) решение для восстановления файлов. Из коробки есть куча функциональности: и работа с образами, и сигнатурный поиск, и поддержка многих (но, к сожалению, не всех) файловых систем…
И еще — я R-Studio и под линукс запускал через wine, если уж совсем надо было.DrZlodberg
14.03.2019 10:18Так r-saver вроде тоже не абы кем написан. У них там даже какой-то программно-аппаратный комплекс есть для совсем запущенных случаев.
И еще — я R-Studio и под линукс запускал через wine, если уж совсем надо было.
Зачем? Так у них на сайте указана версия для линуха (и даже мака). Или это за отдельную плату? Кстати через вайн и r-saver, наверно, можно запустить, если не работать напрямую с диском.
lll000lll
14.03.2019 16:11В сейвере есть сигнатурный поиск, по умолчанию включен. Причём он не сплошной, а «умный», ищет только в секторах, не отнесённых уже к каким-либо файлам на основе найденных метаданных ФС.
Сейвер со студией сравнивать не совсем корректно. Это решение для быстрого и качественного восстановления «здесь и сейчас». Нужно восстановить — скачал бесплатно, запустил визард и восстановил. Без залезания в дебри.
Если уж сравнивать с R-Studio — то UFS Explorer Pro, они уже из одной категории.DrZlodberg
15.03.2019 09:02Может в новом? Сейчас специально посмотрел — в старом, который с образами работать умеет, даже настроек никаких нет.
abmanimenja
13.03.2019 20:13Какая-нибудь тщательно проверяющая диск файловая система типа ZFS и ее встроенный RAID-Z на нескольких дисках дают куда как большую надежность.
le1ic
13.03.2019 20:17+11Читаешь такой «что делать с HDD с бэдами со студенческих времен?», и такой «waaaat?» А потом читаешь 4ТБ, и такой «а, ну да, я старый пердун...» мои HDD со студенческих времен – 256MB )))
abmanimenja
13.03.2019 20:37+3Читаешь такой «что делать с HDD с бэдами со студенческих времен?», и такой «waaaat?» А потом читаешь 4ТБ, и такой «а, ну да, я старый пердун...» мои HDD со студенческих времен – 256MB )))
Да ладно вам…
«4ТБ со студенческих времен» — это и для современных студентов довольно круто
мои HDD со студенческих времен – 256MB )))
Какой то размер странный.
SSD что ли?rrust
13.03.2019 21:00были и на 5МБ, большие, шумные и так сказать не очень быстрые. Однокурсник в autoexec.bat прописал строчку из песни «Ой мороз, мороз!», потому что и в самом деле можно было спеть минимум пару куплетов пока все загрузится и нортон командер покажет синие панельки.
Turilion
13.03.2019 21:03Согласен, какой то странный обьем. 40Мб были, 80Мб помню, даже 100 и 120 Мб стояли у нас в 486-тых. А потом как то сразу Гиг на К6-том. А таких странных обьемов не помню.
Exchan-ge
14.03.2019 00:4340Мб были, 80Мб помню, даже 100 и 120 Мб стояли у нас
5, 10, 20 (ST-225), 40 (Western Digital 93044A), 140 ( Caviar AC140), 340 (Conner CFA 340A), 840 (Caviar AC2850) — из того, с чем непосредственно работал.
Psychosynthesis
14.03.2019 01:57Полагаю автор комментария имел ввиду приближённое значение. Хабр не умеет в метафоры и сравнения, увы.
sibvic Автор
14.03.2019 06:52Невнимательно читали. Во время студенчества старые диски не доживали до смерти, а менялись на более емкие. По сути умер у меня только один винт WD на 40GB. Проблемы с бэдами полезли только при покупке емких винтов и отпадения надобности в таких больших объемах. Бэдами покрылись уже 5 винтов: 1,5, 2, 3, 4, 4 TB. Все лежат на полочке пустые. Вот и захотелось их использовать под что-то не очень нужное (игры, например).
token_zero
13.03.2019 20:55+3Используем старые HDD с бэдами
1. Для начала, возьмём отвёртку…
savagebk
13.03.2019 21:03+1Был винчестер в руках, когда он ко мне попал, то Reallocated sector count было в районе 5000. Пока спасал с него информацию стало в районе 70000. Мне его отдали, он долго валялся, потом понадобился в качестве временного пристанища для Ubuntu. И количество бэдов больше не росло. Был под наблюдением около года, я его потом еще знакомому айтишнику за 500 р. продал, честно предупредил, что он сыпался, но перестал.
Stas911
13.03.2019 21:15Интересно, а есть какое-нить Open source решение, которое на куче глючных винтов может построить надежное хранилище (в дублированием, контролем целостности и пр)?
ClearAirTurbulence
13.03.2019 21:29zfs? но, имхо, те, кто этим запаривается, не возятся с доходягами
Temtaime
13.03.2019 21:34+1Не может.
Любой бед заставляет zfs считать диск умирающим со всеми вытекающими.
u010602
14.03.2019 03:27Нет. Беды вылезают тогда, когда кончился резерв секторов (это сотни или даже тысячи секторов). Пока резерв есть — каждый диск чинит сам себя, и обычный рейд на них работает прозрачно. Когда диск не может уже сам себя чинить — то его лучше выбросить. Я пробовал продолжить их использовать, в течении месяца высыпались полностью. При этом таймауты при обращениях к таким секторам происходит на уровне САТА контроллера, т.е. даже не на уровне ОС. А значит возможные подвисания и лаги, вы ни как не можете контролировать. Т.е. просто присутствие такого винта в системе дает лаги даже в ходе загрузки биоса. Такой пк будет работать очень плохо. А ради чего?
berez
14.03.2019 10:39+1Нет. Беды вылезают тогда, когда кончился резерв секторов (это сотни или даже тысячи секторов). Пока резерв есть — каждый диск чинит сам себя, и обычный рейд на них работает прозрачно.
В теории все так.
На практике нечитаемый сектор далеко не сразу подменяется резервным. Какое-то время он болтается в pending reallocated sectors. А уж когда там его контроллер соблаговолит переназначить, зависит от многих факторов. У меня в экспериментах такие вот «недопереназначенные» сектора висели по полгода (и что характерно — все это время не читались). Лучший способ заставить контроллер переназначить такой сектор — это попытаться что-нибудь туда записать напрямую. Есть, конечно, и специальные команды для этого, но они вендор-специфик.
MinamotoSoft
13.03.2019 23:01+1Похвально! но перед изысканиями — полезно ознакомится с существующими решениями.
А то будет как с Остапом Бэндером.
«Всю ночь! соченял —
Я помню чудное мгновенье, передомной явилась Ты!...»
и только на утро вспомнил, что все это написал до меня А. эС. — Пушкин!
seri0shka
14.03.2019 01:00Пользуясь случаем, задам два вопроса знатокам.
1. Чисто теоретически (на практике точно не удастся проверить, железо не позволит). Имеем, например, диск с долгочитаемыми и бэдами, равномерно расположенными по всему объёму. Если переформатировать его, скажем, с 300 дорожек (ну или сколько их там бывает) на 100 дорожек- мы получим вечный диск меньшего объёма?
2. Со старыми дисками (не более 20 Гб) несколько раз встречал картину, когда диск просто усыпан «красными» секторами. И становился совершенно нормальным после обычного полного форматирования. То есть до этого, в моём понимании, информация была просто «размагничена» от времени, по аналогии с магнитной лентой. Может ли такое быть? Подтверждения никогда нигде не встречал, везде утверждается, что информация хранится «вечно».Psychosynthesis
14.03.2019 02:241. Нет. Если начал сыпаться настолько, что целые дорожки пришлось отключать — это вопрос времени, причём скорее небольшого. Вообще, раз уж вы подняли вопрос про «чисто теоретически» — любые новые бэды это с наибольшей вероятностью одно из двух:
- Загрязнения во внутреннем объёме а учитывая, что фильтры в HHD не идеальны, да и атмосфера тоже оставляет желать лучшего, «чисто теоретически» — он рано или поздно выйдет из строя.
- Размагничивания сектора. Если поверхность начала размагничиваться, значит жить ей осталось тоже недолго.
Да и вообще, HDD по сути своей, будучи механическим устройством не могут быть вечными.
2. Такое может быть, да. Насколько я понимаю, заряд на ячейке при работе периодически обновляется, однако это происходит только при попытках записи-чтения (перезапись, дефрагментация, проверка на бэд-блоки, etc). В любом случае «вечно» информация не хранится — ячейка может размагнититься и это факт.
OZR
14.03.2019 02:21После долгих исследований пришёл к подобному костылю. Для начала надо пройтись Victoria HDD из под DOS (именно из под DOS, не под Windows. Понятия не имею какие). Режим advanced remap+butterfly. Ставим диск и ждём. Если всё завершилось хорошо, ок. Если всё плохо, возможно нужно два прохода на один диск. В среднем это занимает чуть меньше недели чистого времени. После того как этот тест прошёл. Запускаем linux и там используем это
#!/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% поверхности бито бэдами восстанавливать не выгодно. Их будет больше, не поможет.OZR
14.03.2019 07:13(именно из под DOS, не под Windows. Понятия не имею какие)
Дурацкая опечатка которую невозможно отредактировать. * Понятия не имею какие слои абстракции накладывает операционная система для дисков. Они есть и уже много раз замечал, виктория из под windows полноценно не отрабатывает и не помогает. Виктория же из под DOS работает идеально. К сожалению альтернатив ей не существует, как и исходного кода к ней… Потрясающий софт. Версия 3.52.Naves
14.03.2019 13:06У меня на современных дисках с точностью до наоборот. DOS-версии в режиме advanced remap не удается заставить диск отремапить сектор, и из под Windows удается. Возможно это зависит от SATA-контроллера.
sotnikdv
14.03.2019 04:15Винт — дешевый расходник. Нет ничего хуже ненадежного хранилища, неважно для чего. Даже для фильмов, который я искал, качал, потом хотел посмотреть, он начал лагать и т.д.
Поэтому нужно убить свою жабу, выкинуть этот винт нафиг и купить новый. Я раз в год перетестирую свои винты (плюс смарт) и пускаю дефектные на блины (подставки под чашки) без сожалений.
4Тб, конечно 4Тб, но если он негарантийный — «в печку его!».
Единственное применение винта с бедами это или подставки под чай или поделки типа такой
P.S. Недавно в мусор ушло 2х4Тб и 4х3Тбu010602
14.03.2019 04:27Зря вы их в мусор выкидываете. Бывает у людей горит плата электроники, и чтоб достать данные нужна другая плата на запчасти. Лучше продавайте или дарите через сайты обьявлений. Там еще мотор и магниты могут пригодится самодельщикам.
OZR
14.03.2019 06:554 ТБ Б\У на авито стоят примерно 4к рублей, это рабочие. Цена давно не меняется 1к рублей = 1 тб. С серьёзными повреждениями можно в живых сохранить терабайта 3. В простенькой дисковой полке аля DELL MD1000 на 15 дисков влезет 45 терабайтов. Ещё одна такая же полка идёт на резерв и в тот же рейд. Итого 30 дисков. Пусть наглухо убитых. Но ещё живых и способных ещё прожить, возможно год или более и в подобных условиях обеспечить более чем надёжное хранение. А это уже лишние тысяч 90 рублей экономии. И вот уже когда они действительно умрут ещё один раз и на них будет невозможно составить карту бэдблоков, тогда уже дербанятся на магнитики и платы… К сожалению я не настолько богат, чтобы позволить себе подобное расточительство… выкидывать…
expromt
14.03.2019 12:24Ого. Локальную копию интернета хотите сделать? :-)
А если серьезно — раньше тоже занимался накопительством. Но пару лет назад пересмотрел взгляды. Сейчас только SSD на 384ГБ и те на 2/3 пустые и нисколько не страдаю да и чистку уже очень давно не делал. Так что хлама тоже присутствует порядком всякого.
vladkorotnev
14.03.2019 06:10Я лично с софт-бедами борюсь куда проще, сначала всю важную инфу перекатываем на свеженький винт, а потом делаем старому `dd if=/dev/zero of=/dev/sdX bs=1M`, переразмечаем и наслаждаемся новой помойкой для торрентов :-)
Temtaime
14.03.2019 06:33Какие-то всем идеальные харды попадаются, которые сами ремапят беды.
У есть несколько хардов Seagate и WD у которых всего несколько нестабильных секторов(появились в результате удара по диску во время работы, видимо), при чтении из которых хард возвращает ошибку в ОС, при этом заносить их в отремапленные он наотрез отказывается и викторией и вообще чем угодно. Полную перезапись и нулями и рандомными данными делал, эффекта нет. Вот просто есть всего несколько секторов, чтение из которых заставляет хард призадуматься и вернуть UNCR.
chkdsk прекрасная утилитка, которая помечает их как сдохшие и Windows перестаёт их использовать, но есть проблема: рядом с ними ещё 1-2 сектора, которые читаются, но с ощутимой задержкой в секунд 10 — харды их ремапить не хотят тоже.
Трюк автора хорош, но не технологичен, как уже сказали, правильным решением было бы читать диск в режиме прямого доступа и добавлять такие сектора, а также несколько соседних в специальный файл $BadClus, но таких тулз я не встречал в жизни, а написать самому — руки не доходят.
Зато в линуксе редактировать список проблемных секторов в той же ext4 — легче лёгкого, снял список секторов с помощью badblocks, расширил его в обе стороны на пару мегабайт и mkfs.ext4 — диски успешно работают уже долго без ошибок.vladkorotnev
14.03.2019 07:05Если не ремапятся, может, ремапить некуда уже?
Temtaime
14.03.2019 07:43Так в смарте параметр C4 и 05 равны нулю — как это некуда? Таких секторов всего несколько и их число не увеличивается, появились разово после удара.
mistergrim
14.03.2019 08:08У есть несколько хардов Seagate и WD у которых всего несколько нестабильных секторов(появились в результате удара по диску во время работы, видимо), при чтении из которых хард возвращает ошибку в ОС, при этом заносить их в отремапленные он наотрез отказывается и викторией и вообще чем угодно. Полную перезапись и нулями и рандомными данными делал, эффекта нет. Вот просто есть всего несколько секторов, чтение из которых заставляет хард призадуматься и вернуть UNCR.
После удара по диску может быть вообще всё, что угодно.Temtaime
14.03.2019 09:08Диск из ноутбука, ударили ноутбук во время работы.
Такие ситуации вроде бы сплошь и рядом, просто чуть не повезло и головка зацепила поверхность.
seri0shka
14.03.2019 10:44После удара по диску может быть вообще всё, что угодно
Лежит у меня на полочке ноутбучный диск после автоаварии. При чтении смарта примерно каждые три секунды замирает и через пару секунд оживает снова. Соответственно на смарте куча красных секторов, но они не привязаны к адресам, то есть при следующем чтении будут в других местах. Количество не растёт. Информацию можно записывать и считывать без ошибок, но тоже с паузами каждые три секунды (соответственно видео не воспроизвести). Получилась флешка для хранения на 320 Гб.
Подозреваю, что проблема в электронике, но донора для проверки нет.mistergrim
14.03.2019 15:18Конечно же, дело не в электронике, раз дефект плавающий.
И донор вам ничем не поможет, уже давным-давно гермоблок с электроникой представляют собой единое целое, нельзя просто так взять и поменять плату: в ПЗУ записана калибровочная информация для данного конкретного пакета блинов (т.н. адаптивы).
Vovan64
14.03.2019 07:00Такой способ имеет право на существование только как крайняя мера перед тем как выбросить веник и после:
1. Ремапа битых секторов смартом
2. На что запаса не хватило — отрезать разделом, лучше с каким-то левым типом файловой системы
3. Пометить остаток програмно чекдисками
Только не плохо бы создаваемые файлы с бедами делать системными и r/o — - тогда их никто дефрагментировать не будет.
P.S. — самовосстанавливающие коды применять бессмысленно так как в самом винчестере они уже реализованы, а бед — это уже когда совсем не вышло восстановить. Конечно немного полегчает, но масло масляное получится.
gecube
14.03.2019 08:45файл оставляем на этом бэде чтобы ничего больше на него не писалось.
ага. И любая дефрагментация — файл переезжает на новое место, а на место бэд-сектора — другой файл. Винт тупит. И в результате ошибки чтения/записи. ОК. Может не дефрагментация. Может у Вас очень умная файловая система (типа zfs, btrfs) и она вообще не гарантирует постоянство физических адресов секторов, в которых расположены файлы.
Надо понимать, что единственный надежный способ не дать операционной системе что-либо НЕ записать в бед-сектора — это не создавать поверх этих блоков файловую систему. Т.е. таблица разметки будет выглядеть так:
[MBR][раздел 1][раздел 2][блок с бэдами][раздел 3]
Далее если необходимо, то можно все разделы объединить в единое логическое пространство (напр., LVM в Linux).
u007
14.03.2019 08:57Какова может быть природа софт-бэдов, если они появляются массово, и что можно сделать?
Тут просто лежит Seagate на 2 Тб, почти неюзанный, выбросить жалко. Выскакивают бэды в области размером с 200 Гб, я их перезаписываю — исчезают, но потом возникают рядом. Плюнул, отрезал эти 200 Гб, некоторое время пользовался, но потом зона расширилась…gecube
14.03.2019 08:59Может быть контроллер глючит. Например, такая история была с IBM AVER серий. Половина их проблем была связана с «контактной болезнью».
PavelBelyaev
14.03.2019 08:59Сразу, как прочитал статью — в голову пришла мысль об автоматической дефрагментации. А еще если свет выключат и чекдиск запустится после ребута?
Stanislavvv
14.03.2019 09:32Всё ж как хорошо в линуксе — тупо запустил mkfs с параметром -c и всё…
berez
14.03.2019 20:57+1Пустая трата времени, если на диске есть области с «плавающими» дефектами (когда сектора в определенной области то читаются, то нет). Мало того, что на проверку времени уйдет масса, так еще и часть секторов из нестабильных областей заюзается — со всеми вытекающими.
Stanislavvv
15.03.2019 09:55Это уже другой вопрос, так как согласен, что использовать относительно современные винты с бедами нет смысла.
Но вот то, что под винды надо писать подобный софт, так как штатный уже не позволяет (действительно не позволяет или автор не умеет в документацию?) — показатель.berez
15.03.2019 18:16Штатный позволяет. Chkdsk умеет искать бэды и помечать их на файловой системе, чтоб не использовались. Это, конечно, не совсем то, что mkfs -c, но близко.
Temtaime
15.03.2019 20:32Только толку от этого нет — он не берёт соседние сектора, которые читаются, но с ощутимой задержкой в секунды — таким диском всё равно пользоваться не получится полноценно.
Sergery8205
14.03.2019 13:28Был винт с бэдами исключительно в пределах первых 40 Гб. Создал в этой части раздел, после нее еще один. Да — 40 Гб потерял, но зато уже несколько лет винт работает, но на 40 Гб меньше.
ledinhome
15.03.2019 17:40Идея очень классная, у самого лежат несколько винтов, совершенно не пригодных для постоянного использования, но идеально подходящих для хранения помойки. Chkdsk для них не пригоден, на одном из винтов, к примеру, был бэд вешающий винт. Находил его с помощью mp3шек, а потом в diskedit находил плохие сектора и помечал вручную.
Однако я не программист, и не понимаю что с этими исходниками делать. Найденный exeшник требует x64, которой у меня нет ни на одной машине. А если оно и под DOSом будет работать, и под WinXP…
И еще вопрос — файлы помечены как не перемещаемые?sysd
15.03.2019 18:07Идея не классная, прочтите комментарии, там предложена куча адекватных вариантов, и не делайте как написано в статье. Ну или хотя бы самый популярный.
zamboga
15.03.2019 20:07Да, тут как раз тот самый редкий случай, когда комменты полезнее осовного поста.
ledinhome
15.03.2019 20:39Да знаю я. Это заместо варианта «Если много — вырезанием целыми разделами», когда все штатные средства говорят «да выкинь ты его» :))
Еще забыл про возможность оставлять файлы с тормознутыми секторами :)
VBKesha
В том же NTFS есть штатно есть спец файл в котором хранятся бэды, чтобы туда ничего не писалось. И вроде бы есть ключ
/R Locates bad sectors and recovers readable information(implies /F).
чтобы эти бэды найти и пометить.
megapro17
Почему эти беды помечаются, но свободного места меньше не становится? Есть полу убитый жесткий на котором куча бадов, и всё так же 1 тб. Сканировал несколько раз, и викторией, и виндой.
VBKesha
Викторией точно результата не даст.
А винда в конце должна написать сколько секторов посечено как бэды, по крайне мере раньше так делала.
JerleShannara
Если лезут уже ФС-ные бэды, то хард лучше в помойку, это значит, что G-List уже забит под завязку, а он весьма приличного объёма. Ну или пересчитать транслятор, чтобы G-List в P-List перенесло, но толку мало — винт уже начал активно осыпаться.
VBKesha
Мне это вполне понятно, это больше к автору. Ну и с другой стороны для эксперементов вполне годятся подубитые винты.
mistergrim
Если G-List забит под завязку, вряд ли ОС уже будет в состоянии вообще что-то делать. Обычно это всё же софт-бэды.
JerleShannara
Имею опыт (правда древнего, современные может уже так не выживут) обращения с WD на 120Gb (купленного в те времена, когда эти 120Гб были супер-круто и вообще почти максимумом), который навернулся и как в песне «Весь покрытый бэдами» шустро начал сыпаться. Благо это был WD и удалось ему своеобразный LowLevel Format сделать с пересчётом. Он после такого стал на 80Гб, далее через две недели снова прилично сыпаться стал, и с повторением стал чем-то вроде 60Гб. На этом я предпочёл «закопать стюардессу» и купить таки под «инфернетики и музычку поставить» новый диск.
DrZlodberg
Или просто бэды попали в системную область. Есть у меня такой винт. В итоге сделал ему раздел, начинающийся дальше, чем идут бэды. Ещё был вариант с дохлой серединой — там решилось созданием 2х разделов, до начала бэдов и после них. Использую иногда как дискету — пока работают. Правда со вторым проблема в том, что вында (по умолчанию?) не видит второй раздел. Хотя 10ка может и видит уже.
iDm1
Если участок диска был поврежден в результате падения, то есть вероятность, что на его сроке жизни это не скажется (когда при повреждении не образовался мусор) если не обращаться к поврежденному участку. В таком случае плохие блоки на уровне NTFS/ext4 как раз могут помочь использовать его будто бы повреждения и не было. Разумеется не для критически важных данных.
vokzz
Потому что вместо этой «bad» ячейки используется другая из зарезервированной области диска. Вроде облать около пары процентов от емкости диска.
EvgeniyNuAfanasievich
Есть область резервная на диске, которая постепенно расходуется.
megapro17
А если израсходуется? Там довольно много бедов было.
JerleShannara
ABRT/T0NF/NRDY и прочие ужасные акронимы из эпохи начала IDE станут для вас обыденностью.