Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
|
во время выполнения операции страничного обмена => тот на котором своп. 23.07.04 11:15 Число просмотров: 4693
Автор: Killer{R} <Dmitry> Статус: Elderman
Отредактировано 23.07.04 11:19 Количество правок: 1
|
|
Был такой прикол при загрузке на в2к. Тогда еще чекдиск вылетал и ниче не находил при каждой загрузке. Помогла мистика - полный скан на бэды утилитой производителя под досом. Бэдов утилита не прошла, а глюк прошел. Испугался наверно.
|
|
<sysadmin>
|
[Win2k Serv] Помогите разобраться, плз... 23.07.04 08:59
Автор: HandleX <Александр М.> Статус: The Elderman
|
Итак, в логах системы (см. subj.) такое: «Обнаружена ошибка на устройстве \Device\Harddisk0\DR0 во время выполнения операции страничного обмена. ».
Вопрос: какой это логический диск? ;-)
Всем заранее спасибо за ответы.
|
|
[Win2k Serv] Это весь диск (в смысле raw физический диск) 23.07.04 11:37
Автор: amirul <Serge> Статус: The Elderman
|
> Вопрос: какой это логический диск? ;-)
А вообще меппинг из досовских имен в виндовые можно найти только в директории объектов.
WinObj от sysinternals
OBJDIR в SoftICE
objdir.exe в NTDDK\tools\other (NTDDK для любых версий)
|
|
во время выполнения операции страничного обмена => тот на котором своп. 23.07.04 11:15
Автор: Killer{R} <Dmitry> Статус: Elderman
Отредактировано 23.07.04 11:19 Количество правок: 1
|
|
Был такой прикол при загрузке на в2к. Тогда еще чекдиск вылетал и ниче не находил при каждой загрузке. Помогла мистика - полный скан на бэды утилитой производителя под досом. Бэдов утилита не прошла, а глюк прошел. Испугался наверно.
|
| |
Утилита (вернее винт) втихоря могли перемапить бедсектора. Производитель кто? 23.07.04 11:22
Автор: Garick <Yuriy> Статус: Elderman
|
|
|
| | |
Maxtor. Я тоже так думал, единственное НО- после чего этот... 23.07.04 11:43
Автор: Killer{R} <Dmitry> Статус: Elderman
Отредактировано 23.07.04 11:44 Количество правок: 1
|
|
Maxtor. Я тоже так думал, единственное НО- после чего этот глюк начался - начался он после подключения к тому компу вторым винтом старый глючный винт, у которого бэдов - 10% свободного места. Вобщем винда тогда с этим глючным винтом загружалась минут 10, а после изъятия винта и начались глюки с чекдиском.
|
| | | |
Повермах от матраса не объективен при проверке, лучше mhdd юзать - он универсален для IDE.. 23.07.04 12:01
Автор: Garick <Yuriy> Статус: Elderman
|
> глюк начался - начался он после подключения к тому компу
> вторым винтом старый глючный винт, у которого бэдов - 10%
> свободного места. Вобщем винда тогда с этим глючным винтом
> загружалась минут 10, а после изъятия винта и начались
> глюки с чекдиском.
После подключения битого винта вынь вообще отказалась грузиться с синим экраном "inaccessible boot device". В другой похожей ситуации помогло подключение другого винта главным с непопорченной вынь (быстрее всего ФС НТФС). Чекдиск востановил индексы ФС и все снова заработало.
Есть подозрение на принудительную переиндексацию чекдиском битых ФС (при физических бедах) и паровозом нормальных, а потом какой то облом и порча нормальной ФС.
|
| | | | |
Вобще то винды тогда не с первого раза загрузились, и пару... 23.07.04 12:14
Автор: Killer{R} <Dmitry> Статус: Elderman
|
|
Вобще то винды тогда не с первого раза загрузились, и пару раз их ресетили в процессе загрузки, возможно образовался логический бэд. Но почему тогда чекдиск при полном скане /F /R ничего не находил. Да и повермакс, - может он втихаря разобрался с логическим бэдом?
|
| | | | | |
А ФС какая? ФАТ или НТФС? Нормальным чекдиск был еще в ДОС и вынь9х. А в НТ он, по-моему, кривоват. 23.07.04 12:20
Автор: Garick <Yuriy> Статус: Elderman
|
|
|
| | | | | | |
Кривой он как раз-таки в Win9x... Меня пугало переполнение буфера при выводе на экран — этож надо, блин, если они даже здесь прокосячили! ;-) Да и посекторное сканировани крайне тормозно реализовано, не в пику mhdd... 23.07.04 12:23
Автор: HandleX <Александр М.> Статус: The Elderman
|
|
|
| | | | | | |
NTFS 23.07.04 12:21
Автор: Killer{R} <Dmitry> Статус: Elderman
|
|
|
| | | | | | | |
Есть у меняч подозрение о кривости родного чекдиска с НТФС, особенно с индексами. Может кто встречал проверенный и достаточно надежный альтернативный проверяльщик НТФС? 23.07.04 12:25
Автор: Garick <Yuriy> Статус: Elderman
|
|
|
| | | | | | | | |
Дык ведь глюк был вроде не на уровне ФС да и повермакс "исправивший" глюк про НТФС ниче не знает 23.07.04 12:42
Автор: Killer{R} <Dmitry> Статус: Elderman
|
|
|
| | | | | | | | | |
Битая физика "тянет" и проблемы с логикой (ФС). "повермакс "исправивший" глюк про НТФС ниче не знает" - нет матраса под рукой- проверить не могу, некоторые утилиты (сеагейт например) тестят и ФС. 23.07.04 12:49
Автор: Garick <Yuriy> Статус: Elderman
|
|
|
| | | | | | | | | | |
Ну по кр мере он очень хорошо делал вид что не знает ФС 23.07.04 12:57
Автор: Killer{R} <Dmitry> Статус: Elderman
|
|
А именно - для теста выбрал сразу физический диск целиком, про разделы ниче не сказал, говорил что сканит сектора/дорожки, но никак не файлы/индексы/десктрипторы.
|
| | |
Рассказываю подробнее. 23.07.04 11:34
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 23.07.04 11:41 Количество правок: 1
|
Про ремап - нет, наврядли. Винты SCSI, 15000RPM IBM (загрузочный) и два Seagate, совмещённые в RAID0.
Кстати в логах есть ещё записи, что контроллер SCSI не ответил за отведённое ему время...
Предполагаю, что виновато отключение винтов во время их простоя, а потом долгая их раскрутка, поскольку все записи помечены временем после часа ночи, как раз "тишина" на серваке.
Как думаете, если эти записи в логах просто дибилизм от M$, стоит ли на них забить, или же лучше, чтобы винты вообще не отключались?
Ну и корневой пост не оставляет меня в покое — как же всё-таки разрезольвить «\Device\...» в раздел?
Тем более, что у меня там намудрено со всякими Junction Point'ами и рэидами ;-)
|
| | | |
Все Junction Point-ы резолвятся на уровне файловой системы и... [upd] 23.07.04 11:58
Автор: amirul <Serge> Статус: The Elderman
Отредактировано 23.07.04 12:02 Количество правок: 1
|
> Как думаете, если эти записи в логах просто дибилизм от M$,
> стоит ли на них забить, или же лучше, чтобы винты вообще не
> отключались?
> Ну и корневой пост не оставляет меня в покое — как же
> всё-таки разрезольвить «\Device\...» в раздел?
> Тем более, что у меня там намудрено со всякими Junction
> Point'ами и рэидами ;-)
Все Junction Point-ы резолвятся на уровне файловой системы и к девайсу отношения не имеют. А резолвить какой именно это диск надо через базу PnP Manager-а.
Скорее всего будет что-то вроде:
Идешь в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\SCSI
И смотришь там на все устройства с Class=DiskDrive
Первое такое устройство (из присутствующих в данный момент в системе) скорее всего и будет Harddisk0.
(NB: открывать не regedit-ом, который сразу сортирует по алфавиту, а RegEnumKeyEx-ом, как собственно и делает PnP)
-----
Можно еще пользоваться
reg query
она вроде не сортирует а как сэнумерирует так и выводит
-----
ЗЫ: За любые повреждения ответственности не несу :-)
|
| | | | |
Ух ты... Кое что нашёл! 23.07.04 12:18
Автор: HandleX <Александр М.> Статус: The Elderman
|
Там для каждого из винтов в реестре HKLM\SYSTEM\CurrentControlSet\Enum\SCSI есть свой ключ, параметры там... неважно, главное, есть такое:
IBM: Driver = {4D36E967-E325-11CE-BFC1-08002BE10318}\0000
Seagate(1): Driver = {4D36E967-E325-11CE-BFC1-08002BE10318}\0001
Seagate(2): Driver = {4D36E967-E325-11CE-BFC1-08002BE10318}\0002
Наверное, это оно? Судя по всему, «\Device\Harddisk0\DR0» это IBM...
Сейчас выключу эдак на недельку отключение винтов, посмотрю, если эта хрень в логах пропадёт, включу обратно ;-)
В настоящее время записи появляются со строгой периодичностью раз в сутки ;-)
|
| | | | | |
Не факт 23.07.04 14:29
Автор: amirul <Serge> Статус: The Elderman
|
> IBM: Driver =
> {4D36E967-E325-11CE-BFC1-08002BE10318}\0000
> Seagate(1): Driver =
> {4D36E967-E325-11CE-BFC1-08002BE10318}\0001
> Seagate(2): Driver =
> {4D36E967-E325-11CE-BFC1-08002BE10318}\0002
Я тоже сначала подумал на номера. Но во первых там могут быть совсем не номера (это просто подключи в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class), а во вторых девайс классы насколько мне известно PnP manager-ом используются только для загрузки class-фильтров (все остальное используется при установке/просмотре устройств в Device Manager-е и т.п.). Первичен все таки ключ Enum. Он и просматривается начиная с Root-а. Все физические шины попадают в HAL (или HAL_ACPI), а остальные устройства энумерируются уже на шинах.
> Наверное, это оно? Судя по всему, «\Device\Harddisk0\DR0»
> это IBM...
Лучше посмотри в каком порядке энумерируются подключи SCSI
> Сейчас выключу эдак на недельку отключение винтов,
> посмотрю, если эта хрень в логах пропадёт, включу обратно
> ;-)
> В настоящее время записи появляются со строгой
> периодичностью раз в сутки ;-)
|
| | | |
Я отвечал по ситуации Killer{R}... 23.07.04 11:45
Автор: Garick <Yuriy> Статус: Elderman
|
> Про ремап - нет, наврядли. Винты SCSI, 15000RPM IBM
> (загрузочный) и два Seagate, совмещённые в RAID0.
> Кстати в логах есть ещё записи, что контроллер SCSI не
> ответил за отведённое ему время...
а где своп лежит?
>
> Предполагаю, что виновато отключение винтов во время их
> простоя, а потом долгая их раскрутка, поскольку все записи
> помечены временем после часа ночи, как раз "тишина" на
> серваке.
Похоже на то... таймауты
> Как думаете, если эти записи в логах просто дибилизм от M$,
> стоит ли на них забить, или же лучше, чтобы винты вообще не
> отключались?
скайзи винты расчитаны на 100 ПВ (продолж включ) и при правильном охлаждении, можно не отключать.
А можно настроить тайматуты дисковых операций (может быть, я не знаю как) или забить, если потерь инфы нет.
|
|
Та же беда 23.07.04 09:18
Автор: Slava_Verbov Статус: Незарегистрированный пользователь
|
|
У меня вин хр рус без сп. Иногда запись в журнале появляется при загрузке системы, во время текущей работы ещё ни разу не появлялась...
|
|
|
подробно о проекте
Анализ криптографических сетевых...
