41 ответов в этой теме

[slig]

В феврале Microsoft выпустила патч для WINXP SP1 32 и 64 bit, который исправляет ни много ни мало ошибку:

Физическая порча винчестеров объёмом более 130 ГБ при мертвяцком зависе операционной системы и при уходе в различные состояния сна...
помню лишь номер статьи - ищите на сайте производителя:

331958

Такие дела

[422digital]

This update addresses the "Hard Disk May Become Corrupted When Entering Standby or Hibernation" issue in Windows XP. Download now to protect the hard disk when entering Standby or Hibernation.

_http://www.microsoft.com/downloads/details.aspx?familyid=b997cc5f-4483-4edc-a17e-6f659a033b0d&displaylang=en

File Name: Q331958_WXP_SP2_x86_ENU.exe

Download Size: 394 KB

Date Published: 1/22/2003

Version: Q331958

[Alf_Zetas]

Билл Гейтс собрал все (почти) хотфиксы в одну упаковку - 9МБ

http://download.micr...939-x86-ENU.exe

[slig]

Верно. Правда, этот фикс в этой упаковке отсутствует. Вообще, чтобы увидеть все фиксы, выпущенные после sp1 - идите по ссылке:

http://support.micro...&MaxResults=500

[Alf_Zetas]

atapi.sys в этой упаковке в наличии

там даже есть исправления не выходившие (официально) в виде отдельных хотфиксов - пресловутое исправление тормозов П4 с хипертрейдингом после установки СП1

[slig]

Наверное ты прав, Zetas - я просто просмотрел список обновлений, включённых в этот пакет - и этого там не нашёл. Видимо, Майкрософт намеренно не написала об этом, чтобы шум не поднимать по поводу посыпавшихся винтов...

[-VAG-]

Сам наткнулся на эти грабли купив и установив два винта 180Гб и 200Гб
Мамка их видит без проблем, GHOST и PM c ними работают без проблем, но дальше чудеса..
их описывать не буду, а вот почему это происходит и как с этим бороться я понял.
У всех Win - ограниченная разрядность при адресации к ФИЗИЧЕСКИМ данным на винчестере и это все портит. Выглядит это следующим образом, вне зависимости от деления НЖД на партиции и на логические диски при обращении WINдами за 137-ой Гб формируется обращение (из-за переполнения) на первый Гб. Т.о. запись данных за 137Гб границу приводит к РЕАЛЬНОЙ записи в начало винта. Там обычно стоит операционная система. При этом часто происходит полное уничтожение данных (перетирание) в независимости от файловой системы. ОС с такими винтами живет не долго, а именно до тех пор, пока вы не скините в "конец" диска что-нибудь.. Я прошел через эти стадии не раз (говорила мама - учись на ЧУЖИХ ошибках!). Причем один раз уже почти простился с диском (перетерлась таблица разделов и МВР). т.е. винт вообще потерял разбивку, а в разных программах (PQM, Fdisk) показывал страшенные цифры размеров партиций и логических дисков..
Наконец я нашел то, что искал в сети.

здесь http://www.computery...ранить
и здесь http://www.computery..._106.htm#Как

Сохранить и удержать

Очень прошу помочь понять и решить неожиданно возникшую у меня проблему с сохранностью данных. Maxtor на 160 Гб (с 8 Мб кэша) стоит вторым винтом (IDE 1, Slave) на материнской плате ASUS A7V266A. Памяти - 512 Мб. Система - Windows Me. Прошивка BIOS и набор VIA 1-in-4 - одни из последних. И BIOS, и Windows прекрасно видят диск и все его 160 Гб (для простоты везде пишу неправильные Гб).

Диск разбит на два раздела - 30 Гб и 130 Гб. Все прекрасно работает, пока данные не попадают в область второго раздела после 101 Гб, то есть в область диска после 131 Гб (30 + 101). Но если что-нибудь записывается с другого винта в эту область на второй раздел, то повреждается часть файлов на первом разделе. Причем имена, размер и атрибуты испорченных файлов могут не измениться, а их содержимое полностью (чаще всего) или большими блоками полностью портится. Большинство файлов на этом винчестере - звуковые, по 30 - 100 мегабайт.

Один раз, когда Sound Forge подправил и все-таки открыл один такой испорченный файл на первом разделе, то первая половина "звука" осталась нетронутой, а вторая содержала фрагмент, записанный с "рэка" в проблемную область второго раздела и потом удаленного! Этого "звука" больше нигде не было. Вероятно, из-за чего-то переклинило адресацию. Симптомы проблемы установлены мной благодаря упорным наблюдениям, долгим опытам и бесконечным сравнениям (перезаписи 10 - 20 Гб туда-сюда).

Порог в 131 Гб выбран, так как, во-первых, у IDE-канала это закладывалось как предельное значение, и, во-вторых, если этот винт повесить на встроенный RAID, то просматривается только 131 Гб. Временно урезал с конца второй раздел до 101 Гб так, чтобы суммарный объем двух разделов составил 131 072 Мб. Все долго и упорно проверял - данные не летят.

В чем проблема? В диске, материнке или "винде"? И как ее решить? Жалко ведь 30 Гб. SMART-параметры винта всегда были в норме. Систему я вычистил от мишуры и содержу в строгом порядке. Вирусов нет. Не хотелось бы пока уходить с Windows Me, так как мне ее хватает и там много настроенных рабочих программ и примочек. Может, поставить драйвер какой-нибудь? Если же все-таки придется менять "винду", то будет ли подобная проблема в Windows 2000 / XP?


Ответ на подобный вопрос я уже приводил в одном из номеров Upgrade, но ваш случай довольно интересен благодаря подробно описанным симптомам сбоя, а потому вкратце отвечу еще раз.

Большие диски становятся все более популярны, и народ начинает повсеместно наступать на одни и те же грабли. Если ваш BIOS видит полный объем диска, то проблема только в операционной системе: Windows 9x не поддерживает 48-битную адресацию. И вам надо переходить либо на Win-dows 2000 SP3, либо на Win-dows XP SP1, так как только в этих системах появилась поддержка режима BigLBA (еще раз обратите внимание, что BIOS тоже должен иметь поддержку BigLBA). Даже более того - после установки сервис-паков BigLBA надо еще и включить вручную в реестре:
HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Services\
Atapi\Parameters
"EnableBigLba"=dword:00000001

Не забывайте, пожалуйста, о том, что в процессе активации режима BigLBA (что, как мы видим из вашего случая, обязательно для любого диска с 48-битной адресацией, то есть более 137,4 Гб) с небольшой вероятностью вы можете потерять все данные на диске, поэтому не забудьте про резервное копирование. Учтите, что операционные системы, которые изначально не имеют поддержки BigLBA, - а такие на сегодня все Windows - нельзя устанавливать в раздел, расположенный за пределами первых 137 Гб.

Обратите внимание, что SP не снимают этой проблемы до конца. В любом случае необходимо вручную править реестр, а так же сто раз подумать, что будет если на этот винт вы загрузитесь с ДРУГОЙ операционной системы (диск-реаниматор, win98, PC-DOS) и полезете на 137-ой ГБ...
В результате на 180Гб винте я "выкинул" (unused) 40Гб с крокодильими слезами на глазах, а 200-ку использую "на полную", но на ней нет ни каких ОС - только данные (видео) и то с наличием резервных копий.
Указанный постом ниже патч от мелкософта спасает только от проблем при "засыпании" диска. Для настольного компа я лично всегда отключаю режим энергосбережения.
Вот такая паршивая жизнь.

По секрету - читал, что WIN2003 исходно поддерживает BigLBA, но живой win2003 я не видил.

Александр

[DenizZ]

Только что проверил эту строку в реестре (win2k.sp3) - я ничего сам не правил, там всё именно так и есть!
Правда, никогда не работал с дисками больше 80Гб.

[-VAG-]

Только что проверил эту строку в реестре (win2k.sp3) - я ничего сам не правил, там всё именно так и есть!
Правда, никогда не работал с дисками больше 80Гб.

Значит слухи верны
Но вот то что диски большие в продаже уже есть, а как с ними работать не продавцы не (в большей степени) покупатели не знают - это настораживает..
это я о больном - 40 Гб псу под хвост...

Александр.

[iliuxa]

не понял до конца - я уже прикупил 2 харда по 200G
у меня стоит ХР sp1 мать intel 850, и что таперь делать?

[-VAG-]

не понял до конца - я уже прикупил 2 харда по 200G
у меня стоит ХР sp1 мать intel 850, и что таперь делать?

Первое - забыть на всегда про мультизагрузку (только XP SP1 и ничего больше).
Второе -отбить первичный партишен под ситему и ее туда поставить (это если диск/и будет/будут загрузочнным/и)
Третье - после SP1 в реестре добавить ключ HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Services\Atapi\Parameters : "EnableBigLba"=dword:00000001
И перегрузиться.
Четвертое - оключи режим сбережения для винта (чтоб не засыпал) и поставь патчи от мелкософта на эту тему.
Пятое -ТОЛЬКО ПОСЛЕ ЭТОГО в менеджере дисков XP разбить оставшееся свободное место под свои нужды, форматить и пользовать. (форматирование ДО может повлечь за собой потерю диска(не безвозвратно)/системы(безвозвратно))

Не плохо бы сделать еще и апдейт виоса мамки (у меня INTEL865PERL держит большие винты но виос я все равно себе обновил), возможно будет надежнее работать мама с винтом. Последний BIOS для твой мамки P25. Вот ссылка на биосы к 850(единственое, я не знаю точно что именно за мама у тебя (какие буквы в названии), поэтому выбери биос сам)

В биосе рекомендуют также отключить режим SMART (самодиагностика винта), если планируется работа с видеопотоком на запись (оцифровка)


PS шестое, седьмое, и все остальное - регулярно сливай образ системного диска и других важных дисков, например, GHOSTом (только не на тот же винт!!!, лучше на болванки CD или DVD - последняя версия может это делать прямо из под "DOSа") - это резко сократит время восстановления системы и поток не нормативной лексики в течении этого процесса.

PPS - молись, если умеешь , чтобы позже еще не обнаружилать у мелкософта какая-нибудь "бяка" при работе с большими винтами, и не нашлись бы какие-нибудь умные программы (дефрагментеры, сжиматели, кодировщики содержимого диска и пр.), которые захотели бы работать с диском НАПРЯМУЮ, но с ограниченной разрядностью...

[iliuxa]

Большое человеческое спасибо
понятно что
"...ложки нет"

- На самом деле самого дела нет. В самой деятельности заключена самость дела - и наоборот.
Наоборот получим оборот на, и таким образом перевернем образ. Я уже не говорю о природе говора в роде при уже. Ужи и узы - вы меня понимаете, мистер Андерсон?
- Конечно, я так и думал, Смит. Дай еще затянуться.

наверное по этому принцибу живут в мелкософте

[-VAG-]

наверное по этому принцибу живут в мелкософте

Я их не осуждаю... У них проблем и так выше крыши
Были и другие ограничения, вспомни, - 2Гб на FAT16, 8Гб у БИОСов мамок для HDD, придуманное мелкософтом ограничение на 32Гб для FAT32, ограничения на размер файла в FAT32.. 1Гб оперативки для Win 95, 2Гб для WinME.. правда не одно из этих оганичений не уничтожало систему и данные на дисках... Но они учатся . Возможно скоро про ограничение в 137Гб мы забудем.. (правда нет уверенности, что не вспомним про другие )
Ты не один, я нахожусь в точно такой же ситуации (если это тебя как-то взбодрит )

Сообщение отредактировано -VAG-: 22 Nov 2003 - 15:53

[iliuxa]

просто ситуация следущая - еле еле уговорил шефа покупать диски для бекапов проектов, вместо DLT лент
ведь сейчас одни из оптимальных по цене и объему это 200Gb
а тут такая подстава от мелкософтов и еще при том что уже куплено 2 диска, будет жутко не здорово если винда продолжая писать на хард после 137 gb начнет стирать ранее записанные проекты.

Не забывайте, пожалуйста, о том, что в процессе активации режима BigLBA (что, как мы видим из вашего случая, обязательно для любого диска с 48-битной адресацией, то есть более 137,4 Гб) с небольшой вероятностью вы можете потерять все данные на диске,

- это реально?

[-VAG-]

- это реально?

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

В твоем случае с бэкапированием проектов надо быть КРАЙНЕ осторожным, чтобы этот винт ни в коем случае не попал под другую ОС c неустановленным BigLBA. Если винты не съемные, это проще (шансов меньше испортить) только формати тогда в NTFS5 - меньше соблазнов будет влезть на диск из по 98-х и не потребуется бить на много дисков по 32Гб в случае как с FAT32 (правда я форматил 80Гб в FAT32 и все после этого работало не плохо, но всякие дефрагментации и прочие "сжатия" я не запускал на такой раздел - страшно..)
Внешних USB->IDE или IEEE1394 -> IDE c 48 битной шиной IDE я так и не смог найти (по крайней мере среди офицальных параметров этих девайсов такой параметр вообще отсутствует и я "по умолчанию" считаю что IDE не 48-битный)
Либо, как вариант, отбей на нем 137Гб, а остальное в UNUSED... до поры до времени. Тем более, что лично у меня винт 200Гб это 200 000 000 000 байт, т.е. 186,3 ГБ (бинарных) - теряем 50Гб, а не 70Гб..
Здесь нас тоже слегка дурят..

Не в тему:
================
Два программиста. Один другому:
- вот представь, что у тебя есть 1000 баксов, ну или для круглого счета -1024 ..
================
Что отличает пользователя от программиста.
Первый считает что в килобайте 1000 байт, второй точно уверен, что в килограмме 1024 грамма..

Сообщение отредактировано -VAG-: 23 Nov 2003 - 21:00

[Zdpn]

Если имеется motherboard с чипсетом интел, то поддержку винтов >137 можно осуществить с помощью Intel® Application Accelerator
http://www.intel.com...ets/iaa/lba.htm
При этом драйверы MS будут заменены на драйверы из состава IAA.

[-VAG-]

2 Zdpn
Спасибо за добрые вести! Не М$ так Intel ! (и почему последний я больше уважаю... )

2 ALL
Кто проверит в работе эти драйвера (и еще чтоб не какие последующие фиксы и сервис паки от мелкософта не подменили бы их с дуру на свои "улучшенные") сообщите, пожалуйста результаты - очень жалко проводить эксперименты на своих "заполненные" подзавязку винтах...

[-VAG-]

За пост до этого я был не корректен (читай не прав, обманут, запутан, не компетентен ) по отношению к цифрам 137 Гб. у всех источников на кои я опирался речь шла о 137 ДЕСЯТИЧНЫХ Гб что эквивалентно 128 БИНАРНЫХ Гб..

вот интел и поставил меня на место..
http://www.intel.com...aa/lba_test.htm

В зависимости от используемого программного приложения расчет объема жесткого диска более 137 ГБ может быть не вполне корректным по причине способа вывода информации.

Жесткие диски объемом менее 137 ГБ обычно имеют 28-битную конфигурацию LBA. Ниже приводятся примеры расчета объема 128 ГБ жесткого диска:

(2 ^ 28 секторов) x 512 байт = 137438953472 байт = 134217728 КБ = 131072 МБ = 128 ГБ

При объеме жесткого диска более 128 ГБ, его структура становится 48-битной. Приведенные выше расчеты основаны на том, что 1 КБ = 1024 байт.

При расчете в предположении 1 КБ = 1000 байт общий объем получится 137.439853472ГБ.

Данная информация важна для определения того, правильного ли Ваша ОС распознала общий объем жесткого диска, размером более 137 ГБ. Если ОС или приложение показывает общий объем жесткого диска, как 131072 МБ, это значит, что она распознала только 128 ГБ и в данный момент не имеет доступа к 48-битной конфигурации диска.

настораживает это
http://www.intel.com...aa/lba_test.htm

Соблюдайте осторожность: Выполнение программы тестирования на компьютерных системах, использующих неподдерживаемые ОС, например, Windows* XP, Windows* 2000, и Windows NT* 4.0 приведет к
ошибке 'NTVDM.EXE'.

и это
http://www.intel.com...s/iaa/me_se.htm

При работе в ОС Windows* Me, Windows 98 Second Edition и Windows 98 нередко возникают случаи, когда программный пакет Intel® Application Accelerator оказывается неспособным снять ограничение на максимальный поддерживаемый объем дискового пространства (137 ГБ).

Это происходит вследствие того, что операционные системы Windows Me, Windows 98 SE, Windows 98 и BIOS системной платы в настоящее время не поддерживают 48-разрядную адресацию LBA. Подробнее об этом смотрите на странице Поддержка 48-разрядной адресации LBA средствами BIOS

Тем более, что список мамок (чипсетов) не так велик как хотелось бы..
http://www.intel.com...aa/suppchip.htm

Программный пакет Intel® Application Accelerator поддерживает следующие наборы микросхем Intel®:

Набор микросхем Intel® 810
Набор микросхем Intel® 810E
Набор микросхем Intel® 810E2
Набор микросхем Intel® 810L
Набор микросхем Intel® 815
Набор микросхем Intel® 815E
Набор микросхем Intel® 815EP
Набор микросхем Intel® 815G
Набор микросхем Intel® 815EG
Набор микросхем Intel® 815P
Набор микросхем Intel® 820
Набор микросхем Intel® 820E
Набор микросхем Intel® 840
Набор микросхем Intel® 845
Набор микросхем Intel® 845E
Набор микросхем Intel® 845G
Набор микросхем Intel® 845GE
Набор микросхем Intel® 845GL
Набор микросхем Intel® 845GV
Набор микросхем Intel® 845PE
Набор микросхем Intel® 850
Набор микросхем Intel® 850E
Набор микросхем Intel® 860

[ati78]

Еще есть:

Intel® Application Accelerator RAID Edition
Product Overview

The Intel® Application Accelerator RAID Edition software package provides support for high-performance Serial ATA RAID 0 arrays and redundant RAID 1 arrays on select Intel® 865 and 875 chipset-based platforms using Windows* XP or Windows 2000.

Он поддерживает новые чипсеты 865 и 875
Пока есть баги с Неро

[iliuxa]

а как можно протестить hard на предмет 137 глюка -
я сделал все телодвижения на тему активации 48bit BigLba,
но пока средствами только мелкософта, без Intel® Application Accelerator,
вот теперь думаю работает это все или нет

Сообщение отредактировано iliuxa: 26 Nov 2003 - 18:23

[DaLiV]

zapishi na disk 150 gigov infi
esli disk poheritsja - znachit privet - ne rabotajet

[Zdpn]

"Обычный" IAA поддерживает еще E7205, новый Intel® Application Accelerator RAID Edition только Intel® 865 and 875 chipset-based platforms с ICH5R и обязательно raid массивом SATA. Безp этих условий не ставится. Когда будет для ICH5 без R и sata - не известно.

[iliuxa]

а если разбить диск на 135 и остальное а затем на это остальное писать ?
просто так с ходу не найду мусора и времени
150 gb забивать

[DaLiV]

mozhesh i tak

[-VAG-]

а если разбить диск на 135 и остальное а затем на это остальное писать ?
просто так с ходу не найду мусора и времени
150 gb забивать

Да. именно так и можно проверить.
Но при этом все равно прийдется "забивать" часть диска информацией.
Могу предложить такой метод:
-бъем диск, например так:
-первичный 10 Гб
-вторичный партишин - все остальное
-во вторичном - логические по 10 Гб
первые 2..3 забиваем чем-то (см.ниже), потом 13,14,15 тоже чем-то забиваем, далее проверяеем целостность информации на первых дисках.
Основная проблема - проверка целостности информации.
1. Если "чужая" запись влезла на таблицу FAT "первых" дисков, то не заметить искажения файловой системы просто не возможно (визуально, скандиск и пр.) При этом достаточно "подпортить" 1-2Мб..
2. Если "чужая" запись влезла на "место хранения тела файла" уже имеющегося на диске, то не всегда удастся обнаружить проблему быстро. Для этого нужно проверить CRC всех файлов и соответствие фактического размера и "заявленного в FAT" (скандиск, чекдиск, дефрагментеры). Чтобы повысить вероятность "порчи" писать надо уже значительно больше, хотя естественно может хватить и 1кб..
3. Самый плохой случай - Если "чужая" запись влезла на то место диска где нет файлов вообще. В таблице FAT эти кластеры все равно остаются помеченнымии как "пустые" и при записи на "нижний" диск они (кластары) будут перезаписаны корректной инфомацией.. Скандиск, чекдиск, дефрагментеры - здесь не помогу.
4. Самый "хороший" случай - "чужая" запись влезла на МВR.
Все диски "похерелись" - количество дисков, их размеры и вообще может не оказаться ни каких дисков и партишинов (фдиск,PQM и пр.)
Что предложить для увеличения вероятности обнаружения проблемы 137?
вариант 1 маловероятен,
вариант 2 лучший для нас
вариант 3 не очевидность проблемы 137
вариант 4 проблена на лицо, но вероятность мала (надо хорошо прицелиться)
Пробуем, тогда, реализовать вариант 2
Я бы поступил так:
Первые диски ПОЛНОСТЬЮ забил бы файлами размером в 100-500 байт. Такие файлы занимаю целиком один кластер. Писаться они будут быстро. Их будет ОЧЕНЬ много на диске. Дальнейшее определение их "порченности" будет простым. "Дальние" диски забил бы большими файлами (скопируй пару DVD, например).. Далее скандиск или что-нибудь подобное на "первые" диски..
если не получишь четвертый вариант сразу
ЛИБО, попытаться прицелится..
Поскольку до этого предлагалось заиметь две достаточно большие области
с данными и искать их перекрытие, можно поступить иначе - иметь небольшую "контрольную" область "внизу" и писать в дальнюю область до тех пор пока не испортится "контрольная" зона..
Ну и конечно не исключен вариан "математический". Т.е. расчитать куда именно отображаются данные с "верхних" дисков на "нижние". Тут, к сожалению, все завит от физической конфигурации диска (головки, цилиндры, сектора) и от того КАК именно реализован алгоритм LBA(виртуальной подмены мнимых головок, секторов,цилиндров на их физические аналоги). С такими расчетами я не помогу..Тем более как показывает практика считай-не считай, а все равно ошибешься

Диски сейчас быстрые (проверь, установлен ли у тебя режим DMA - это резко повысит скорость работы с диском) и методом "научного тыка", я думаю за несколько часов ты получишь ответ на свой вопрос...
На практике у меня это получалось за пол дня (не ТЕСТИРОВАНИЯ, а работы с РЕАЛЬНЫМИ файлами и их реальной ПОТЕРЕЙ - далее следует ненормативная лексика с моей стороны в свой же адрес и адрес мелкософта...)

Где взять "мусор"? Создай его в геометрической прогрессии:
Создаем в отдельной папке файл размером 100..500 БАЙТ (например текстовый в блокноте).
Создаем его копию.
Выделяем уже два файла и создаем их копию.
Далее выделяем полученные четыре файла и делаем их копию....

============== не втему ==============
Программист ушел на минут в душ помыть голову. Нет его час, второй, третий...
Колеги начали волноваться, заходят в душ и видят:
измученный программист, вокруг куча пустых пузырьков из-под шампуня, в тысячный раз читает и тупо выполняет инструкцию с флакончика  шампуня
1. нанести небольшое количество шампуня на влажные волосы
2. растереть и через две-три минуты тщательно промыть голову
3. процедуру повторить
==================================

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

Рекомендую
- отключи поддержку BigLBA, получи проблему, включи поддежку BigLBA, повтори тот же эксперимент и убедись, что проблема не возникла... Иначе тебя будут мучать сомнения типа "а в д р у г ??? "
- образы первых дисков с мусором сохрани GHost`ом - они (данные) "рыхлые" и отлично будут сжиматься и легко восстаноавливаться..
- в качестве систеного используй другой физический диск - меньше потом проблем с восстановлением работоспособности ОС (она может пострадать в ходе исследований)
- используй FAT

[shuster]

к слову о птичках:
у меня стоят два винта 120 + 200. пользуюсь уже пол года.
поначалу не знал как подступиться, в итоге грхнулось все 200GB.
все готовые проекты которые надо было сдавать вчера.
озверел...
стал бомбить Intel and Maxtor - дали ссылки, скачал - работает тьфу, тьфу уже вот пару месяцев без сбоев. Все делал по инструкции.

[-VAG-]

озверел...
стал бомбить Intel and Maxtor - дали ссылки, скачал - работает тьфу, тьфу уже вот пару месяцев без сбоев. Все делал по инструкции.

Аналогично! мы друг друга понимаем... к твоему "тьфу, тьфу" еще одно мое тьфу (для порядку)
Остальным - не повторяйте наши ошибки! Угробить проект в 200Гб это не тоже самое, что запоротая дискета..

[iliuxa]

shuster, ты бы написал куда и какие ссылки тебе дали

стал бомбить Intel and Maxtor - дали ссылки, скачал - работает тьфу, тьфу уже вот пару месяцев без сбоев. Все делал по инструкции.

[422digital]

А как дела обстоят с большими винтами, подключенными по USB2.0 или IEE1394 интерфейсам?

[iliuxa]

в зависимости от того как с ними работают сами коробки

[-VAG-]

Я уже писал ранее, что на текущий момет я не смог найти очевидных свиделельств поддержки такими "коробками" больших винтов.
Этот параметр умалчивается в описаниях, а я "по умолчанию" считаю что ее (поддержки) нет. Возможно я не прав, т.к. текущая (описаная здесь) проблема корнями уходит в ОС а не в железо.. А как мне удалось выяснить мамок с поддержкой больших винтов (в контексте темы) уже ОЧЕНЬ много. Т.е. на уровне BIOSа (особенно после его обновления) многие мамки корректно работают с ними (винтами). Возможно в равной степени это может быть отнесено и к "коробкам". Я лично пользовал не дорогие китайские "корбочки" фирмы Cronos http://www.chronos.c...e/enclosure.htm практически весь модельный ряд размера 3.5 и 5 и usb и ieee (кстати, не плохие впечатления). Покрайней мере винт видится целиком, но из под WinXP работать с ним полноценно не удалось.. Мало того я "потерял" один винт целиком при форматировании "хвоста".. И реанимировать его удалось только подключив к мамке с 865 чипсетом и переразбивке (еле удалось снести "старую" разбивку с абсолютно абстрактными значения размеров партиций и пр.).. Иначе он в "коробке" больше не виделся. После переразбивки и форматировании на мамке он вность стал доступент и в "выносном" варианте.. Говорят что тоже относится и к более дорогим Datafab Systems http://www.datafab.c...atalog.asp?ID=2 но сам я не пробовал - небыло задач..
Для данных устройств, видимо, не маловажную роль играют еще и дравера. Т.е. как ОС "видит"этот винт...

[iliuxa]

на савеловском купил китайскую коробку,
внешний вид как у SATA коробок на www.highpoint-tech.coм,
так на ней было написанно full support maxtor 160 gb
а при подключении в нее IBM 120 она работала по 1394 на скорости чуть выше чем USB1.0 - 3mb/s вместо 38mb/s, в итоге пришлось поменять ее на sarotech (у нее ни где не написано про большие диски а сам их туда пока ставить побаиваюсь)

[alexandrnew]

Привет ВСЕМ! У меня лично ASUS P4C800 с SATA RAIDом на борту чипсет 875, драйвера имеются только в Intel® Application Accelerator, это меня и спасло, вроде как, но со временем увидим.

[iliuxa]

таки и ко мне пришла беда все сделал как описанно VAG и на сайте мелкософта
Win Xp SP1 + все патчи на тему 137гб + правка реестра
новый биос матери intel 850 EV и биос HighPoin 133 контроллера, на котором собственно диск и весит
записал на диск 140 гиг бекапов и вот оно - некоторые файлы записанные самыми первыми на чистый диск ПАПОРТИЛИСЬ
это были AVI объемом по 200-400 метров,
имена остались но при просмотре у них не реальные данные
типа резолюшн 0х0 0bit и т.п
Напишите у кого данная проблема 137 решилась и на какой конфигурации (если не сложно,напишите какие настройки сделали после чего заработало)

[Zdpn]

Asus P4g8x (чипсет E7205), Bios BIGLBA поддерживает.
HDD 40GB Master + WD160JB (160 GB) slave. BigLBA в реестре не "включал", использую IAA. WD имеет FAT32 и NTFS разделы. Multiboot (98 +XP) Пока все нормально.

[422digital]

>биос HighPoin 133
Не в нем ли проблема? Помнится когда были IBM DTLA, то они прежде всего сыпались на этих контроллерах ( HighPoin ). Хотя у меня на P4PE стоят 2 DTLA и пока работают (чтоб не сглазить).

[iliuxa]

у меня еще ни разу DTLA на нем не сыпались
Zdpn, а ты 160 забивал на полную емкость ?
как после этого все данные в порядке?
мне просто нужен одним партишнм в NTFS диск под архивацию
я где то слышал что после IAA диск надо на логические бить - или нет

[Zdpn]

iliuxa
Полностью не забивал, NTFS партиция в конце, у меня каждому члену семьи своя ось свои разделы.... Диск бил в Partition magic после iaa.

[-VAG-]

мне просто нужен одним партишнм в NTFS диск под архивацию

К нашему общему сожалению, насколько мне удалось выяснить, ключевую роль в этом безобразии имеют две вещи. Первая - это "аппаратная" поддержка, т.е. мама и BIOS, вторая - ОС. Самое страшное в этом то, что на разбиение на партишены (в том числе и одна целиковая партиция), ни их количество, ни варианты файловой системы (включая NTFS5) не решают этой проблемы. Увы..
т.е. можно смело иметь одну партицию на 160Гб в NTFS5 и если общая проблема 137 решена , то и в данном случае ослажнений не будет. Но если проблему 137 на компьютере не решили, то проблема с данными будет. Даже видимо, проблема будет очень глобальной, т.к. для ее возникновения прийдется ПОЛНОСТЬЮ забить данными диск и есть шанс их ПОЧТИ полностью или ПОЛНОСТЬЮ потерять.. При разбиении на партиции есть шанс, что отдельно взятые "диски" уцелеют.

2Zdpn

Asus P4g8x (чипсет E7205), Bios BIGLBA поддерживает.
HDD 40GB Master + WD160JB (160 GB) slave. BigLBA в реестре не "включал", использую IAA. WD имеет FAT32 и NTFS разделы. Multiboot (98 +XP) Пока все нормально.

К великому сожалению, это почти мой случай (кроме железа, но мама BIGLBA тоже держит). И к моему великому сожалению, "пока" длилость около 3 месяцев до той поры пока я не подзабил "верхнюю" часть slave`а... Потом еще и мастера поменял с 120 на 160, а на слэйва 200 повесил.. Но разобравшись в чем проблема на загрузочной (мульти загрузка - bootmagic) 160-ке отрезал в хвосте кусок и оставил его для всех систем в UNUSED`e. т.е. оставил доступными 135Гб в "нижней" части диска.. И меня ни какими каврижками не убедить использовать этот кусок , тем более на мультизагрузочном диске.. (переставлять или вытаскивать из имиджей несколько ОС + потерянные(отсутствующие в имидже) данные..БРР....) Спокойствие для меня дороже..

Zdpn - мой тебе совет сделай тоже у себя или
ВКЛЮЧИ у XP BigLBA, отбей "задний" диск (от 135 и до конца), отформатируй его в NTFS5 чтобы другие ОС его не видели и пользуй его ТОЛЬКО под ХР.

Кто ЕЩЕ не терял 100..200 Гб данных, тот меня может и не понять.. Для остальных - это трагедия, преждевременные седины и полное понимание того как НАДО БЫЛО делать, к сожалению.
Кстати, PQM - вполне корректно работает с "хвостом"..


2iliuxa

некоторые файлы записанные самыми первыми на чистый диск ПАПОРТИЛИСЬ
это были AVI объемом по 200-400 метров,

Не падай духом, если BigLBA включен, то возможно потеря вызвана не проблемой 137.. Это может быть проблема кэширования данних ОС перед записью на диск. Точнее не корректным "освобождением кэша". Попробуй отключить кэширование записи на диск и осторожно поработать, рьяно наблюдая за системой..
В том же PQM можно ориентировочно оценить вылезли данные за 137 или нет..
Можно это пробовать оценить по штатному дефрагментатору, только не запускай его на дефрагментацию -если проблема есть, то тем самым ты ее усугубишь!.
Естественно, надо помнить, что объем данных на диске и их "физическое расположение" разные и для данной проблемы это очень критично..

PS. Помоему, меня пора прибить за "длинный язык" и повторяемость..

[-VAG-]

2iliuxa

QUOTE 
некоторые файлы записанные самыми первыми на чистый диск ПАПОРТИЛИСЬ
это были AVI объемом по 200-400 метров,


Не падай духом, если BigLBA включен, то возможно потеря вызвана не проблемой 137.. Это может быть проблема кэширования данних ОС перед записью на диск. Точнее не корректным "освобождением кэша". Попробуй отключить кэширование записи на диск и осторожно поработать, рьяно наблюдая за системой..

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

По-моему - Жванецкий..
=======
В очереди к врачу, больные между собой..
- И что у вас болит бабушака.. Голова? и что? Приписали уколы? Куда- в голову? нет.. а куда? КУДА?? Ну вы подумайте- какя связь!

=======
У ухо-горло-носа
-Доктор у меня в ухе вилка...
-Извините, больной, но уменя на сегодня прием закончен (выдирает вилку из уха больного и втыкает ему ее в глаз!).. Обратитесь к окулисту. Он еще два часа сегодня принимает..

[iliuxa]

а может это и еще проблема самого ХР , с копированием файлов в 2000 раньше проблем не было а сейчас переодически стали возникать - перекидываю по сети файлы .ас3 а они оказываются битыми, перкидываю второй раз и все работает.
вроде и на вирусы постоянно проверяюсь.

[-VAG-]

... проблема самого ХР , с копированием файлов в 2000 раньше проблем не было а сейчас переодически стали возникать - перекидываю по сети файлы .ас3 а они оказываются битыми, перкидываю второй раз и все работает

Отключи кеширование записи на диск и понаблюдай. Если и у тебя (как у меня) снимется эта проблема - сообщи пожалуйста. Это будет очень полезно для других.