Комментарии 74
Нечто аналогичное, похоже, наблюдается сейчас с 2,5-дюймовыми внешними дисками Seagate Backup Plus Slim — регулярно несколько из только что скопированных файлов различаются, и либо при повторной проверке всё-таки совпадают (!), либо приходится копировать заново.
До текущего момента, впрочем, грешил на своеобразие USB-3.0-контроллеров Etron EJ168 (опрометчиво устанавливавшихся на материнские платы Gigabyte 2011 года), особенно учитывая, что с ранними версиями драйвера Etron всё было ещё более впечатляюще (в частности накопитель частенько внезапно пропадал из системы, и исправили это лишь где-то через год), да и сейчас впечатления яркие — например, этот контроллер несовместим с USB-концентратором 4K-монитора Dell P2415Q.
До текущего момента, впрочем, грешил на своеобразие USB-3.0-контроллеров Etron EJ168 (опрометчиво устанавливавшихся на материнские платы Gigabyte 2011 года), особенно учитывая, что с ранними версиями драйвера Etron всё было ещё более впечатляюще (в частности накопитель частенько внезапно пропадал из системы, и исправили это лишь где-то через год), да и сейчас впечатления яркие — например, этот контроллер несовместим с USB-концентратором 4K-монитора Dell P2415Q.
Я бы грешил на USB, особенно если иногда он-таки не будет совпадать при повторной проверке.
К счастью, теперь у нас есть ZFS — это просто сказка. Недавно у меня сервак неделю работал на половине зеркала, пока диск на замену ехал.
Кстати, скрабы на массивах у меня раз в полгода выявляют парочку сбоев контрольных сумм на отдельных винтах (которые ZRAID тут же исправляет) — только уже не помню, на каком из массивов, поэтому называть производителя винтов не буду, чтобы не оболгать невинного (у меня разные есть).
Кстати, скрабы на массивах у меня раз в полгода выявляют парочку сбоев контрольных сумм на отдельных винтах (которые ZRAID тут же исправляет) — только уже не помню, на каком из массивов, поэтому называть производителя винтов не буду, чтобы не оболгать невинного (у меня разные есть).
А я другую историю знаю — как чувак во времена болванок CD-RW и пишущих сидюков не мог видео-файл записать. Вылилось в целое расследование: http://www.ixbt.com/optical/magia-chisel.shtml
И, кстати, Fujitsu MPG — это же тот самый фудж, который мертворожденный изначально, из серии IBM DTLA. На котором собственно репутация Fujitsu как хардо-строителей для настольных ПК и закончилась.
Не знал. Откуда дровишки?
Практика 146%, наверное.
В свое время очень много народа горя хлебнуло с этой серией.
В свое время очень много народа горя хлебнуло с этой серией.
Не знаю, в моей практике Fujitsu, наоборот, характеризовались исключительной надёжностью железа (согласен — может, везло). А потом они кончились.
Ах жаль, что не сохранилось фото с прошлого места работы. Огромная стопа дохлых Fujitsu и несколько коробок новых HDD для их замены.
В начале 200х я работал в вузе в отделе, который в т.ч. обслуживал все компьютерные классы. И прекрасно помню тот момент, когда ВНЕЗАПНО со всех сторон университета понесли компьютеры на ремонт. Потом блинами от этих дисков и магнитами все аудитории были завалены. До сих пор дома валяется один из них. :)
В начале 200х я работал в вузе в отделе, который в т.ч. обслуживал все компьютерные классы. И прекрасно помню тот момент, когда ВНЕЗАПНО со всех сторон университета понесли компьютеры на ремонт. Потом блинами от этих дисков и магнитами все аудитории были завалены. До сих пор дома валяется один из них. :)
MPG и DTLA — это одни из самых легендарных дисков. Seagate с их «мухой CC» плетутся в хвосте. IBM не было, но Fujitsu MPG у меня лежали огромной стопкой.
Все MPG были приговорены при рождении. Цирроз логики, а точнее разрушение микросхемы Cirrus Logic агрессивным припоем.
Все MPG были приговорены при рождении. Цирроз логики, а точнее разрушение микросхемы Cirrus Logic агрессивным припоем.
Слухи делились примерно на две группы:
(причём, как слухи, у меня сдох один такой, а другой вот до сих пор как музейный экспонат храню — живой)) )
— Флюс там какой то агрессивный был и потихоньку ел снизу микросхему контроллера
— Ошибка в прошивке, в связи с чем всякие внутренние логи «когданть» затирали firmware на сервисной поверхности
(причём, как слухи, у меня сдох один такой, а другой вот до сих пор как музейный экспонат храню — живой)) )
— Флюс там какой то агрессивный был и потихоньку ел снизу микросхему контроллера
— Ошибка в прошивке, в связи с чем всякие внутренние логи «когданть» затирали firmware на сервисной поверхности
Были обе проблемы.
Флюс-не флюс, но имело место повреждение компаунда процессора винта (Кстати говоря не известно, с этого случая, или ещё со времён видеокарт Currus Logic стали звать Циррозом Логики), со временем в компаунде выростали проводящие ток области, от чего чип откидывал копыта. Кому-то помогала заморозка винта, комуто прожарка, у кого-то он оживал отлежавшись пару месяцев, но во всех случаях оживал он не на очень большой промежуток времени. Добавило кайфа то, что часть адаптивов лежала на плате (по слухам — удешевление производства пластин, такчто старый вариант с хранением всех адаптивов на блинах перестал работать) и куча ремонтников напаролась на тот факт, что простое перекидывание платы (что делалось на квантумах тех времён (у этих винтов выгорал драйвер мотора из-за каких-то просчётов при разработке) винт не оживляло. Сегодня хранение параметров блинов в прошивке процессора уже никого не удивляет, а тогда удивило всех.
В ранних прошивках происходила следующая фигня — логи смарта со временем затирали куски таблиц адаптивов и прошивки. Была рекомендация для ранних прошивок — отключите смарт пока не выйдет новая версия.
Флюс-не флюс, но имело место повреждение компаунда процессора винта (Кстати говоря не известно, с этого случая, или ещё со времён видеокарт Currus Logic стали звать Циррозом Логики), со временем в компаунде выростали проводящие ток области, от чего чип откидывал копыта. Кому-то помогала заморозка винта, комуто прожарка, у кого-то он оживал отлежавшись пару месяцев, но во всех случаях оживал он не на очень большой промежуток времени. Добавило кайфа то, что часть адаптивов лежала на плате (по слухам — удешевление производства пластин, такчто старый вариант с хранением всех адаптивов на блинах перестал работать) и куча ремонтников напаролась на тот факт, что простое перекидывание платы (что делалось на квантумах тех времён (у этих винтов выгорал драйвер мотора из-за каких-то просчётов при разработке) винт не оживляло. Сегодня хранение параметров блинов в прошивке процессора уже никого не удивляет, а тогда удивило всех.
В ранних прошивках происходила следующая фигня — логи смарта со временем затирали куски таблиц адаптивов и прошивки. Была рекомендация для ранних прошивок — отключите смарт пока не выйдет новая версия.
Дык в фидо в те времены эпик-треды были, ибо чуть-ли не у каждого второго такой диск в системнике стоял и пал смертью храбрых. Вообще, вот: www.antivirus.ru/Okno7_MPG.html Если вкратце, то во всем виноваты зеленые. -) Основных версий две — компаунд центральной микросхемы Cirrus Logic был сделан из говна и палок не пойми чего, и поэтому со временем, под воздействием внешней среды компаунд начинал давить на кристалл чипа, в итоге выводя его из рабочего состояния. Вторая версия — использовали какой-то ацкий бесвинцовый припой, что в совокупности с хреновым компаундом дало такой эффект. Называлось это «цирроз логики», по аналогии с названием центральной микросхемы.
Это не та серия, у которой микросхемы можно сказать чуть ли не отваливались от платы контроллера при перегреве?
Просто я не помню какая конкретно модель HDD Fujitsu на 20 гиг у меня когда-то на компе была, но именно вот такая проблема наличествовала — уж как я с этим винтом тогда намаялся…
Просто я не помню какая конкретно модель HDD Fujitsu на 20 гиг у меня когда-то на компе была, но именно вот такая проблема наличествовала — уж как я с этим винтом тогда намаялся…
Ну только дефекты там разные были: у DTLA блины сыпались, а у фуджей чипы плохие. Вроде ничего не перепутал?
Хехе.
Ранние WD в серебристых корпусах — половинки корпуса защищались от пыли проклейкой ленты, которая в случае слегка неаккуратного монтажа/демонтажа винта рвалась и винт работал пылесосом. В результате винту наступал кирдык. В недавнем прошлом стали пионерами удешевления корпуса ЖД, правда нагадило это только ремонтникам, которые эти вестерны вскрывали.
Сигейт — о сколько нам открытий чудных… тьфу, такого списка проблем я не видел ни у одного производителя, кстати говоря ихнее LBA=0 — самый свежий epic fail у производителей винтов.
IBM — DTLA, AVER. Познакомили весь мир со стеклянными пластинами(первый) и качественным контактом банки с платой (второй). Хз, но после авера бизнес почему-то был продан в Hitachi
Samsung — ранние винты от гнусмаса надёжностью не славились (дел с ними не имел, но те, кто имел почему-то вспоминают VICTOR V40 и ругаются)
Quantum — привет от TDA и привет от DMA. Сначала у квантума была болезнь с Windows 98 + DMA (винт как-то криво парковал головки и убивал себя), потом был сгорающий драйвер (TDA) мотора. После этого слово Fireball стало матерным. В скором времени контора кудато исчезла с рынка жестких дисков
Fujitsu — цирроз + баги в десктопных винтах. Исчезла с рынка десктопных и оставалась на 2.5 и SCSI после этого факапа
Ранние 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.
Квантума пожрал Макстор, Макстора пожрал Сигейт. В итоге не стало лучше.
Контакт платы с банкой легко решался отвёрткой Torx и подгибанием контактов.
НЛО прилетело и опубликовало эту надпись здесь
>если переключить вичестер на secondary контроллер, а CD-ROM на primary;
Хм. Во времена господства самосбора и IDE, ходило в народе эмпирически выведенное правило — стараться садить диск и сидюк на разные шлейфы, потому как на одном они они друг другу мешать будут…
Хм. Во времена господства самосбора и IDE, ходило в народе эмпирически выведенное правило — стараться садить диск и сидюк на разные шлейфы, потому как на одном они они друг другу мешать будут…
Ну вот именно по этому правилу они у меня и сидели на разных шлейфах.
(Напоминаю, primary/secondary — это шлейфы, а master/slave — позиция на шлейфе, определяемая либо джампером на винчестере, либо разрывом в 28-м проводе — Cable Select)
(Напоминаю, primary/secondary — это шлейфы, а master/slave — позиция на шлейфе, определяемая либо джампером на винчестере, либо разрывом в 28-м проводе — Cable Select)
Эмпирического тут ничего нет. Очевидно, что если диск и сидюк на одном контроллере и одном шлейфе, то одновременная запись/чтение с диска и сидюка будут мешать друг другу.
Ну вы даёте! Развернули тут теорию заговора :) IDE-интерфейс изначально был разработан так, чтобы два устройства спокойно уживались рядом на одной шине. Про разделение по времени никогда не слышали чтоли? :) А представьте теперь себе шину данных процессора, к которой подключено несколько десятков чипов и они прекрасно общаются с процессором не мешая друг другу. А иногда и общаются между собой — без процессора — опять-же не мешая соседям. Если следовать подобным «народным» теориям, то разработчикам пришлось бы от процессора к каждому чипу тянуть отдельную шину данных. А уж про прямую передачу данных между чипами вообще пришлось бы забыть.
Все так. Протокол IDE позволяет иметь два устройства + контроллер на шине.
Только пока контроллер передает данные на master, slave стоит и ждет, пока контроллер освободит шину. Поэтому высокая активность HDD мешает CD.
Только пока контроллер передает данные на master, slave стоит и ждет, пока контроллер освободит шину. Поэтому высокая активность HDD мешает CD.
Арбитраж IDE-интерфейса выполнен достаточно грамотно, чтобы устройства нормально жили вместе. Шина не отдаётся монопольно какому-то из устройств если ему приспичило переслать большой объём данных. Данные передаются блоками. Поэтому пока пропускная способность интерфейса превышает суммарный объём данных, передаваемых обоими устройствами по шине — никто никому не мешает.
В теории, IDE, конечно, был придуман верно) Но вот на практике сам помню — был у меня чудный CD-ROM от Creative (который был с пультом ДУ и позволял проигрывать аудиодиски без участия компьютера), с которым было связано много «веселых» историй. Например, когда он останавливал диск при отсутствии активности, потом разогнать его обратно для него было проблемой — могло занимать приличное время и могло закончиться чтением нулей (!) вместо реальных данных сразу после разгона. Поэтому, услышав шум из него (понимая, что сидюк разгоняется), я нажимал eject и тут же обратно заталкивал лоток — после такого он стартовал верно.
Возвращаясь к теме — когда он висел на одном шлейфе с жестким диском, то временами как бы захватывал его целиком — пока операция с диском не закончится (например, тот же разгон), доступ к жесткому диску также был блокирован. Когда разнес на разные шлейфы, такая проблема исчезла.
Ну и позднее, когда скорости устройств поднялись, на UDMA33 (33 мб/с) была уже видна разница в скорости копирования, когда устройства сидели на одном шлейфе и на разных.
Возвращаясь к теме — когда он висел на одном шлейфе с жестким диском, то временами как бы захватывал его целиком — пока операция с диском не закончится (например, тот же разгон), доступ к жесткому диску также был блокирован. Когда разнес на разные шлейфы, такая проблема исчезла.
Ну и позднее, когда скорости устройств поднялись, на UDMA33 (33 мб/с) была уже видна разница в скорости копирования, когда устройства сидели на одном шлейфе и на разных.
нажимал eject и тут же обратно заталкивал лотокЭто Вам повезло, что кретивщики поленились имплементировать ATAPI полностью — в частности, команду «MEDIA LOCK».
пока операция с диском не закончится (например, тот же разгон), доступ к жесткому диску также была блокирован.А это, похоже, проблема в реализации драйвера, который должен был распознавать состояние «милый, я ещё не готова».
Мне кажется, Creative частенько отличался проблемами с драйверами =) Кстати, одну из них (не связанную с CD-ROM) я только что описал в комменте ниже (если интересно).
Но тут еще может быть то, что CD-ROM, скорее всего, работал только в PIO и не поддерживал UDMA. Вроде вешание именно таких двух устройств на один шлейф серьезно снижало скорость работы с жестким диском.
Но тут еще может быть то, что CD-ROM, скорее всего, работал только в PIO и не поддерживал UDMA. Вроде вешание именно таких двух устройств на один шлейф серьезно снижало скорость работы с жестким диском.
Причина, по которой сборщики (так-же как и я) предпочитали садить устройства на разные шины, была в другом: изредка попадались устройства, которые не точно следовали спецификациям. Бывали в них и баги, как аппаратные, так и программные. Потому что разработчики — люди, а людям свойственно ошибаться. Эти баги могли не проявлять себя до тех пор, пока устройство сидело на шине в гордом одиночестве. Но стоило подсадить к ним «партнёра» — и вот тут могло начаться какое-нибудь веселье. А могло и не начаться. Вот, чтобы голова об этом не болела, сборщики и рассаживали дивайсы по разным шинам (если, конечно, была такая возможность).
Прикольно. Давным давно у меня был точно такой-же винт — при копировании на него изредка портились файлы. Я, недолго думая, пересадил на него микросхему кэша с другого такого-же винта (умершего от цирроза печени логики) — и проблемы с порчей данных прекратились. Правда это ничуть не спасло его от дальнейшего цирроза логики…
Как я пишу в конце письма, я бы с радостью списал всё на битый кэш, вот только тогда проблема проявлялась бы и при копировании на этот винт с любого другого (или с него самого на себя) — так нет, исключительно с сидирома, и исключительно если тот стоит как secondary master.
Да я понял это сразу при прочтении — я внимательно читаю посты. :) Просто всколыхнуло память и выплеснуло на берег тот случай с кэшухой, о чём и решил с Вами поделиться. В Вашем же случае доподлинно так и осталось неизвестно, в чём проблема заключалась — Вам же заменили целиком винчестер. Может это просто напросто начинался тот самый пресловутый цирроз.
Я просто никак не могу представить, почему для проявления аппаратной проблемы требовался именно активный, именно CD-ROM, именно как secondary master — ведь при таком раскладе единственное место, где сигнальные линии могли бы ну хоть как-то пересекаться, было бы внутри чипсета, но от замены чипсета проблема как раз не исчезала.
Сейчас можно только строить догадки. Например, можно предположить, что при копировании использовался режим DMA — данные ехали с привода на винт через чипсет минуя процессор. Причём ехали в синхронном режиме. Если разработчики схемы/бисухи/фирмвара винта где-нибудь накосячили и не учли возникающие при этом задержки — это могло приводить к подобным «спецэффектам».
У меня была мистическая история, когда я подключал к параллельному порту внешнее устройство, то материнка при загрузке не видела SSD, при отключении устройства от параллельного порта, материнка при загрузке видела SSD и всё работало. При подключении устройства после загрузки тоже всё работало.
В итоге всё оказалось довольно банально...
С подобной ситуацией столкнулся когда-то на mp3 плеере MPIO FY400. Сначала просто — wtf почему архив не читается нормально! А потом, когда начал разбираться, обнаружил, что при записи в произвольных местах иногда портится один бит. Такое проявлялось весьма случайно и в основном при работе с большими файлами. Попытки выяснить причину успехом не увенчались (питание контроллера/флешки вроде в норме, микросхемы припаяны нормально, но на всякий случай переприпаяны).
НЛО прилетело и опубликовало эту надпись здесь
У меня была сетевая карта, которая вешала намертво компьютер при попытке копировать на сеть xls файлы. Какой то баг чипа.
Тоже сталкивался с побайтовой разницей, только переданного по сети файла. В итоге расследование выдало брак серии которую решили энтузиасты своими силами. Почему в офф. прошивках проблему до сих пор не решили? (А она у примерно 50% устройств). Ну наверное потому что никто не проверяет все файлы побитово — вот и результат. Полная история решения по ссылке.
Проверка CRC — этого достаточно?
Да — но если откуда-то взялась готовая — и, что самое главное, актуальная CRC.
В противном случае придётся:
Тогда как в моём случае достаточно
Почему-то мне кажется, что второй путь содержит меньше операций.
В противном случае придётся:
- Прочитать данные исходного файла
- Подсчитать CRC
- Прочитать данные из скопированного файла
- Подсчитать CRC
- Сравнить подсчитанные CRC
Тогда как в моём случае достаточно
- Прочитать данные исходного файла
- Прочитать данные из скопированного файла
- Сравнить прочитанное
Почему-то мне кажется, что второй путь содержит меньше операций.
Здорово, что поддержка фуджици оказалась на уровне! У меня лично был обратный опыт с поддержкой Creative.
В каком-то там году типа 2002-2003 решил я обновить свою звуковую карту — на тот момент стояла у меня Create SB Live! (4-канальная), а захотелось мнезапретного плода Live! 5.1, который, кроме наличия отдельных выходов под центральный канал и сабвуфер, умел в драйверах декодировать ac3. Сейчас этим никого не удивишь, но тогда декодировать ac3 умели единицы программ (например, DVD-проигрыватель вроде PowerDVD). Понятно, что Creative могли бы накинуть декодирование и для предыдущей серии карт, но зачем, тем более, что пришло время продавать новую. А тогда я обновлял весь компьютер (на pentium 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 года.
В каком-то там году типа 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. Сравнивается с оригиналом — сжатые файлы случайным образом в случайных местах повреждены.
Сравнивайте ваши данные чаще :)
1. Копируется около 2ТБ клипартов с тома на том.
2. На копии ставится флаг NTFS «сжато».
3. Сравнивается с оригиналом — совпадение.
4. Дефрагментация при помощи O&O Defrag.
5. Сравнивается с оригиналом — сжатые файлы случайным образом в случайных местах повреждены.
Сравнивайте ваши данные чаще :)
А чем данные сравниваете?
В FAR есть хороший плагин Advanced Compare.
А какие есть ещё методы? Хэш сумма не показатель?
Total Commander умеет сравнивать директории в рамках функции синхронизации.
Объясняю вопрос, есть несколько офисов и серверов, вот я через не быстрый интернет тащу к себе БД. По окончанию надо убедиться в целостности, запустить проверку хэше, не так уж и долго.
Хотя если сразу «правильно» копировать, то может и не понадобится сверять.
И какой алгоритм лучше подходит для хэширования (md5, sha, crc...)?
Проблема в том, что тотал коммандер платный и не пользуюсь, также не пользуюсь фаром, поэтому только рада копирования его запускать, не хотелось бы. К тому же не знаю как фар работает с сетью, так как копируется по VPN'у.
Мне интересны все варианты, а там уже думать и выбирать.
Хотя если сразу «правильно» копировать, то может и не понадобится сверять.
И какой алгоритм лучше подходит для хэширования (md5, sha, crc...)?
Проблема в том, что тотал коммандер платный и не пользуюсь, также не пользуюсь фаром, поэтому только рада копирования его запускать, не хотелось бы. К тому же не знаю как фар работает с сетью, так как копируется по VPN'у.
Мне интересны все варианты, а там уже думать и выбирать.
При таком раскладе файл лучше всего передавать при помощи SFTP, и не столько ради безопасности, сколько потому, что SSH-туннель проводит контроль целостности проходящих через него данных, что снижает вероятность невидимого повреждения файла. А после получения всего файла можно сверить его контрольные суммы на обоих машинах при помощи либо
А вообще для таких задач есть утилита
cksum (быстро), либо md5 (медленнее, но надёжнее).А вообще для таких задач есть утилита
rsync.
Я вот только что погуглил, и нашел, что чипсет i845D не поддерживает память с ECC, так что не байка ли это?
Не знал, но сейчас порадовался, что сколько-нибудь значимые вещи копирую Total Commander с проверкой хэша md5. Этого достаточно, как думаете?
Не думаю. И ОС, и драйвы имеют кеши, и при чтении "того, что только что записали" данные могут идти из кэша, а не с пластин. Лично я произвожу сверку только после полного выключения и включения компьютера (не ребута) — это хоть, может, и чрезмерно (кэш винчестера теоретически должен быть полностью замещён при загрузке ОС), но зато 100% надёжно (выключение питания гарантированно очищает кеш финчестера).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему я перепроверяю записанные данные, или История одного расследования