Через два месяца я получил от Fujitsu новый винчестер с обновлённой ревизией прошивки. Он работал нормально…Досточтимый сэр,
В 2001 году я уже общался с Вами относительно проблем с моим диском Fujitsu MPG3409AH. Сейчас я столкнулся с ещё одной проблемой — боюсь, гораздо более худшей. Могу ли я по-прежнему обращаться к Вам? Если нет, подскажите отвечающего за это человека, к кому я могу обратиться.
Monday, July 29, 2002, 8:57:37 AM, you wrote:
gffc> Какую проблему Вы испытываете с Вашим диском?
Начнём с бюрократических деталей:
Модель: MPG3409AH
Серийный номер: VLxxxxxxxxCF (август 2001)
Ревизия прошивки: A9
Проблема состоит в следующем: от случая к случаю единственный бит в прочитанных данных изменяется с 1 на 0 — но исключительно в том случае, если происходит обмен данными между HDD на primary канале и CD-ROM на secondary канале.
Расположение бита всегда одно и то же — xxxx1xxx превращается в xxxx0xxx на смещении XXXXX02E примерно каждые 50 прочитанных или записанных мегабайт, но абсолютно случайно.
Например:
Смещение в файле — ожидаемое значение — прочитанное значение
26002E 5A 52
C2D02E 8C 84
28002E 99 91
Впервые я заметил проблему, скопировав zip-файл с компат-диска на винчестер: файл с диска открывался нормально, а с винчестера — нет; сравнение файлов показало, что указанным образом — из 1 в 0 — сбросился один бит. Затем, сравнивая 130-мегабайтный файл на другом свежезаписанном компакт-диске с его исходной копией на винчестере, я обнаружил, что копии иногда совпадают, а иногда — нет (!!!). Запросив побитовую распечатку расхождений, я получил аналогичный результат: информация, считанная с винчестера, время от времени оказывалась испорченной. Байт, повреждённый при предыдущей попытке чтения, при очередной попытке оказывался правильным, и наоборот.
Сначала я грешил на планки памяти в моём компьютере. Поставил память с поддержкой ECC и до кучи добавил к ней кулер — безрезультатно. Заподозрил CD-ROM и стал сравнивать файл на компакт-диске с файлом на винчестере, и копией файла на другом компьютере. Сравнение по сети всегда было успешным, сравнение с винчестером — нет. Заподозрил контроллер жёстких дисков (чипсет i845D). Перенёс винчестер на компьютер с более старой материнкой (DELL двухгодичной давности — так что чипсет там гаранитрованно другой, да и CD-ROM тоже) — и ошибки сравнения «винчестер с CD» воспроизвелись.
Для меня это изначально выглядит как битая ячейка во внутреннем кэше винчестера. Однако я одного не могу понять — почему я не могу повторить проблему при копировании с Master-винчеcтера на Slave-винчестер на том же самом контроллере — или с проблемного винчестера на него самого же? Может быть, потому, что поток данных в таком случае течёт вдвое медленнее, чем при копировании между Primary и Secondary IDE контроллерами?
Подозрения навевает также моя первая проблема, с которой я обращался к Вам пару лет назад — она заключалась в том, что диск Fujitsu более ранней серии, MPD, случайным образом намертво зависал — настолько, что не помогала кнопка RESET, а только выключение питания — во время обращений к CD-ROM на Secondary IDE контроллере.
Если бы не это дополнительное, но необходимое условие (обмен между винчестером и CD-ROM), я бы не был настолько обескуражен. Встречались ли Вы с подобным поведением?
Повторю набор достаточных и необходимых условий для возникновения проблемы:
- Подопытный винчестер должен быть выставлен как Master на primary IDE канале;
- CD-ROM должен быть выставлен как Master на secondary IDE канале;
- Подопытный винчестер и CD-ROM должны одновременно активно передавать данные.
Факторы, не влияющие на воспроизведение проблемы (проблема воспроизводится):
- после замены CD-ROM привода
- после замены RAM
- после замены блока питания
- после замены материнской платы
- на другом компьютере
В то же время, если изменить хотя бы один параметр из списка необходимых, баг перестаёт воспроизводиться:
- если переключить вичестер на secondary контроллер, а CD-ROM на primary;
- если поставить винчестер (или CD-ROM) как Slave;
- если во время чтения данных с винчестера CD-ROM простаивает.
Заранее благодарен за Ваше внимание.
А мораль истории сей такова: если бы я не имел привычки побитово сравнивать скопированные куда-либо файлы, никто ещё долго ничего бы не узнал...
Комментарии (56)
tronix286
29.12.2015 08:03+3А я другую историю знаю — как чувак во времена болванок CD-RW и пишущих сидюков не мог видео-файл записать. Вылилось в целое расследование: http://www.ixbt.com/optical/magia-chisel.shtml
tronix286
29.12.2015 08:10+2И, кстати, Fujitsu MPG — это же тот самый фудж, который мертворожденный изначально, из серии IBM DTLA. На котором собственно репутация Fujitsu как хардо-строителей для настольных ПК и закончилась.
Wesha
29.12.2015 08:26Не знал. Откуда дровишки?
workless
29.12.2015 08:45+2Практика 146%, наверное.
В свое время очень много народа горя хлебнуло с этой серией.Wesha
29.12.2015 09:02Не знаю, в моей практике Fujitsu, наоборот, характеризовались исключительной надёжностью железа (согласен — может, везло). А потом они кончились.
foboss
29.12.2015 22:07Ах жаль, что не сохранилось фото с прошлого места работы. Огромная стопа дохлых Fujitsu и несколько коробок новых HDD для их замены.
В начале 200х я работал в вузе в отделе, который в т.ч. обслуживал все компьютерные классы. И прекрасно помню тот момент, когда ВНЕЗАПНО со всех сторон университета понесли компьютеры на ремонт. Потом блинами от этих дисков и магнитами все аудитории были завалены. До сих пор дома валяется один из них. :)
gotch
29.12.2015 09:07+9MPG и DTLA — это одни из самых легендарных дисков. Seagate с их «мухой CC» плетутся в хвосте. IBM не было, но Fujitsu MPG у меня лежали огромной стопкой.
Все MPG были приговорены при рождении. Цирроз логики, а точнее разрушение микросхемы Cirrus Logic агрессивным припоем.
lleo_aha
29.12.2015 09:12+1Слухи делились примерно на две группы:
(причём, как слухи, у меня сдох один такой, а другой вот до сих пор как музейный экспонат храню — живой)) )
— Флюс там какой то агрессивный был и потихоньку ел снизу микросхему контроллера
— Ошибка в прошивке, в связи с чем всякие внутренние логи «когданть» затирали firmware на сервисной поверхностиJerleShannara
29.12.2015 11:10+3Были обе проблемы.
Флюс-не флюс, но имело место повреждение компаунда процессора винта (Кстати говоря не известно, с этого случая, или ещё со времён видеокарт Currus Logic стали звать Циррозом Логики), со временем в компаунде выростали проводящие ток области, от чего чип откидывал копыта. Кому-то помогала заморозка винта, комуто прожарка, у кого-то он оживал отлежавшись пару месяцев, но во всех случаях оживал он не на очень большой промежуток времени. Добавило кайфа то, что часть адаптивов лежала на плате (по слухам — удешевление производства пластин, такчто старый вариант с хранением всех адаптивов на блинах перестал работать) и куча ремонтников напаролась на тот факт, что простое перекидывание платы (что делалось на квантумах тех времён (у этих винтов выгорал драйвер мотора из-за каких-то просчётов при разработке) винт не оживляло. Сегодня хранение параметров блинов в прошивке процессора уже никого не удивляет, а тогда удивило всех.
В ранних прошивках происходила следующая фигня — логи смарта со временем затирали куски таблиц адаптивов и прошивки. Была рекомендация для ранних прошивок — отключите смарт пока не выйдет новая версия.
tronix286
29.12.2015 10:11+2Дык в фидо в те времены эпик-треды были, ибо чуть-ли не у каждого второго такой диск в системнике стоял и пал смертью храбрых. Вообще, вот: www.antivirus.ru/Okno7_MPG.html Если вкратце, то во всем виноваты зеленые. -) Основных версий две — компаунд центральной микросхемы Cirrus Logic был сделан из
говна и палокне пойми чего, и поэтому со временем, под воздействием внешней среды компаунд начинал давить на кристалл чипа, в итоге выводя его из рабочего состояния. Вторая версия — использовали какой-то ацкий бесвинцовый припой, что в совокупности с хреновым компаундом дало такой эффект. Называлось это «цирроз логики», по аналогии с названием центральной микросхемы.
Gaikotsu
29.12.2015 08:55Это не та серия, у которой микросхемы можно сказать чуть ли не отваливались от платы контроллера при перегреве?
Просто я не помню какая конкретно модель HDD Fujitsu на 20 гиг у меня когда-то на компе была, но именно вот такая проблема наличествовала — уж как я с этим винтом тогда намаялся…
vilgeforce
29.12.2015 10:05Ну только дефекты там разные были: у DTLA блины сыпались, а у фуджей чипы плохие. Вроде ничего не перепутал?
JerleShannara
29.12.2015 11:21+1Хехе.
Ранние WD в серебристых корпусах — половинки корпуса защищались от пыли проклейкой ленты, которая в случае слегка неаккуратного монтажа/демонтажа винта рвалась и винт работал пылесосом. В результате винту наступал кирдык. В недавнем прошлом стали пионерами удешевления корпуса ЖД, правда нагадило это только ремонтникам, которые эти вестерны вскрывали.
Сигейт — о сколько нам открытий чудных… тьфу, такого списка проблем я не видел ни у одного производителя, кстати говоря ихнее LBA=0 — самый свежий epic fail у производителей винтов.
IBM — DTLA, AVER. Познакомили весь мир со стеклянными пластинами(первый) и качественным контактом банки с платой (второй). Хз, но после авера бизнес почему-то был продан в Hitachi
Samsung — ранние винты от гнусмаса надёжностью не славились (дел с ними не имел, но те, кто имел почему-то вспоминают VICTOR V40 и ругаются)
Quantum — привет от TDA и привет от DMA. Сначала у квантума была болезнь с Windows 98 + DMA (винт как-то криво парковал головки и убивал себя), потом был сгорающий драйвер (TDA) мотора. После этого слово Fireball стало матерным. В скором времени контора кудато исчезла с рынка жестких дисков
Fujitsu — цирроз + баги в десктопных винтах. Исчезла с рынка десктопных и оставалась на 2.5 и SCSI после этого факапа
stigory
29.12.2015 11:39В скором времени контора кудато исчезла с рынка жестких дисков
Заголовок спойлера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.
varnav
30.12.2015 11:57Контакт платы с банкой легко решался отвёрткой Torx и подгибанием контактов.
JerleShannara
31.12.2015 21:55Не решался, проблемы была в мягком припое, которым были облужены контакты платы. Подгибание решало проблему на очень короткий срок. Решение — облуживание по новой более жестким припоем.
XogN
29.12.2015 09:08Лет 7 назад столкнулся с систематическим повреждением файлов при копировании.
Правда, тогда оказалась виновата битая оперативка, но с тех пор всегда для мало мальски важных файлов сверяю контрольные суммы после копирования.
hungry_ewok
29.12.2015 09:57>если переключить вичестер на secondary контроллер, а CD-ROM на primary;
Хм. Во времена господства самосбора и IDE, ходило в народе эмпирически выведенное правило — стараться садить диск и сидюк на разные шлейфы, потому как на одном они они друг другу мешать будут…Wesha
29.12.2015 10:03+6Ну вот именно по этому правилу они у меня и сидели на разных шлейфах.
(Напоминаю, primary/secondary — это шлейфы, а master/slave — позиция на шлейфе, определяемая либо джампером на винчестере, либо разрывом в 28-м проводе — Cable Select)
leotsarev
29.12.2015 17:28-1Эмпирического тут ничего нет. Очевидно, что если диск и сидюк на одном контроллере и одном шлейфе, то одновременная запись/чтение с диска и сидюка будут мешать друг другу.
jok40
29.12.2015 17:46+1Ну вы даёте! Развернули тут теорию заговора :) IDE-интерфейс изначально был разработан так, чтобы два устройства спокойно уживались рядом на одной шине. Про разделение по времени никогда не слышали чтоли? :) А представьте теперь себе шину данных процессора, к которой подключено несколько десятков чипов и они прекрасно общаются с процессором не мешая друг другу. А иногда и общаются между собой — без процессора — опять-же не мешая соседям. Если следовать подобным «народным» теориям, то разработчикам пришлось бы от процессора к каждому чипу тянуть отдельную шину данных. А уж про прямую передачу данных между чипами вообще пришлось бы забыть.
leotsarev
29.12.2015 18:08Все так. Протокол IDE позволяет иметь два устройства + контроллер на шине.
Только пока контроллер передает данные на master, slave стоит и ждет, пока контроллер освободит шину. Поэтому высокая активность HDD мешает CD.jok40
29.12.2015 18:20Арбитраж IDE-интерфейса выполнен достаточно грамотно, чтобы устройства нормально жили вместе. Шина не отдаётся монопольно какому-то из устройств если ему приспичило переслать большой объём данных. Данные передаются блоками. Поэтому пока пропускная способность интерфейса превышает суммарный объём данных, передаваемых обоими устройствами по шине — никто никому не мешает.
kdekaluga
29.12.2015 22:12+1В теории, IDE, конечно, был придуман верно) Но вот на практике сам помню — был у меня чудный CD-ROM от Creative (который был с пультом ДУ и позволял проигрывать аудиодиски без участия компьютера), с которым было связано много «веселых» историй. Например, когда он останавливал диск при отсутствии активности, потом разогнать его обратно для него было проблемой — могло занимать приличное время и могло закончиться чтением нулей (!) вместо реальных данных сразу после разгона. Поэтому, услышав шум из него (понимая, что сидюк разгоняется), я нажимал eject и тут же обратно заталкивал лоток — после такого он стартовал верно.
Возвращаясь к теме — когда он висел на одном шлейфе с жестким диском, то временами как бы захватывал его целиком — пока операция с диском не закончится (например, тот же разгон), доступ к жесткому диску также был блокирован. Когда разнес на разные шлейфы, такая проблема исчезла.
Ну и позднее, когда скорости устройств поднялись, на UDMA33 (33 мб/с) была уже видна разница в скорости копирования, когда устройства сидели на одном шлейфе и на разных.Wesha
29.12.2015 22:21нажимал eject и тут же обратно заталкивал лоток
Это Вам повезло, что кретивщики поленились имплементировать ATAPI полностью — в частности, команду «MEDIA LOCK».
пока операция с диском не закончится (например, тот же разгон), доступ к жесткому диску также была блокирован.
А это, похоже, проблема в реализации драйвера, который должен был распознавать состояние «милый, я ещё не готова».kdekaluga
29.12.2015 22:46Мне кажется, Creative частенько отличался проблемами с драйверами =) Кстати, одну из них (не связанную с CD-ROM) я только что описал в комменте ниже (если интересно).
Но тут еще может быть то, что CD-ROM, скорее всего, работал только в PIO и не поддерживал UDMA. Вроде вешание именно таких двух устройств на один шлейф серьезно снижало скорость работы с жестким диском.
jok40
29.12.2015 20:34Причина, по которой сборщики (так-же как и я) предпочитали садить устройства на разные шины, была в другом: изредка попадались устройства, которые не точно следовали спецификациям. Бывали в них и баги, как аппаратные, так и программные. Потому что разработчики — люди, а людям свойственно ошибаться. Эти баги могли не проявлять себя до тех пор, пока устройство сидело на шине в гордом одиночестве. Но стоило подсадить к ним «партнёра» — и вот тут могло начаться какое-нибудь веселье. А могло и не начаться. Вот, чтобы голова об этом не болела, сборщики и рассаживали дивайсы по разным шинам (если, конечно, была такая возможность).
jok40
29.12.2015 10:33Прикольно. Давным давно у меня был точно такой-же винт — при копировании на него изредка портились файлы. Я, недолго думая, пересадил на него микросхему кэша с другого такого-же винта (умершего от цирроза
печенилогики) — и проблемы с порчей данных прекратились. Правда это ничуть не спасло его от дальнейшего цирроза логики…Wesha
29.12.2015 10:49Как я пишу в конце письма, я бы с радостью списал всё на битый кэш, вот только тогда проблема проявлялась бы и при копировании на этот винт с любого другого (или с него самого на себя) — так нет, исключительно с сидирома, и исключительно если тот стоит как secondary master.
jok40
29.12.2015 11:04+1Да я понял это сразу при прочтении — я внимательно читаю посты. :) Просто всколыхнуло память и выплеснуло на берег тот случай с кэшухой, о чём и решил с Вами поделиться. В Вашем же случае доподлинно так и осталось неизвестно, в чём проблема заключалась — Вам же заменили целиком винчестер. Может это просто напросто начинался тот самый пресловутый цирроз.
Wesha
29.12.2015 11:13+2Я просто никак не могу представить, почему для проявления аппаратной проблемы требовался именно активный, именно CD-ROM, именно как secondary master — ведь при таком раскладе единственное место, где сигнальные линии могли бы ну хоть как-то пересекаться, было бы внутри чипсета, но от замены чипсета проблема как раз не исчезала.
jok40
29.12.2015 13:27Сейчас можно только строить догадки. Например, можно предположить, что при копировании использовался режим DMA — данные ехали с привода на винт через чипсет минуя процессор. Причём ехали в синхронном режиме. Если разработчики схемы/бисухи/фирмвара винта где-нибудь накосячили и не учли возникающие при этом задержки — это могло приводить к подобным «спецэффектам».
qwerty1023
29.12.2015 10:58С подобной ситуацией столкнулся когда-то на mp3 плеере MPIO FY400. Сначала просто — wtf почему архив не читается нормально! А потом, когда начал разбираться, обнаружил, что при записи в произвольных местах иногда портится один бит. Такое проявлялось весьма случайно и в основном при работе с большими файлами. Попытки выяснить причину успехом не увенчались (питание контроллера/флешки вроде в норме, микросхемы припаяны нормально, но на всякий случай переприпаяны).
Mixim333
29.12.2015 11:27Забавно, судя по всему, не только с прошивкой у этой модели HDD были проблемы: http://forum.ru-board.com/topic.cgi?forum=27&topic=2090. Мне всегда было интересно: выпускались ли в современном компьютерном мире устройства с такими багами и оказывается да, было такое.
Satyricon
29.12.2015 14:06У меня была сетевая карта, которая вешала намертво компьютер при попытке копировать на сеть xls файлы. Какой то баг чипа.
Speakus
29.12.2015 18:31Тоже сталкивался с побайтовой разницей, только переданного по сети файла. В итоге расследование выдало брак серии которую решили энтузиасты своими силами. Почему в офф. прошивках проблему до сих пор не решили? (А она у примерно 50% устройств). Ну наверное потому что никто не проверяет все файлы побитово — вот и результат. Полная история решения по ссылке.
Wesha
29.12.2015 18:45никто не проверяет все файлы побитово — вот и результат.
Я с тех пор проверяю всегда. Как говорил Жванецкий, «чуть больше времени на выход — зато спокоен, что действительно ушёл, действительно пошёл домой, и действительно лёг спать».
BigD
29.12.2015 19:03Проверка CRC — этого достаточно?
Wesha
29.12.2015 19:11Да — но если откуда-то взялась готовая — и, что самое главное, актуальная CRC.
В противном случае придётся:
- Прочитать данные исходного файла
- Подсчитать CRC
- Прочитать данные из скопированного файла
- Подсчитать CRC
- Сравнить подсчитанные CRC
Тогда как в моём случае достаточно
- Прочитать данные исходного файла
- Прочитать данные из скопированного файла
- Сравнить прочитанное
Почему-то мне кажется, что второй путь содержит меньше операций.BigD
29.12.2015 22:40Ну я обычно копирую важные файлы при помощи Total Commander, он содержит функцию Verify CRC и проверяет сразу после копирования. Да, проверка занимает по времени столько же, сколько копирование.
Wesha
29.12.2015 23:02Ненадёжно: проверять нужно после полного сброса всех кэшей — включая кэш винчестера. Поэтому я всегда проверяю после включения/выключения компьютера.
kdekaluga
29.12.2015 22:35+2Здорово, что поддержка фуджици оказалась на уровне! У меня лично был обратный опыт с поддержкой 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 года.Wesha
30.12.2015 01:35Здорово, что поддержка фуджици оказалась на уровне!
Как говорят в деревнях, «авотх… вост!». Как Вы могли заметить из преамбулы письма, это был инженер, с которым я за два года до этого общался по поводу другой проблемы с фуджиками, поэтому я в этот раз написал ему напрямую. А как я его выцепил в первый раз — это уже совсем другая история…
SkazochNik
30.12.2015 12:30> это уже совсем другая история…
То есть приквел будет? Ждать? Очень хотелось бы.Wesha
30.12.2015 19:41Ну приквел гораздо менее детективный, и амбула истории уже раскрыта в письме:
я обращался к Вам пару лет назад — она заключалась в том, что диск Fujitsu более ранней серии, MPD, случайным образом намертво зависал — настолько, что не помогала кнопка RESET, а только выключение питания — во время обращений к CD-ROM на Secondary IDE контроллере.
А чтобы вспомнить детали, надо будет залезать в мои старые почтовые архивы, а это надолго.
Lain_13
06.01.2016 00:10+1Хм… Я тут вспомнил, что тоже имею привычку перепроверять то, что записал или упаковал, и года полтора назад порадовался тому, что имею. Дело в том, что купил я себе ноутбук. Хороший, быстрый, но стоило на нём долго поработать или немного поиграть — начинал странно глючить и просто повисал. Но не отправлять же его в сервис по гарантии со словами «странно работает»? И тут решил я упаковать несколько гектаров файлов и сразу же перепроверить, а открывается ли архив после упаковки? Такая вот у меня привычка. И к моему изумлению тест остановился с ошибкой во время распаковки одного из файлов внутри архива. Ок, запускаем тест ещё раз — снова ошибка… но уже в другом файле! Налицо проблема с перегревом и расхождением где-то контактов. И вероятнее всего материнки — основные источники тепла в ноутбуке ведь расположены именно там. Что, кстати, в последствии и подтвердилось… после того, как мне в сервисе упорно два раза винт меняли не желая выполнить приложенную на бумажке процедуру тестирования проблемы и верить в то, что с материнкой может быть что-то не так. -_-
MTonly
Нечто аналогичное, похоже, наблюдается сейчас с 2,5-дюймовыми внешними дисками Seagate Backup Plus Slim — регулярно несколько из только что скопированных файлов различаются, и либо при повторной проверке всё-таки совпадают (!), либо приходится копировать заново.
До текущего момента, впрочем, грешил на своеобразие USB-3.0-контроллеров Etron EJ168 (опрометчиво устанавливавшихся на материнские платы Gigabyte 2011 года), особенно учитывая, что с ранними версиями драйвера Etron всё было ещё более впечатляюще (в частности накопитель частенько внезапно пропадал из системы, и исправили это лишь где-то через год), да и сейчас впечатления яркие — например, этот контроллер несовместим с USB-концентратором 4K-монитора Dell P2415Q.
vilgeforce
Я бы грешил на USB, особенно если иногда он-таки не будет совпадать при повторной проверке.
Wesha
К счастью, теперь у нас есть ZFS — это просто сказка. Недавно у меня сервак неделю работал на половине зеркала, пока диск на замену ехал.
Кстати, скрабы на массивах у меня раз в полгода выявляют парочку сбоев контрольных сумм на отдельных винтах (которые ZRAID тут же исправляет) — только уже не помню, на каком из массивов, поэтому называть производителя винтов не буду, чтобы не оболгать невинного (у меня разные есть).