информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Где водятся OGRыSpanning Tree Protocol: недокументированное применение
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Microsoft обещает радикально усилить... 
 Ядро Linux избавляется от российских... 
 20 лет Ubuntu 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / operating systems
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
[NT] Видимо игнорирует... Ибо сырой. 20.11.06 11:56  Число просмотров: 2898
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 20.11.06 11:57  Количество правок: 1
<"чистая" ссылка>
> 1. Что надо сделать, чтобы shadow copy мог корректно
> работать на диске, где chkdsk нашёл бэд блоки?
Выключить его, чтобы информация о теневых копиях пропала. И вкючить его, возможно тогда, поскольку ни один файл уже не "ляжет" на сбойные кластеры, то и ShadowCopy нервничать не будет.

> 2. Почему shadow copy так себя ведёт? (но это академический интерес)
Разлагается M$, неясно чтоли? -)) Живы ли те, кто разрабатывал NTFS? ИМХО, WinFS провалилась оттого, что не смогли разобраться в коде NTFS (шутка), а теневые копии ИМХО очень тесно юзают NTFS на весьма низком уровне.
<operating systems>
[NT] Shadow Copy игнорирует информацию о bad block ? 20.11.06 10:38  
Автор: ZloyShaman <ZloyShaman> Статус: Elderman
<"чистая" ссылка>
Внимание, много буков.
Ситуация:
Windows XP SP2. После сбоя электропитания в логах посыпались ошибки:
The device, \Device\Harddisk1\D, has a bad block.
(\Device\Harddisk1\D - это системный раздел )
Сделал chkdsk с исправлением, нашлось 12 Кб бэд блоков, ошибки в логах прекратились.
Через несколько дней попробовал сделать ntbackup всего раздела. Процесс до конца не завершался, в логах ntbackup видны сообщения вида:
WARNING: Portions of "\Documents and Settings\me\My Documents\My Pictures\mypic.JPG" cannot be read. The backed up data is corrupt or incomplete.
This file will not restore correctly.

В логе приложений при этом снова видна ошибка
The device, \Device\Harddisk1\D, has a bad block.
которая появляется строго в паре с:
The shadow copy of volume G: was aborted because of an IO failure.
Если исключить проблемный файл из бэкапа, то затыкается на другом файле. При этом проводником или тотал коммандером все эти проблемные файлы копируются прекрасно. И они точно не повреждены (если это архив - он корректно разархивируется, если картинка - открывается).
Сделал chkdsk второй раз, новых бэд блоков нет. Проверил утилитой от производителя жёсткого диска, нашлось 3 бэда (3 бэда Х 4 Кб кластер = 12 Кб, вроде всё верно)
Далее, я отключил в ntbackup Shadow Copy, и всё прекрасно скопировалось.
В общем, пока что не ситуация видится так. Chkdsk пометил бэд блоки и теперь Windows их не использует. Но механизм shadow copy почему-то игнорирует эти записи (возможно, обращается к диску на более низком уровне?). Объяснение не кажется мне правдоподобным, но более убедительного я пока не придумал.
Итого два вопроса:
1. Что надо сделать, чтобы shadow copy мог корректно работать на диске, где chkdsk нашёл бэд блоки?
2. Почему shadow copy так себя ведёт? (но это академический интерес)
[NT] Видимо игнорирует... Ибо сырой. 20.11.06 11:56  
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 20.11.06 11:57  Количество правок: 1
<"чистая" ссылка>
> 1. Что надо сделать, чтобы shadow copy мог корректно
> работать на диске, где chkdsk нашёл бэд блоки?
Выключить его, чтобы информация о теневых копиях пропала. И вкючить его, возможно тогда, поскольку ни один файл уже не "ляжет" на сбойные кластеры, то и ShadowCopy нервничать не будет.

> 2. Почему shadow copy так себя ведёт? (но это академический интерес)
Разлагается M$, неясно чтоли? -)) Живы ли те, кто разрабатывал NTFS? ИМХО, WinFS провалилась оттого, что не смогли разобраться в коде NTFS (шутка), а теневые копии ИМХО очень тесно юзают NTFS на весьма низком уровне.
Кто сырой? Shadow Copy? Он вроде бы с 2К существует, нет? 20.11.06 12:05  
Автор: ZloyShaman <ZloyShaman> Статус: Elderman
<"чистая" ссылка>
Кто сырой? Shadow Copy? Он вроде бы с 2К существует, нет?
> Выключить его, чтобы информация о теневых копиях пропала. И
> вкючить его, возможно тогда, поскольку ни один файл уже не
> "ляжет" на сбойные кластеры, то и ShadowCopy нервничать не
> будет.
Это я не понял, что и где нужно выключить и включить?
Правой кнопкой мыши по диску, Свойства->Теневые копии->Отключить. Применить это дело. Потом снова включить. 20.11.06 13:08  
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 20.11.06 13:11  Количество правок: 2
<"чистая" ссылка>
Данной процедурой ты сбросишь информацию о теневых копиях, и начнёшь их создавать заново.

Ты говоришь, прогнал утиль от производителя, и она сделала Remap, т.е. переназначила сбойные кластеры на резервные? Гы-гы, винда уже успела отметить в NTFS инфу о сбойных кластерах, прощай 12K с винта.
Маленький совет: никогда не гоняй chkdsk на поиск битых кластеров, он медленный, и делает всё "неправильно", проще при подозрениях на бэды сразу гнать утиль производителя или mhdd для ATA/SATA винтов... mhdd сделает ремап, и всё будет в шоколаде... на некоторое время -))

Сейчас у тебя и так весь винт читается на низком уровне, хотя в NTFS и осталась информация о том, что кластеры "сбойные". Поэтому и было чтение данных ShadowCopy невозможным.

Вообще, такое поведение Shadow Copy ненормальное, отправь Bug Report в M$.
не надо так шутить ;) 20.11.06 13:13  
Автор: ZloyShaman <ZloyShaman> Статус: Elderman
<"чистая" ссылка>
Повторяю, у меня Windows XP. Там служба теневой копии не запущена постоянно. И вкладки такой в свойствах диска тоже нет.
> Ты говоришь, прогнал утиль от производителя, и она сделала
> Remap, т.е. переназначила сбойные кластеры на резервные?
> Гы-гы, винда уже успела отметить в NTFS инфу о сбойных
> кластерах, прощай 4K с винта.
Она не переназначала, а просто нашла. Так что информация о сбойных кластерах хранится в NTFS.
> Сейчас у тебя и так весь винт читается на низком уровне,
> хотя в NTFS и осталась информация о том, что кластеры
> "сбойные". Поэтому и было чтение данных ShadowCopy
> невозможным.
Они и есть до сих пор сбойные. Смотри предыдущий абзац.
На "низком уровне", т.е. утилитой от проиизводителя, как и раньше на трёх секторах выдаётся ECC Error.
> Вообще, такое поведение Shadow Copy ненормальное, отправь
> Bug Report в M$.
А у меня виндоус нелицензионный. Это ничего?
Всё, понял, прости за невнимательностсь, Shadow Copy мне въелось в башку -)) Прогони ещё раз MHDD по диску... может найдёт чего? 20.11.06 13:19  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
Я уже обгонялся всяких утилит. 20.11.06 13:38  
Автор: ZloyShaman <ZloyShaman> Статус: Elderman
<"чистая" ссылка>
Дело-то не в ненайденных бэдах. Файлы нормально копируются => расположены в здоровых секторах.
У меня предъява именно к Shadow Copy.
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach