Запись опубликовал Uncle Vёder
1824 просмотра
Буквально несколько дней назад со мной (а точнее - с моим компьютером) произошла одна неприятная история. Ничего нового я из неё, в принципе, не почерпнул, но в очередной раз утвердился в некоторых вещах. Если вы любите, чтобы ваш компьютер работал без сбоев и ошибок - эта информация может оказаться очень полезной.
Началось всё очень просто. Стали как-то криво работать торренты. Допустим есть у нас некая папка, и в ней лежит 10 файлов. Создаём мы торрент из одного и встаём на раздачу - всё хорошо. Повторяем операцию для оставшихся девяти - всё опять же отлично. А теперь берём и делаем один большой торрент на всю папку. И вот тут начинаются проблемы: при попытке встать на раздачу некоторые файлы отображаются недокачанными, причём всего на 1-2%, а то и меньше. Чешем репу, пересоздаём торрент - та же борода.
Тут стоит сделать небольшое отступление и пояснить, как вообще работает протокол BitTorrent. Подробно эту информацию можно почерпнуть из той же википедии, а здесь кратко о том, что из себя представляет торрент-раздача.
При создании торрента программа как правило предлагает нам выбрать размер блока.
Далее файл считывается с диска, условно разбивается на блоки заданного размера, и для каждого блока строится хэш (по алгоритму SHA1). Отдельно сохраняется информация об имени и размере файла. Это и есть основная составляющая torrent-файла. Когда клиент сети BT запрашивает данные, он получает их кусками в виде тех самых блоков, после чего локально пересчитывает и проверяет хэш, а при его несовпадении - запрашивает блок повторно. Аналогично при попытке встать с уже скачанными файлами на раздачу отдельно сверяется каждый блок. Такая система обеспечивает довольно хорошую целостность данных и защиту от коллизий.
Чуть интереснее происходит, если файлов в раздаче несколько. Чтобы не расходовать блоки (а значит и сетевой траффик впоследствии) впустую (особенно когда блоки здоровые - по 16МБ, а файлов много и они мелкие), файлы считываются потоком непрерывно в виде одного большого сырого набора данных. Получается, что если хвост первого файла занял не весь доступный объём блока, то оставшееся свободное место будет дописано уже данными следующего файла (именно поэтому при выборочном скачивании содержимого торрент-раздач зачастую всё равно подтягивается разный мусор).
Так вот, в нашем случае проблема заключалась в том, что при проверке хэшей после добавления свежесозданного торрента наблюдалось расхождение данных. Причём расхождение мизерное - всего один блок на файл, да и то не на каждый. Но расхождение было. А если расхождение есть у инициатора раздачи - значит и остальные не смогут её до конца скачать. Оперативно нашли простой выход: отправить файлы для групповой раздачи в отдельную резервацию. Тогда всё создавалось и перехэшировалось нормально. Хотя как нормально... тоже через раз. Нужно было копать глубже и решать проблему.
Первым делом подозрение пало на сам алгоритм BitTorrent и файловую систему NTFS. Основывалась идея на том факте, что проблемы всплыли именно с многофайловыми раздачами, в которых один блок может содержать данные сразу нескольких файлов. Была мысль, что в некоторых исключительных случаях вместо пустого хвоста файла в данных каким-то образом оказывается рандомная каша, которая и вызывает расхождение.
Для начала были перепробованы разные варианты программ для создания torrent-файлов (в нашем случае это были qBittorrent 3.4.3, uTorrent 2.2.1 и Torrent Builder 3.2.2). Результат оказался довольно странным: торренты созданные разными программами давали расхождение в разных файлах. Это исключило влияние конкретной программы, но только ещё больше запутало ситуацию.
Определённо нужно было найти в этом какую-то закономерность. Я подсчитал MD5-хэши исходных файлов, с которыми успешно работали одиночные раздачи. А потом посчитал MD5-хэши для тех же самых файлов, но лежащих в резервации для групповой раздачи. Не сказать, что я сильно удивился тому, что хэши местами не совпадали. Проблема была не в BitTorrent, а в самих файлах.
Решив воспроизвести ошибку, я выбрал один файл и скопировал его в другую папку на том же HDD. MD5-хэш поменялся. Почесав бороду, я сделал ещё одну копию файла, но в этот раз хэш остался неизменным, что меня сильно обескуражило. Сделал третью копию - хэш опять совпадает с исходным. Тут я решаю перепроверить первую копию... и да, хэш тоже совпал с хэшем исходного файла. Тут в самую пору было бы задуматься о поехавшей крыше. Но я решил продолжить эксперименты, и таки нашёл ситуацию, в которой баг 100% воспроизводится: нужно было копировать сразу по несколько файлов.
Тем временем была предпринята попытка сравнить различающиеся копии файлов. На тестовых образцах все отличия составляли ровно 1 байт. Причём байт этот находился в файле совершенно произвольно, а не в конце, что забивало последний гвоздь в крышку гроба теории о глюках алгоритма BT.
Но кого же тогда подозревать? Файловую систему? Жёсткий диск? Шифрование и сжатие данных NTFS были у меня выключены изначально. Ради эксперимента отключил последнее, что могло влиять на результат - кэширование операций записи средствами той же NTFS. Результата это не дало никакого (ну, кроме снижения производительности). Был так же испробован и другой HDD, но и на нём ошибка спокойно воспроизводилась в тех же условиях. Иногда даже не нужно было копировать файл - каждый новый запуск MD5 давал новый хэш. А совсем неразбериху в ситуацию вносило то, что исходный хэш у некоторых копий действительно периодически восстанавливался.
Что может произвольно портить файлы, при этом иногда ещё и восстанавлиая их в изначальное состояние? Не знаю, сколько бы я ещё ломал голову, если бы Minamoto Michi не подкинул интересную идею: может, с файлами и дисками на самом деле всё в порядке, просто они криво читаются? А действительно. Куда читаются файлы? Где считаются функции хэширования? Оперативная память. Вот я мудааак...
Тут стоит сделать ещё одно небольшое отступление. Весной этого года я решил наконец слегка подразогнать свой компьютер и даже планировал написать об этом пост в бложек. Однако планам не суждено было сбыться. Если разгон видеокарты удался относительно успешно, то с процессором вышла полная жопа. Он легко брал высокие частоты, но совершенно отказывался их удерживать. Промучавшись около недели, я выяснил, что всё упёрлось в мощность цепей питания материнской платы. Они банально не выдерживали возросшей нагрузки и слишком быстро перегревались. А поскольку покупка новой материнки в мои планы не входила, затею пришлось забросить. Тем не менее, в процессе перебора конфигураций я слегка подразогнал память со штатных 1333МГц до 1600МГц, и даже проверил систему в этом режиме на стабильность (с помощью OCCT).
Память. Да, память. Я уже давно знал, что сбои в оперативной памяти могут привести к порче данных на внешних носителях. У меня уже был печальный опыт на другом железе, когда из-за переразогнанной памяти слетела MBR на системном диске. И в последнее время я действительно наблюдал чуть больше различных мелких глюков софта, чем привык видеть обычно, но не придал этому значения.
При первой же выдавшейся возможности, я хватанул первое, что попалось под руку (а под руку попался старый HBCD с Memtest86+ 4.20) и запустил тест. Буквально через несколько минут перед моим взором предстала такая картина:
В принципе, дальше тест уже можно было не продолжать. Если бы даже он завершился без ошибок, это всё равно не отменило бы сбои в начале. Рабочая память не должна давать ни одной ошибки.
Скинув параметры памяти в заводские настройки, я повторно врубил Memtest86+ и укатил на дачу. И не зря. Учитывая, что памяти у меня 16ГБ, каждый проход полного теста занимал около 3 часов. Вернувшись с дачи, я увидел, что вполне успешно завершены уже два прохода. Можно было для верности погонять ещё, но на это уже не было времени.
Загрузив систему, я попытался повторить все те действия, которые приводили к появлению битых копий файлов. Ни в одном из вариантов баг больше не воспроизводился.
Мораль этой истории:
1. Если у вас проблемы с битыми файлами - не факт, что виноваты в этом жёсткий диск или файловая система. Проблемы с оперативной памятью тоже легко могут оказаться причиной сбоев.
2. Тестов на стабильность не бывает много. Если у вас уверенно прошёл тест OCCT - не забудьте попробовать Linpack, AIDA, Prime, Memtest и вообще всё, что попадётся под руку. Чем больше и дольше - тем лучше.
3. Если компьютер глючит больше чем обычно, а вы его не так давно разгоняли - не стоит пытаться искать тому какие-то сторонние причины. Начните с исключения основного фактора, т.е. самого разгона.
Не забывайте ставить лойс, если хотите, чтобы я таки написал большой пост про разгон. Ну или дизлойс, если хотите, чтоб я убился апстену. И комменты тоже пишите.
5 Комментариев
Рекомендуемые комментарии