Senior Software Engineer; Software Archaeologist
0,8
рейтинг
29 декабря 2015 в 03:32

Разработка → Почему я перепроверяю записанные данные, или История одного расследования recovery mode

Недавняя хабрастатья о различиях в побайтово идентичных файлах вызвала из глубин памяти (и почтового ящика) небольшой кусочек моей переписки с одним из инженеров, отвечавших в то время за линию дисков MPG в компании 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), я бы не был настолько обескуражен. Встречались ли Вы с подобным поведением?

Повторю набор достаточных и необходимых условий для возникновения проблемы:
  1. Подопытный винчестер должен быть выставлен как Master на primary IDE канале;
  2. CD-ROM должен быть выставлен как Master на secondary IDE канале;
  3. Подопытный винчестер и CD-ROM должны одновременно активно передавать данные.

Факторы, не влияющие на воспроизведение проблемы (проблема воспроизводится):
  • после замены CD-ROM привода
  • после замены RAM
  • после замены блока питания
  • после замены материнской платы
  • на другом компьютере

В то же время, если изменить хотя бы один параметр из списка необходимых, баг перестаёт воспроизводиться:
  • если переключить вичестер на secondary контроллер, а CD-ROM на primary;
  • если поставить винчестер (или CD-ROM) как Slave;
  • если во время чтения данных с винчестера CD-ROM простаивает.

Заранее благодарен за Ваше внимание.
Через два месяца я получил от Fujitsu новый винчестер с обновлённой ревизией прошивки. Он работал нормально…
А мораль истории сей такова: если бы я не имел привычки побитово сравнивать скопированные куда-либо файлы, никто ещё долго ничего бы не узнал...
@Wesha
карма
7,5
рейтинг 0,8
Senior Software Engineer; Software Archaeologist
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (64)

  • 0
    Нечто аналогичное, похоже, наблюдается сейчас с 2,5-дюймовыми внешними дисками Seagate Backup Plus Slim — регулярно несколько из только что скопированных файлов различаются, и либо при повторной проверке всё-таки совпадают (!), либо приходится копировать заново.

    До текущего момента, впрочем, грешил на своеобразие USB-3.0-контроллеров Etron EJ168 (опрометчиво устанавливавшихся на материнские платы Gigabyte 2011 года), особенно учитывая, что с ранними версиями драйвера Etron всё было ещё более впечатляюще (в частности накопитель частенько внезапно пропадал из системы, и исправили это лишь где-то через год), да и сейчас впечатления яркие — например, этот контроллер несовместим с USB-концентратором 4K-монитора Dell P2415Q.
    • 0
      Я бы грешил на USB, особенно если иногда он-таки не будет совпадать при повторной проверке.
      • +3
        К счастью, теперь у нас есть ZFS — это просто сказка. Недавно у меня сервак неделю работал на половине зеркала, пока диск на замену ехал.

        Кстати, скрабы на массивах у меня раз в полгода выявляют парочку сбоев контрольных сумм на отдельных винтах (которые ZRAID тут же исправляет) — только уже не помню, на каком из массивов, поэтому называть производителя винтов не буду, чтобы не оболгать невинного (у меня разные есть).
  • +3
    А я другую историю знаю — как чувак во времена болванок CD-RW и пишущих сидюков не мог видео-файл записать. Вылилось в целое расследование: http://www.ixbt.com/optical/magia-chisel.shtml
  • +2
    И, кстати, Fujitsu MPG — это же тот самый фудж, который мертворожденный изначально, из серии IBM DTLA. На котором собственно репутация Fujitsu как хардо-строителей для настольных ПК и закончилась.
    • 0
      Не знал. Откуда дровишки?
      • +2
        Практика 146%, наверное.
        В свое время очень много народа горя хлебнуло с этой серией.
        • 0
          Не знаю, в моей практике Fujitsu, наоборот, характеризовались исключительной надёжностью железа (согласен — может, везло). А потом они кончились.
          • 0
            Ах жаль, что не сохранилось фото с прошлого места работы. Огромная стопа дохлых Fujitsu и несколько коробок новых HDD для их замены.

            В начале 200х я работал в вузе в отделе, который в т.ч. обслуживал все компьютерные классы. И прекрасно помню тот момент, когда ВНЕЗАПНО со всех сторон университета понесли компьютеры на ремонт. Потом блинами от этих дисков и магнитами все аудитории были завалены. До сих пор дома валяется один из них. :)
            • 0
              Это была партия, апрельская, вроде. Горел контроллер у всех, через несколько месяцев. Остальные крепкие были.
              • 0
                Ой, это я с WD перепутал, у них была эта проблема.
      • +9
        MPG и DTLA — это одни из самых легендарных дисков. Seagate с их «мухой CC» плетутся в хвосте. IBM не было, но Fujitsu MPG у меня лежали огромной стопкой.
        Все MPG были приговорены при рождении. Цирроз логики, а точнее разрушение микросхемы Cirrus Logic агрессивным припоем.
        • 0
          Ну дятлов-то я помню, а вот ужастиков про MPG не слышал.
          • 0
            К сожалению серия MPG была действительно обреченной.
            С ходу нашлась такая статья.
      • +1
        Слухи делились примерно на две группы:
        (причём, как слухи, у меня сдох один такой, а другой вот до сих пор как музейный экспонат храню — живой)) )

        — Флюс там какой то агрессивный был и потихоньку ел снизу микросхему контроллера
        — Ошибка в прошивке, в связи с чем всякие внутренние логи «когданть» затирали firmware на сервисной поверхности
        • +3
          Были обе проблемы.
          Флюс-не флюс, но имело место повреждение компаунда процессора винта (Кстати говоря не известно, с этого случая, или ещё со времён видеокарт Currus Logic стали звать Циррозом Логики), со временем в компаунде выростали проводящие ток области, от чего чип откидывал копыта. Кому-то помогала заморозка винта, комуто прожарка, у кого-то он оживал отлежавшись пару месяцев, но во всех случаях оживал он не на очень большой промежуток времени. Добавило кайфа то, что часть адаптивов лежала на плате (по слухам — удешевление производства пластин, такчто старый вариант с хранением всех адаптивов на блинах перестал работать) и куча ремонтников напаролась на тот факт, что простое перекидывание платы (что делалось на квантумах тех времён (у этих винтов выгорал драйвер мотора из-за каких-то просчётов при разработке) винт не оживляло. Сегодня хранение параметров блинов в прошивке процессора уже никого не удивляет, а тогда удивило всех.

          В ранних прошивках происходила следующая фигня — логи смарта со временем затирали куски таблиц адаптивов и прошивки. Была рекомендация для ранних прошивок — отключите смарт пока не выйдет новая версия.
      • +2
        Дык в фидо в те времены эпик-треды были, ибо чуть-ли не у каждого второго такой диск в системнике стоял и пал смертью храбрых. Вообще, вот: www.antivirus.ru/Okno7_MPG.html Если вкратце, то во всем виноваты зеленые. -) Основных версий две — компаунд центральной микросхемы Cirrus Logic был сделан из говна и палок не пойми чего, и поэтому со временем, под воздействием внешней среды компаунд начинал давить на кристалл чипа, в итоге выводя его из рабочего состояния. Вторая версия — использовали какой-то ацкий бесвинцовый припой, что в совокупности с хреновым компаундом дало такой эффект. Называлось это «цирроз логики», по аналогии с названием центральной микросхемы.
    • 0
      Это не та серия, у которой микросхемы можно сказать чуть ли не отваливались от платы контроллера при перегреве?
      Просто я не помню какая конкретно модель HDD Fujitsu на 20 гиг у меня когда-то на компе была, но именно вот такая проблема наличествовала — уж как я с этим винтом тогда намаялся…
    • 0
      Ну только дефекты там разные были: у DTLA блины сыпались, а у фуджей чипы плохие. Вроде ничего не перепутал?
    • +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 после этого факапа
      • 0
        В скором времени контора кудато исчезла с рынка жестких дисков

        Заголовок спойлера
        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.



        Квантума пожрал Макстор, Макстора пожрал Сигейт. В итоге не стало лучше.
      • 0
        Контакт платы с банкой легко решался отвёрткой Torx и подгибанием контактов.
        • 0
          Не решался, проблемы была в мягком припое, которым были облужены контакты платы. Подгибание решало проблему на очень короткий срок. Решение — облуживание по новой более жестким припоем.
  • 0
    Лет 7 назад столкнулся с систематическим повреждением файлов при копировании.
    Правда, тогда оказалась виновата битая оперативка, но с тех пор всегда для мало мальски важных файлов сверяю контрольные суммы после копирования.
    • 0
      В моём случае оперативка немедленно попала под подозрение, но была сразу оправдана.
      • 0
        В моем случае были плавающие ошибки, которые далеко не сразу проявились даже при длительном тестировании памяти.
  • 0
    >если переключить вичестер на secondary контроллер, а CD-ROM на primary;

    Хм. Во времена господства самосбора и IDE, ходило в народе эмпирически выведенное правило — стараться садить диск и сидюк на разные шлейфы, потому как на одном они они друг другу мешать будут…
    • +6
      Ну вот именно по этому правилу они у меня и сидели на разных шлейфах.

      (Напоминаю, primary/secondary — это шлейфы, а master/slave — позиция на шлейфе, определяемая либо джампером на винчестере, либо разрывом в 28-м проводе — Cable Select) image
    • –1
      Эмпирического тут ничего нет. Очевидно, что если диск и сидюк на одном контроллере и одном шлейфе, то одновременная запись/чтение с диска и сидюка будут мешать друг другу.
      • +1
        Ну вы даёте! Развернули тут теорию заговора :) IDE-интерфейс изначально был разработан так, чтобы два устройства спокойно уживались рядом на одной шине. Про разделение по времени никогда не слышали чтоли? :) А представьте теперь себе шину данных процессора, к которой подключено несколько десятков чипов и они прекрасно общаются с процессором не мешая друг другу. А иногда и общаются между собой — без процессора — опять-же не мешая соседям. Если следовать подобным «народным» теориям, то разработчикам пришлось бы от процессора к каждому чипу тянуть отдельную шину данных. А уж про прямую передачу данных между чипами вообще пришлось бы забыть.
        • 0
          Все так. Протокол IDE позволяет иметь два устройства + контроллер на шине.
          Только пока контроллер передает данные на master, slave стоит и ждет, пока контроллер освободит шину. Поэтому высокая активность HDD мешает CD.
          • 0
            Арбитраж IDE-интерфейса выполнен достаточно грамотно, чтобы устройства нормально жили вместе. Шина не отдаётся монопольно какому-то из устройств если ему приспичило переслать большой объём данных. Данные передаются блоками. Поэтому пока пропускная способность интерфейса превышает суммарный объём данных, передаваемых обоими устройствами по шине — никто никому не мешает.
            • +1
              В теории, IDE, конечно, был придуман верно) Но вот на практике сам помню — был у меня чудный CD-ROM от Creative (который был с пультом ДУ и позволял проигрывать аудиодиски без участия компьютера), с которым было связано много «веселых» историй. Например, когда он останавливал диск при отсутствии активности, потом разогнать его обратно для него было проблемой — могло занимать приличное время и могло закончиться чтением нулей (!) вместо реальных данных сразу после разгона. Поэтому, услышав шум из него (понимая, что сидюк разгоняется), я нажимал eject и тут же обратно заталкивал лоток — после такого он стартовал верно.
              Возвращаясь к теме — когда он висел на одном шлейфе с жестким диском, то временами как бы захватывал его целиком — пока операция с диском не закончится (например, тот же разгон), доступ к жесткому диску также был блокирован. Когда разнес на разные шлейфы, такая проблема исчезла.
              Ну и позднее, когда скорости устройств поднялись, на UDMA33 (33 мб/с) была уже видна разница в скорости копирования, когда устройства сидели на одном шлейфе и на разных.
              • 0
                нажимал eject и тут же обратно заталкивал лоток
                Это Вам повезло, что кретивщики поленились имплементировать ATAPI полностью — в частности, команду «MEDIA LOCK».
                пока операция с диском не закончится (например, тот же разгон), доступ к жесткому диску также была блокирован.
                А это, похоже, проблема в реализации драйвера, который должен был распознавать состояние «милый, я ещё не готова».
                • 0
                  Мне кажется, Creative частенько отличался проблемами с драйверами =) Кстати, одну из них (не связанную с CD-ROM) я только что описал в комменте ниже (если интересно).
                  Но тут еще может быть то, что CD-ROM, скорее всего, работал только в PIO и не поддерживал UDMA. Вроде вешание именно таких двух устройств на один шлейф серьезно снижало скорость работы с жестким диском.
          • 0
            Причина, по которой сборщики (так-же как и я) предпочитали садить устройства на разные шины, была в другом: изредка попадались устройства, которые не точно следовали спецификациям. Бывали в них и баги, как аппаратные, так и программные. Потому что разработчики — люди, а людям свойственно ошибаться. Эти баги могли не проявлять себя до тех пор, пока устройство сидело на шине в гордом одиночестве. Но стоило подсадить к ним «партнёра» — и вот тут могло начаться какое-нибудь веселье. А могло и не начаться. Вот, чтобы голова об этом не болела, сборщики и рассаживали дивайсы по разным шинам (если, конечно, была такая возможность).
  • 0
    Прикольно. Давным давно у меня был точно такой-же винт — при копировании на него изредка портились файлы. Я, недолго думая, пересадил на него микросхему кэша с другого такого-же винта (умершего от цирроза печени логики) — и проблемы с порчей данных прекратились. Правда это ничуть не спасло его от дальнейшего цирроза логики…
    • 0
      Как я пишу в конце письма, я бы с радостью списал всё на битый кэш, вот только тогда проблема проявлялась бы и при копировании на этот винт с любого другого (или с него самого на себя) — так нет, исключительно с сидирома, и исключительно если тот стоит как secondary master.
      • +1
        Да я понял это сразу при прочтении — я внимательно читаю посты. :) Просто всколыхнуло память и выплеснуло на берег тот случай с кэшухой, о чём и решил с Вами поделиться. В Вашем же случае доподлинно так и осталось неизвестно, в чём проблема заключалась — Вам же заменили целиком винчестер. Может это просто напросто начинался тот самый пресловутый цирроз.
        • +2
          Я просто никак не могу представить, почему для проявления аппаратной проблемы требовался именно активный, именно CD-ROM, именно как secondary master — ведь при таком раскладе единственное место, где сигнальные линии могли бы ну хоть как-то пересекаться, было бы внутри чипсета, но от замены чипсета проблема как раз не исчезала.
          • 0
            Сейчас можно только строить догадки. Например, можно предположить, что при копировании использовался режим DMA — данные ехали с привода на винт через чипсет минуя процессор. Причём ехали в синхронном режиме. Если разработчики схемы/бисухи/фирмвара винта где-нибудь накосячили и не учли возникающие при этом задержки — это могло приводить к подобным «спецэффектам».
  • 0
    С подобной ситуацией столкнулся когда-то на mp3 плеере MPIO FY400. Сначала просто — wtf почему архив не читается нормально! А потом, когда начал разбираться, обнаружил, что при записи в произвольных местах иногда портится один бит. Такое проявлялось весьма случайно и в основном при работе с большими файлами. Попытки выяснить причину успехом не увенчались (питание контроллера/флешки вроде в норме, микросхемы припаяны нормально, но на всякий случай переприпаяны).
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    У меня была сетевая карта, которая вешала намертво компьютер при попытке копировать на сеть xls файлы. Какой то баг чипа.
  • 0
    Тоже сталкивался с побайтовой разницей, только переданного по сети файла. В итоге расследование выдало брак серии которую решили энтузиасты своими силами. Почему в офф. прошивках проблему до сих пор не решили? (А она у примерно 50% устройств). Ну наверное потому что никто не проверяет все файлы побитово — вот и результат. Полная история решения по ссылке.
    • 0
      никто не проверяет все файлы побитово — вот и результат.

      Я с тех пор проверяю всегда. Как говорил Жванецкий, «чуть больше времени на выход — зато спокоен, что действительно ушёл, действительно пошёл домой, и действительно лёг спать».
    • 0
      Почему-почему… Потому что проприетарная лицензия?
  • 0
    Проверка CRC — этого достаточно?
    • 0
      Да — но если откуда-то взялась готовая — и, что самое главное, актуальная CRC.

      В противном случае придётся:
      • Прочитать данные исходного файла
      • Подсчитать CRC
      • Прочитать данные из скопированного файла
      • Подсчитать CRC
      • Сравнить подсчитанные CRC

      Тогда как в моём случае достаточно
      • Прочитать данные исходного файла
      • Прочитать данные из скопированного файла
      • Сравнить прочитанное

      Почему-то мне кажется, что второй путь содержит меньше операций.
      • 0
        Ну я обычно копирую важные файлы при помощи Total Commander, он содержит функцию Verify CRC и проверяет сразу после копирования. Да, проверка занимает по времени столько же, сколько копирование.
        • 0
          Ненадёжно: проверять нужно после полного сброса всех кэшей — включая кэш винчестера. Поэтому я всегда проверяю после включения/выключения компьютера.
  • +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 года.
    • 0
      Здорово, что поддержка фуджици оказалась на уровне!
      Как говорят в деревнях, «авотх… вост!». Как Вы могли заметить из преамбулы письма, это был инженер, с которым я за два года до этого общался по поводу другой проблемы с фуджиками, поэтому я в этот раз написал ему напрямую. А как я его выцепил в первый раз — это уже совсем другая история…
      • 0
        > это уже совсем другая история…
        То есть приквел будет? Ждать? Очень хотелось бы.
        • 0
          Ну приквел гораздо менее детективный, и амбула истории уже раскрыта в письме:
          я обращался к Вам пару лет назад — она заключалась в том, что диск Fujitsu более ранней серии, MPD, случайным образом намертво зависал — настолько, что не помогала кнопка RESET, а только выключение питания — во время обращений к CD-ROM на Secondary IDE контроллере.
          А чтобы вспомнить детали, надо будет залезать в мои старые почтовые архивы, а это надолго.
  • +1
    Хм… Я тут вспомнил, что тоже имею привычку перепроверять то, что записал или упаковал, и года полтора назад порадовался тому, что имею. Дело в том, что купил я себе ноутбук. Хороший, быстрый, но стоило на нём долго поработать или немного поиграть — начинал странно глючить и просто повисал. Но не отправлять же его в сервис по гарантии со словами «странно работает»? И тут решил я упаковать несколько гектаров файлов и сразу же перепроверить, а открывается ли архив после упаковки? Такая вот у меня привычка. И к моему изумлению тест остановился с ошибкой во время распаковки одного из файлов внутри архива. Ок, запускаем тест ещё раз — снова ошибка… но уже в другом файле! Налицо проблема с перегревом и расхождением где-то контактов. И вероятнее всего материнки — основные источники тепла в ноутбуке ведь расположены именно там. Что, кстати, в последствии и подтвердилось… после того, как мне в сервисе упорно два раза винт меняли не желая выполнить приложенную на бумажке процедуру тестирования проблемы и верить в то, что с материнкой может быть что-то не так. -_-
  • +2
    Я тоже проверяю. Вот сейчас стоит сервер рядом. Выполняются следующие действия:
    1. Копируется около 2ТБ клипартов с тома на том.
    2. На копии ставится флаг NTFS «сжато».
    3. Сравнивается с оригиналом — совпадение.
    4. Дефрагментация при помощи O&O Defrag.
    5. Сравнивается с оригиналом — сжатые файлы случайным образом в случайных местах повреждены.

    Сравнивайте ваши данные чаще :)
  • 0
    А чем данные сравниваете?
    • +1
      В FAR есть хороший плагин Advanced Compare.
      • 0
        А какие есть ещё методы? Хэш сумма не показатель?
        • 0
          Total Commander умеет сравнивать директории в рамках функции синхронизации.
        • +1
          Хэш сумма не показатель?
          Показатель, но (если не учитывать коллизии) есть ещё одно «но»
          • 0
            Объясняю вопрос, есть несколько офисов и серверов, вот я через не быстрый интернет тащу к себе БД. По окончанию надо убедиться в целостности, запустить проверку хэше, не так уж и долго.
            Хотя если сразу «правильно» копировать, то может и не понадобится сверять.

            И какой алгоритм лучше подходит для хэширования (md5, sha, crc...)?

            Проблема в том, что тотал коммандер платный и не пользуюсь, также не пользуюсь фаром, поэтому только рада копирования его запускать, не хотелось бы. К тому же не знаю как фар работает с сетью, так как копируется по VPN'у.

            Мне интересны все варианты, а там уже думать и выбирать.
            • 0
              При таком раскладе файл лучше всего передавать при помощи SFTP, и не столько ради безопасности, сколько потому, что SSH-туннель проводит контроль целостности проходящих через него данных, что снижает вероятность невидимого повреждения файла. А после получения всего файла можно сверить его контрольные суммы на обоих машинах при помощи либо cksum (быстро), либо md5 (медленнее, но надёжнее).
              А вообще для таких задач есть утилита rsync.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.