Комментарии 74
До текущего момента, впрочем, грешил на своеобразие USB-3.0-контроллеров Etron EJ168 (опрометчиво устанавливавшихся на материнские платы Gigabyte 2011 года), особенно учитывая, что с ранними версиями драйвера Etron всё было ещё более впечатляюще (в частности накопитель частенько внезапно пропадал из системы, и исправили это лишь где-то через год), да и сейчас впечатления яркие — например, этот контроллер несовместим с USB-концентратором 4K-монитора Dell P2415Q.
Кстати, скрабы на массивах у меня раз в полгода выявляют парочку сбоев контрольных сумм на отдельных винтах (которые ZRAID тут же исправляет) — только уже не помню, на каком из массивов, поэтому называть производителя винтов не буду, чтобы не оболгать невинного (у меня разные есть).
В свое время очень много народа горя хлебнуло с этой серией.
В начале 200х я работал в вузе в отделе, который в т.ч. обслуживал все компьютерные классы. И прекрасно помню тот момент, когда ВНЕЗАПНО со всех сторон университета понесли компьютеры на ремонт. Потом блинами от этих дисков и магнитами все аудитории были завалены. До сих пор дома валяется один из них. :)
Все MPG были приговорены при рождении. Цирроз логики, а точнее разрушение микросхемы Cirrus Logic агрессивным припоем.
(причём, как слухи, у меня сдох один такой, а другой вот до сих пор как музейный экспонат храню — живой)) )
— Флюс там какой то агрессивный был и потихоньку ел снизу микросхему контроллера
— Ошибка в прошивке, в связи с чем всякие внутренние логи «когданть» затирали firmware на сервисной поверхности
Флюс-не флюс, но имело место повреждение компаунда процессора винта (Кстати говоря не известно, с этого случая, или ещё со времён видеокарт Currus Logic стали звать Циррозом Логики), со временем в компаунде выростали проводящие ток области, от чего чип откидывал копыта. Кому-то помогала заморозка винта, комуто прожарка, у кого-то он оживал отлежавшись пару месяцев, но во всех случаях оживал он не на очень большой промежуток времени. Добавило кайфа то, что часть адаптивов лежала на плате (по слухам — удешевление производства пластин, такчто старый вариант с хранением всех адаптивов на блинах перестал работать) и куча ремонтников напаролась на тот факт, что простое перекидывание платы (что делалось на квантумах тех времён (у этих винтов выгорал драйвер мотора из-за каких-то просчётов при разработке) винт не оживляло. Сегодня хранение параметров блинов в прошивке процессора уже никого не удивляет, а тогда удивило всех.
В ранних прошивках происходила следующая фигня — логи смарта со временем затирали куски таблиц адаптивов и прошивки. Была рекомендация для ранних прошивок — отключите смарт пока не выйдет новая версия.
Просто я не помню какая конкретно модель HDD Fujitsu на 20 гиг у меня когда-то на компе была, но именно вот такая проблема наличествовала — уж как я с этим винтом тогда намаялся…
Ранние WD в серебристых корпусах — половинки корпуса защищались от пыли проклейкой ленты, которая в случае слегка неаккуратного монтажа/демонтажа винта рвалась и винт работал пылесосом. В результате винту наступал кирдык. В недавнем прошлом стали пионерами удешевления корпуса ЖД, правда нагадило это только ремонтникам, которые эти вестерны вскрывали.
Сигейт — о сколько нам открытий чудных… тьфу, такого списка проблем я не видел ни у одного производителя, кстати говоря ихнее LBA=0 — самый свежий epic fail у производителей винтов.
IBM — DTLA, AVER. Познакомили весь мир со стеклянными пластинами(первый) и качественным контактом банки с платой (второй). Хз, но после авера бизнес почему-то был продан в Hitachi
Samsung — ранние винты от гнусмаса надёжностью не славились (дел с ними не имел, но те, кто имел почему-то вспоминают VICTOR V40 и ругаются)
Quantum — привет от TDA и привет от DMA. Сначала у квантума была болезнь с Windows 98 + DMA (винт как-то криво парковал головки и убивал себя), потом был сгорающий драйвер (TDA) мотора. После этого слово Fireball стало матерным. В скором времени контора кудато исчезла с рынка жестких дисков
Fujitsu — цирроз + баги в десктопных винтах. Исчезла с рынка десктопных и оставалась на 2.5 и SCSI после этого факапа
В скором времени контора кудато исчезла с рынка жестких дисков
And the Germans killed the Jews
And the Jews killed the Arabs
And the Arabs killed the hostages
And that is the news
Roger Waters.
Квантума пожрал Макстор, Макстора пожрал Сигейт. В итоге не стало лучше.
Хм. Во времена господства самосбора и IDE, ходило в народе эмпирически выведенное правило — стараться садить диск и сидюк на разные шлейфы, потому как на одном они они друг другу мешать будут…
(Напоминаю, primary/secondary — это шлейфы, а master/slave — позиция на шлейфе, определяемая либо джампером на винчестере, либо разрывом в 28-м проводе — Cable Select)
![image](https://habrastorage.org/getpro/habr/comment_images/c73/01e/8a1/c7301e8a1ae3f8de7337b9e6293b158b.gif)
Только пока контроллер передает данные на master, slave стоит и ждет, пока контроллер освободит шину. Поэтому высокая активность HDD мешает CD.
Возвращаясь к теме — когда он висел на одном шлейфе с жестким диском, то временами как бы захватывал его целиком — пока операция с диском не закончится (например, тот же разгон), доступ к жесткому диску также был блокирован. Когда разнес на разные шлейфы, такая проблема исчезла.
Ну и позднее, когда скорости устройств поднялись, на UDMA33 (33 мб/с) была уже видна разница в скорости копирования, когда устройства сидели на одном шлейфе и на разных.
нажимал eject и тут же обратно заталкивал лотокЭто Вам повезло, что кретивщики поленились имплементировать ATAPI полностью — в частности, команду «MEDIA LOCK».
пока операция с диском не закончится (например, тот же разгон), доступ к жесткому диску также была блокирован.А это, похоже, проблема в реализации драйвера, который должен был распознавать состояние «милый, я ещё не готова».
Но тут еще может быть то, что CD-ROM, скорее всего, работал только в PIO и не поддерживал UDMA. Вроде вешание именно таких двух устройств на один шлейф серьезно снижало скорость работы с жестким диском.
У меня была мистическая история, когда я подключал к параллельному порту внешнее устройство, то материнка при загрузке не видела SSD, при отключении устройства от параллельного порта, материнка при загрузке видела SSD и всё работало. При подключении устройства после загрузки тоже всё работало.
В итоге всё оказалось довольно банально...
В противном случае придётся:
- Прочитать данные исходного файла
- Подсчитать CRC
- Прочитать данные из скопированного файла
- Подсчитать CRC
- Сравнить подсчитанные CRC
Тогда как в моём случае достаточно
- Прочитать данные исходного файла
- Прочитать данные из скопированного файла
- Сравнить прочитанное
Почему-то мне кажется, что второй путь содержит меньше операций.
В каком-то там году типа 2002-2003 решил я обновить свою звуковую карту — на тот момент стояла у меня Create SB Live! (4-канальная), а захотелось мне
Про качество Live! 5.1 vs Live! — это отдельный разговор, его опустим. Но каково же было мое удивление, когда попытка декодирования ac3 вызывала падение системы в синий экран! Как в Windows 98, так и в ХР. Возможно, я бы так и не продолжил разбираться с этим, но обнаружил, что программное декодирование ас3 в PowerDVD тоже приводило к падению, но только программы. Стал разбираться — оказалось, падал декодер ас3, находящийся в ivaudio.dll (или как-то так), в общем, декодер от Intervideo. Дебаггер показал, что библиотека пыталась выполнить какую-то странную команду процессора и на ней успешно падала (команда оказалась от атлона, в Pentium 4 её не было). Стал копать дальше — зачем декодер пытается выполнить команду от атлона? Оказалось, что он неверно анализирует данные, возвращаемые CPUID и принимает решение, что у меня атлон.
Файл был успешно исправлен и программное декодирование ас3 заработало. Тогда уже полез в драйвер… и нашел там точно такой же код! Т.е. драйвер также ошибочно принимал мой новенький Pentium 4 за Athlon. Исправил hex-редактором драйвер для Windows 98 и, о чудо, декодирование заработало! В хр, к сожалению, так просто исправить не получилось — я тогда не знал про контрольную сумму, и после простого исправления драйвер более не загружался.
В общем, с описание проблемы, с кусками дизассемблера и адресами в памяти и файлах я обратился в поддержку Creative. На первое мое сообщение пришел ответ — «если драйвер считает ваш процессор Athlon'ом, возможно, вам следует обратиться к продавцу вашего процессора». Уже неплохо. После объяснения проблемы еще раз более детально, пришел еще более серьезный ответ — «В таком случае, найдите на нашем сайте (Creative) адрес команды разработчиков драйвера и попробуйте обратиться с этой проблемой к ним».
И ведь я даже пытался этот адрес найти, но не нашел.
Позже я выкинул Live! 5.1 и с большим удовольствием перешел на Audigy 2, на котором и просидел до 2013 года.
Здорово, что поддержка фуджици оказалась на уровне!Как говорят в деревнях, «авотх… вост!». Как Вы могли заметить из преамбулы письма, это был инженер, с которым я за два года до этого общался по поводу другой проблемы с фуджиками, поэтому я в этот раз написал ему напрямую. А как я его выцепил в первый раз — это уже совсем другая история…
То есть приквел будет? Ждать? Очень хотелось бы.
я обращался к Вам пару лет назад — она заключалась в том, что диск Fujitsu более ранней серии, MPD, случайным образом намертво зависал — настолько, что не помогала кнопка RESET, а только выключение питания — во время обращений к CD-ROM на Secondary IDE контроллере.А чтобы вспомнить детали, надо будет залезать в мои старые почтовые архивы, а это надолго.
1. Копируется около 2ТБ клипартов с тома на том.
2. На копии ставится флаг NTFS «сжато».
3. Сравнивается с оригиналом — совпадение.
4. Дефрагментация при помощи O&O Defrag.
5. Сравнивается с оригиналом — сжатые файлы случайным образом в случайных местах повреждены.
Сравнивайте ваши данные чаще :)
Хотя если сразу «правильно» копировать, то может и не понадобится сверять.
И какой алгоритм лучше подходит для хэширования (md5, sha, crc...)?
Проблема в том, что тотал коммандер платный и не пользуюсь, также не пользуюсь фаром, поэтому только рада копирования его запускать, не хотелось бы. К тому же не знаю как фар работает с сетью, так как копируется по VPN'у.
Мне интересны все варианты, а там уже думать и выбирать.
cksum
(быстро), либо md5
(медленнее, но надёжнее).А вообще для таких задач есть утилита
rsync
.Не знал, но сейчас порадовался, что сколько-нибудь значимые вещи копирую Total Commander с проверкой хэша md5. Этого достаточно, как думаете?
Не думаю. И ОС, и драйвы имеют кеши, и при чтении "того, что только что записали" данные могут идти из кэша, а не с пластин. Лично я произвожу сверку только после полного выключения и включения компьютера (не ребута) — это хоть, может, и чрезмерно (кэш винчестера теоретически должен быть полностью замещён при загрузке ОС), но зато 100% надёжно (выключение питания гарантированно очищает кеш финчестера).
Почему я перепроверяю записанные данные, или История одного расследования