Показать полную графическую версию : Как преобразовать нестабильный сектор в бэд-блок?
Grabber2006
25-05-2015, 21:46
http://i72.fastpic.ru/big/2015/0525/60/0dcd1e48c31aa9896e97e24439136a60.png (http://fastpic.ru/)
Как преобразовать нестабильный сектор в бэд-блок? HDD стоит в RAID0, так что разрушающие методы не подходят.
Подскажите, каким софтом можно "добить" этот сектор. У меня подозрения на зависание компьютера из-за него.
DVDshnik
26-05-2015, 06:27
Склероз подсказывает, что можно дисковым редактором записать в сбойный сектор F8 (вроде) и он пометится как сбойный.
А так-то по времени наработки и числу включений диску приходит естественный капут.
дисковым редактором записать в сбойный сектор F8 (вроде) »- это вряд ли ;), по крайней мере, я такого редактора не знаю. Только технологическими утилитами. Да и не надо этого делать. Достаточно просканировать тестом чтения в Victoria for DOS или Victoria for Windows в среде WinPE/LiveCD. Результат теста и новый SMART выложить в теме.А так-то по времени наработки и числу включений диску приходит естественный капут. »- время нароботки всего 3 года, число включений/отключений 4452, что не является критичным :).
Grabber2006
26-05-2015, 21:18
Victoria 3.5 под DOS и 4.46 под WinPE не видит диски отдельно через RAID контроллер. Только массив целиком, который, естественно, не может инициализировать.
При попытке сделать диски временно non-raid утилита конфигурации RAID'а пишет "All data will be lost!" и делать я этого не хочу.
и делать я этого не хочу. »- пусть пишет, проверьте диск потом вернёте RAID-конфигурацию. Или подключите диск к другому ПК. Главное проверка и результат ;)
Как преобразовать нестабильный сектор в бэд-блок? »
Этот нестабильный сейтор уже есть бэд. И хард не знает, как с ним поступить...
Только технологическими утилитами. »
Не только... Можно поймать точный LBA этого сектора в той Victoria 4.46b, а затем попробовать тем же дисковым редактором WinHex или DMDE запмсать только в этот сектор любое значение, например 512 байтов 00h... Если это простой soft-bad, то он уйдёт или на худой конец переназначится...
Но лучше затереть этот сектор в той же Victoria 4.46b...
ЗЫ Это просто так, к слову....
DVDshnik
27-05-2015, 06:20
"All data will be lost!" и делать я этого не хочу. »
Из нулевого рэйда потерять данные - это как само собой разумеется. Если их не копировать, то они и сами потеряются независимо от желания.
Frost_WD
27-05-2015, 10:00
Привет Grabber2006,
Остальные уже дали вам неплохие советы. Мне хотелось добавить, что в принципе, рекомендуется всегда иметь бэкап, а как у вас стоит RAID 0 массив, то это практически обязательно если у вас есть важная информация (особенно если диск осыпается).
По поводу диска, как у Вас стоит RAID 0 не рекомендую подключат диск к другому ПК и т.д. Как потеря информации сильно вероятна. Это можете сделать если вы уверены, что у ваш контролер есть такие функции (для восстановление RAID 0).
Надеюсь был полезен,
Frost_WD
Этот нестабильный сейтор уже есть бэд. »
Нет. Это возможный кандидат на попадание в список плохих секторов или позже стать обычным сектором.
Hard disk case: weak sectors (http://www.hdsentinel.com/hard_disk_case_weak_sectors.php).
Weak Sectors (http://www.hdsentinel.com/forum/viewtopic.php?f=32&t=1416).
Вопрос в том, почему HDD не знает как с ним поступить или как работает алгоритм определения плохих или нестабильных(weak) секторов?
Grabber2006
27-05-2015, 12:02
Бекапы есть. Возможности подключить к другому компу пока нет.
Сделал средствами Windows полную проверку всех логических дисков с поиском сбойных секторов. SMART не изменился.
Этот RAID 0 пережил несколько конфигураций системников
Нет. Это возможный кандидат на попадание в список плохих секторов или позже стать обычным сектором. »
Много воды…, но я внимательно прочитал этот топик…
Утверждаю,--- пендинг это bad.
В свою очерередь и Вам рекомендую к прочтению пусть старую, но на мой взгляд актуальную и хорошую статью Сергея Казанского. Это разработчик легендарной Вмктории…
Логические дефекты
Эти ошибки возникают не из-за повреждения поверхности, а из-за нарушений логики работы сектора. Их можно разделить на исправимые и неисправимые. Логические дефекты имеют такие же внешние проявления, как и физические, и отличить их можно только косвенно, по результатам различных тестов.
Исправимые логические дефекты (софт-бэды): появляются, если контрольная сумма сектора не совпадает с контрольной суммой записанных в него данных. Например, из-за помех или отключения питания во время записи, когда винт уже записал в сектор данные, а контрольную сумму записать не успел (Рис. 1).
См. BAD-секторы. Что это такое, с чем это едят и как от них избавиться (http://www.x-hw.by/articles/hdd/1/full.html)
Это больше вопрос терминологический, но такое определение логического бэда (пусть и софтового, а не физического...) меня сполне устраивает….
Tau_0, Нет, pending это не bad.
И ваша цитата это подтверждает. И меня устраивает определения в моих ссылках.
На вопрос не ответите?
Вопрос в том, почему HDD не знает как с ним поступить или как работает алгоритм определения плохих или нестабильных(weak) секторов? »
Вопрос в том, почему HDD не знает как с ним поступить или как работает алгоритм определения плохих или нестабильных(weak) секторов? » »
У разных производителей или даже у одного производителя на различных линейках причины могут сильно отличаться... Даже неотлаженные фирмвари (кои мы не обсуждаем, поскольку производитель закрыл документацию...) могут быть тому виной. Но и ежику понятно, что в общем случае при нестыковке по ECC хард не cможет принять однозначное решение..., --- сектор попадёт в G-List (Relo-List) и будет там болтаться, если его (хард) не простимулировать записью в этот сектор...
ЗЫ Вы бы лучше внимательнее базовую статью Сергея Казанского почитали...
сектор попадёт в G-List (Relo-List) и будет там болтаться, если его (хард) не простимулировать записью в этот сектор... »
в этом и вопрос почему не может. Накопителю проще будет сразу пометить сектор как сбойный, например после нескольких попыток чтения/записи, чем оставлять болтаться в промежуточном положении.
Неужели у производителей нет таких жестких алгоритмов?
хард не cможет принять однозначное решение..., --- сектор попадёт в G-List (Relo-List) »- причём здесь G-List :confused: HDD именно принял решение и переназначил данный сектор, что и соответствует 05 атрибуту SMART.
IgNat, я бы сформулировал чуток иначе, типа:
"Если HDD принял решение и переназначил сектор – то только в этом случае он попадает в G-List, что отмечается увеличением атрибута 05"
- причём здесь G-List HDD именно принял решение и переназначил данный сектор, »
При том, что не всё так просто…
В данном случае речь идёт о таком скользком понятии, как soft-bad. Если посмотреть дискуссии на том же хоботе, то получается, что производители хардов не используют это понятие, --- оно изобретено пользоватеоями…
Но давайте с самого начала…
Когда записывается сектор, то заполняется не только поле DATA, но и что очень важно поля CRC и ECC…
Посмотрите кратко для хардов WDC
ТехнологияAdvanced Format (http://www.wdc.com/wdproducts/library/whitepapers/rus/2579-771430.pdf)
или здесь…
Технология NO-ID и увеличение плотности записи дисковых накопителей (http://www.mirpu.ru/hdd/72-standardshdd/181-no-id.html)
Для каждого сектора с данными имеется поле ECC, предназначенное для коррекции ошибок. При записи данных сектора высчитывается значение ECC и помещается в это поле. Этим делом занимается сам хард (его микрокод) и контроллер на аппаратном уровне. При последующем чтении сектора считанные данные проверяются и верифицирутся с помощью ECC. Так называемые коды Рида - Соломона (или другие техники) позволяют на лету скорректировать несколько ошибочных байтов в секторе с данными.
Но иногда случается, что хард по каким-то причинам не записывает верное значение в поле ECC. Что-то ему помешало это правильно сделать --- случайные сбои от перегрева, питания, магнитные поля, пылинка, тряски, луны Юпитера не так в линию стали… А так ничего более серьёзного и нет… Но самостоятельно хард с этой проблемой (нестыковкой по ECC) не справится. Но если записать в этот сектор какие-либо данные, то в этот раз данные запишутся правильно и поле ECC будет правильным (предполагается, что иных ошибок нет…). --- Сектор вернётся в строй. Это справедливо и для больших и для малых секторов…
ЗЫ В данном случае я хочу заострить внимание на моменте, когда поле ECC вне зависимости от конкретного места его нахождения вообще не записалось. Эту проблему сам хард решить не может…
Вот и ВСЁ.
Вот Вам напоследок цитата из статьи Сегея Казанского (разработчика Victoria…) ===>
Операционная система или BIOS не могут исправить логический дефект самостоятельно, так как прежде чем писать в сектор, они проверяют его на целостность, нарываются на ошибку и отказываются писать. При этом контроллер винта эту ошибку скорректировать тоже не может: он тщетно пытается прочитать этот сектор со второй, с третьей попытки, и когда это не получается - он всеми силами пытается себе помочь, на ходу подстраивая канал чтения и сервосистему.
Но если записать в этот сектор какие-либо данные, то в этот раз данные запишутся правильно и поле ECC будет правильным (предполагается, что иных ошибок нет…). --- Сектор вернётся в строй. Это справедливо и для больших и для малых секторов… »
Поэтому к сожалению Victoria (и ряд других программ) принципиально не может справиться с длинными секторами: она [как всегда] пытается записать 512-байтный сектор, и даже может отрапортовать об успехе – в то время как надо писать 4К-сектор, выровняв запись по началу физического сектора диска. И в результате ошибка сектора остаётся – причём для Victoria эта ошибка может блуждать в пределах этих самых восьми 512-байтных эмулированных секторов, на которые логически порезан длинный сектор.
Поэтому к сожалению Victoria (и ряд других программ) принципиально не может справиться с длинными секторами: она [как всегда] пытается записать 512-байтный сектор »
Это не такая уж большая беда, --- виктория позволит поймать LBA сбойных больших секторов. Когда их не слишком много, то эти секторы можно затереть или на худой конец переназначить записью в дисковом редакторе диапазона из восьми 512 байтовых в сектор с нативными 4096 байтами.
Я имел в виду другое --- если поле DATA записалось верно, а поля для верификаци данных (CRC и ECC вне зависимости от размера сектора и от того где бы они физически не находились) по какой-то причине не записались, то всегда будет нестыковка по ECC... И эту проблему хард сам никогда не решит.
По крайней мере так Tomset в своё время это дело толковал, а также обосновывал высщкую заполненность Relo-List и вынужденность "Slow responding" у хардов WDC...
Это не такая уж большая беда, --- виктория позволит поймать LBA сбойных больших секторов »
Угу. Собственно, наиболее распространённый метод нахождения этих секторов даже на AF-дисках – в Victoria, и с последующей блочной перезаписью уже в другой программе (например, в DMDE: чтение с игнорированием ошибок блока из 8 эмулированных секторов одного длинного сектора в промежуточный файл – запись этого блока обратно. Такое чтение/запись позволяет в т.ч. избежать уничтожения информации при неверном определении номера сектора: например, открыли диск как логический и стали записывать сектор 77777 от начала логического диска, в то время как Victoria показывает эти 77777 от начала физического диска).
© OSzone.net 2001-2012
vBulletin v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.