MHDD_(remap)

[melanholiac]

Вопрос конечно по софту, но тесно связанный с железом, поэтому тему решил разместить в текущем разделе.

Суть вопроса: программа MHDD, команда remap - при обнаружении bad сектора переносит информацию (пытается) из поврежденного сектора в резервные сектора, которые находятся в конце диска?

[Тролль]

Q11: Разрушает ли информацию процедура remap?

A: Ответ касается только программы MHDD: нет, не разрушает, так как информация в секторе и так потеряна. Т.е, информация в бэд-секторе разрушена ещё до процедуры remap.

( MHDD FAQ )

[melanholiac]

Q11: Разрушает ли информацию процедура remap?

A: Ответ касается только программы MHDD: нет, не разрушает, так как информация в секторе и так потеряна. Т.е, информация в бэд-секторе разрушена ещё до процедуры remap...

Виноват :) , не так поставил вопрос.

я хотел спросить относительно переназначенных сбойных секторов:

В чем собственно заключается это переназначение?, если я правильно понял то сбойные блоки заменяются рабочими, из некого резерва?

[melanholiac]

Вообщем вот что вычитал:

"Как известно, современные винчестеры имеют резервную поверхность. На нее можно "перевести стрелки" при обращении к сбойному сектору, т.е. когда нужно обратится к сектору, который признан сбойным, на самом деле обращение произойдет к сектору из резервной поверхности, назначенным на замену."

Подоплека моего вопроса состояла в том, что я хотел понять где физически находятся "секторы из резервной поверхности", ведь если они находятся очень далеко (в конце диска например) от места где произошел remap (переназначение сектора), То тогда, когда я попытаюсь записать длинный файл на диапазон с переназначенным сектором, то часть файла может оказаться на другом конце диска --- что крайне негативно скажется на времени доступа ко всему файлу, ведь головке чтения\записи придется метаться туда-сюда чтобы прочитать этот файл. Ведь так?

[GUST]

melanholiac

Все утилиты в ДОСе оставляют 6, 7, 8 МБ одну партицию НЕОПРЕДЕЛЁННУЮ, (unknonе, или похожее), как раз для таких целей! Умудряются их сносить (сам такой, экономия, млинЪ!), но при забитых дисках контроллер харда будет недоумевать, теряться и слабо определяться - куда переносить с начинающихся бэдиться секторов?

Так что твои и мои догадки совпадают.

Головки могут не метаться, если будешь нормально дефрагментировать диски.

Все адреса файлов чётко прописаны.

Стоит перенести/переместить пару папок или файлов - усё, можно дефрагментироваться!

А ваще, для каждого производителя хардов есть собственные и сторонние проги/утилиты для Вин или ДОСа.

Полный перечень имеющихся услуг - от температуры и до отслеживания последних часов жизни отдельных элементов.

Практика показывает - если первые пол года новый хард не "уснул" (и тесты выдерживает!), то есть надежда, что и вторые пол года ещё пропашет. Встречались харды с 10 летней наработкой как новенькие, и "только что купленные" годные на свалку. :)

Да, ещё есть такое - CHECKFDSK (или похожее) - утилита Винды. При сбое инфы с любого диска при запуске Винды начинается Проверка и реставрация. Дождись и не отменяй!

Win2000 Pro SP4 справляется замечательно! :)

А ХР старается, но не могёть... :)

[Тролль]

melanholiac:

Неразмеченное дисковое пространство 6-8 Мбайт оставляется для возможности последующего преобразования каких-нибудь логических дисков в динамические без переразметки диска, для этого нужно немного мегабайт неразмеченного пространства на диске. К бэдам это отношения не имеет. Сбойные же сектора заменяются на резервные контроллером диска. А обнаружить их ему "помогает" MHDD, нагружая его работой с сомнительными секторами. Сколько MHDD будет "тыкать в нос" контроллеру диска дефектным сектором и когда этот контроллер решит заменить сектор на резервный, зависит от типа ремапа и типа HDD. Иногда дело может обойтись просто многократным стиранием сектора и все наладится. Если уж MHDD или другая аналогичная программа довела контроллер до того, что он решил заменить сектор на резервный, то где он возьмет этот резервный сектор, зависит от разметки диска контроллером на технологическом уровне, то есть от изготовителя диска. Раньше резервные сектора находились в конце диска за пределами нормальной рабочей зоны и обращение к резервному сектору действительно вносило большую задержку, сейчас скрытые резервные сектора обычно распределяют более или менее равномерно по поверхности диска. Как именно, каждый производитель решает сам для себя.

Изменено 8 августа, 2007 пользователем Тролль

[melanholiac]

Тролль

Спасибо.

Итак, правильно я понял что вслучае с выше указанным примером (запись большого файла на диапазон с замененным сектором), часть файла сначала окажется непонятно где, но после дефрагментации все вернется на круги своя?

[Тролль]

melanholiac:

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

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

Резервные сектора вносят, так сказать, неустранимую скрытую фрагментацию - неустранимую потому, что о том, что контроллер подменяет один сектор на другой, не знают ни операционная, ни файловая система. Они потребовали от контроллера предоставить сектор, скажем, с номером 32345. Контроллер его предоставил, а где он на самом деле, знает только контроллер. Фрагментация небольшая, потому что резервные секторы на современных винчестерах обычно находятся поблизости от дефектных и часто даже не требуют перемещения головок для чтения, так как находятся на тех же дорожках, что и дефектные секторы (точнее, на тех же цилиндрах), или требуют только небольшого перемещения головок, да и самих дефектных секторов на диске не так уж много. По сравнению с общим временем чтения большого файла его увеличение из-за дефектного сектора будет очень небольшим, а чаще всего просто нулевым, потому что при большом файле скорее всего резервный сектор окажется рядом с рабочими, а перераспределит прочитанные секторы в правильном порядке контроллер уже в своей оперативной памяти (буфере) после чтения всей дорожки.

P.S. Раньше резервные сектора располагались в специальной отдельной зоне в конце диска. Тогда действительно головкам приходилось бегать за резервным сектором довольно далеко. Но это было неприятной и довольно редкой случайностью, и в среднем только чуть-чуть увеличивало характерное для диска время доступа к данным. Хотя какому-то файлу могло и не повезти, но программы дефрагментации это опять же не учитывали. А сейчас и эти потери из-за распределения резервных секторов по всей поверхности диска сильно уменьшились.

Изменено 9 августа, 2007 пользователем Тролль

[GUST]

Тролль

Эти небольшие неопределённые партиции на 7-8 МБ создаются в ДОСе, другие проги их не создают.

Для чего?

Мне говорили, что для "запаса" чистого места на случаи потери секторов. Оказывается, что это не так.

Ещё небольшой вопрос:

На диске с Виндой остаются красные полоски, не дефрагментированные файлы. Diskeeper'oм пользуюсь.

Довожу до ежесуточной дефрагментации.

Для упорядочения секторов, понятных и Винде с Diskeeper'oм, и контроллеру харда, что можно и нужно делать?

Винда стоит 4.8 года, хотелось бы облегчить её участь и головок... :)

[Тролль]

GUST:

В DOS'е? Хм, не помню, чтобы FDISK у меня создавал неразмеченную область 8 мегабайт... Хотя я им уже давным-давно не пользовался для разметки, мог и забыть.

Со времен Windows 2000 часто при разметке винчестера на разделы автоматически оставляются свободными 8 мегабайт специально для возможности последующего преобразования дисков в динамические, поскольку теряемая при этом память по сравнению с остающимся объемом диска сейчас практически ничто.

Если во время установки Windows 2000 вы пытаетесь создать раздел, который будет занимать все оставшееся на диске место, в конце диска может остаться неиспользуемое пространство. Это происходит потому, что программа установки Windows 2000 резервирует пространство в конце диска для того, чтобы сделать возможным последующее обновление диска с обычного на динамический. Динамическая информация диска сокраняется в его конце. Резервируемое пространство составляет как минимум один цилиндр, но не менее 1 Мб.

( Почему при создании раздела остается неиспользуемое место в конце диска )

Об этом пишет и Microsoft:

Некоторое пространство в конце диска резервируется установщиком на случай если вы позднее захотите преобразовать диск в динамический. Информация динамического диска хранится в конце диска. Резервируемое количество составляет минимум один цилиндр или 1 Мегабайт, то, что больше. Один цилиндр может быть до 8 Мегабайт, в зависимости от конструкции диска и разметки.

( http://support.microsoft.com/kb/225822/en-us , перевод с английского мой)

или тут

Диски с Master Boot Record Disk (MBR) должны иметь не менее 1 мегабайта свободного пространства в конце диска для динамической базы данных. Управление Дисками и Setup автоматически резервируют это свободное пространство, когда создают разделы или логические диски, но диски с разделами и томами, созданными другими операционными системами, могут не иметь этого свободного доступного пространства.

( http://www.microsoft.com/resources/documen...0.mspx?mfr=true , перевод мой)

Была, кстати, уже темка об этих мегабайтах, Неразмеченное пространство...

Недефрагментированные файлы - это те, которые Виндой запрещено дефрагментировать, поскольку они ей в любой момент могут понадобиться. Можно попробовать дефрагментировать диск с Виндой из другой системы, например, загружаемой с CD (я сам не пробовал, мне хватает обычной степени дефрагментации).

Как часто дефрагментировать - это примерно, как часто убирать в комнате - кто любит это делать понемногу часто, кто помногу редко. Дефрагментация ведь тоже нагрузка для винчестера, поэтому я о дефрагментации думаю только как о средстве ускорения доступа к файлам, а о сроке жизни винчестера у меня заботится его кулер. Ну и, конечно, есть винчестер для резервной копии важных данных. И винчестер обычного пять лет назад объема сейчас, боюсь, уже немного стоит :) , так что проще предоставить заботу о нем святому Исидору, одному из первых энциклопедистов и покровителю устройств хранения информации, назначенному на эту работу Папой Римским...

P.S. Впрочем, лучше не пытаться объехать Windows сбоку и дефрагментировать на NTFS из другой системы то, что самой Винде не хотелось бы дефрагментировать. ИМХО, это весьма рискованно... Некоторые дефрагментаторы обладают способностью делать дефрагментацию после перезагрузки компьютера перед загрузкой Windows, чтобы дефрагментировать то, что не дает дефрагментировать Windows, но бывает, что после такой дефрагментации Windows не загружается. Тише едешь - дальше будешь... :(

Изменено 11 августа, 2007 пользователем Тролль