verissimo 9285 Здесь нет мусора, здесь несколько сложнее. Раздел форматировался в WinXP, но на нем оставалось очень мало места (вероятно,
verissimo сильно душила жаба купить новый винт побольше и делать хоть частичный бэкап на старый). Когда места на разделе мало, MFT-зона сокращается и, в конце концов, свободное место для роста MFT заканчивается совсм. Начинается сильная фрагментация MFT. Ранлист становится настолько большой, что в одну запись он уже не лезет. Поэтому в $MFT появляется атрибут 20=ATTRIBUTE_LIST, в котором перечислены все записи, использованные под данный файл (в дополнительно ипользуемых записях на самом деле только один атрибут 80=DATA). Вернее, там (в 20) перечислены все атрибуты (в т.ч. и расположенные в базовой записи), но для каждого из них указан номер файловой записи. В данном случае мы имеем две записи, использованные под атрибут 80 =DATA: собственно, запись 0 ($MFT), а также запись EE2Ch (60972). То, что кажется мусором - это часть ранлиста MFT, расположенная в записи 0 ($MFT), а мусором оно кажется из-за повторяющихся экстентов 11 02 0A (размер 2 кластера, смещение от предыдущего фрагмента - A кластеров). Глюк это, или действительно MFT имела такой ранлист, никто теперь разбираться не будет, но формально такое возможно. Вы спросите: а как же найти запись EE2Ch, если MFT может быть фрагментирована, а координаты нужного фрагмента могут оказаться неопределимыми без этой самой EE2Ch? Вероятно, используется одно из двух упрощений:
1. Дополнительные записи под $MFT : DATA выделяются только в первом фрагменте MFT.
2. Дополнительные записи под $MFT : DATA выделяются только в тех фрагментах, которые описаны в $MFT.
Как именно, я не знаю, но по-другому вроде никак не сделаешь.
Но это лирическое отступление. Практика для такого кейса следующая:
1. Устранаются какие-либо проблемы, следствием которых стало накрытие раздела. Если они неизвестны, проводится тщательный тест памяти и блока питания, анализ SMART'а винта и результатов сканирования поверхности, состояния кондеров на матери (если они "обычные", не танталовые). В общем, чтобы безопасно продолжать, надо быть уверенным, что причина устранена.
2. Запускаем chkdsk.exe БукваРаздела: и смотрим что не так. Если какая-нибудь мелочь, то можно и /f разрешить, но при таком ранлисте MFT это стремновато, я как-то прокололся на таком... Т.е. /f можно только если нет особо ценного. То, что
verissimo уже дал один раз отработать Чекдиску на исправление, не проанализировав вначале его отчет без исправлений, является недопустимым в практике даже любительского DR. Если Чекдиск находит существенные проблемы, например ругается на DATA в записи 0 или EE2C, то не надо испытывать удачу - восстановление делается копированием в R-Studio на другой винт.
3. Если восстановили на другой винт, то проблемный раздел форматируем в Управлении Дисками. Не забываем удалить Acronis, Partition Magic, HDD Regenerator и прочую фигню, если еще не сделали этого. Копируем инфу обратно - имеем бэкап, не забываем поддерживать его актуальность.
Если восстановили in-place (исправили Чекдиском), то копируем все ценное на другой винт в целях бэкапа.
Обычно, однако, пользователи делают кое-как, т.к. им банально лень заморачиваться.
"Скажи мне марку твоего БП и я скажу кто ты"
Jurij82 Я бы с таким вообще не заморачивался in-place. Избавьтесь от этого глюкала. 4K080H4 - это чудом выживший четырехголовый квакстор с фосфорным коммутатором. С очень даже не нулевой вероятностью коммутатор начал дохнуть - следующее включение может обернуться стучащими звуками. Но могут быть и банальные бэды, ведь винт феноменально стар (он был старшим в линейке - еще были 4K040H2). Если на данный момент удается как-то читать этот винт (MHDD видит, HDDScan видит, WinHex видит), копируйте, как можно быстрее, на новый винт: WinHex - Clone Disk, источник - диск, приемник - файл; потом из полученного файла восстановите в R-Studio или GetDataBack (на сам винт проги не напускать!). Если уже не определяется нигде, или во всех секторах ошибки, то все, только DR-фирма.
rodrigo_f Нет, ему нельзя ремап! Винт очень стремный - посекторку с него как можно быстрее. SMART вроде как уже откинулся, так что лучше не насиловать этот реликт. Если СМАРТ работал, очень вероятно было там увидеть большой Hardware ECC Recovered RAW - показатель скорого накрытия коммутатора на этих кваксторах.
Я понимаю, что там могут быть банальные бэды от старости, но, тем не менее... Кстати, у меня на работе когда-то именно такой в файлообменнике сдох - застучал при включении, обычная фигня для фосфорного квакстора (но нам не надо было ничего восстанавливать, просто заменили винт).