LINUX.ORG.RU

Один эпизод о достижениях современного глюководства

 ,


0

6

Недавно я обнаружил странность: распаковка огромного (45Гб) многотомного архива завершилась с ошибкой, но последующее тестирование этого же архива показало, что ошибок нет.
Я удивился, ещё несколько раз протестировал этот архив, и холодок ужаса пробежал по моей спине: архив тестировался то как исправный, то как ошибочный, причём ошибки возникали на разных томах архива, случайно.
Это могло означать лишь одно: мой комп (стоимостью больше моей месячной зарплаты) начал глючить. Я никогда в жизни не разгонял никакие частоты и всегда ценил надёжность выше производительности, а тут такое…

(это была драматичная завязка, дальше идёт техническая часть и неожиданный финал)

Я приступил к определению источника неисправности, планируя проводить тестирование после замены каждого компонента системы.
Тестировал я многократным (60 раз) чтением архива с подсчётом MD5 каждого тома.
Замечу, что общий объём архива больше, чем размер моей оперативы, поэтому происходило 60 считываний именно с диска.

for i in {1..60}; do md5sum *.rar > $(date +%s.txt); done; md5sum *.txt

На экране отобразились 60 хэш-сумм, из которых большинство совпадали, но 8 штук отличались. Внутри каждого из этих 8 .txt файлов отличалась хеш-сумма лишь какого-то одного тома архива, каждый раз разного.
Короче говоря, при чтении файлов с диска возникает в среднем одна ошибка на 350Гб.

На компе у меня один HDD, разбитый на два раздела: ntfs и ext4.
Загрузиться можно с линукса или с винды.
Винда видит только ntfs, линукс видит оба раздела.
Файлы с архивом лежат на ntfs разделе, а загружаюсь я в линукс.

Первым делом я скопировал эти файлы с ntfs на ext4 и повторил тестирование. К моему удивлению, получилось 0 ошибок из 60.
Вторым делом я загрузился в винду и повторил тестирование файлов, лежащих на ntfs-разделе (пришлось написать скриптик, который делает то же самое, что и тот однострочник на bash). Я удивился ещё больше, потому что и здесь всё было в порядке: 0 ошибок из 60.
И тут до меня дошло: ошибка - чисто софтовая, а железо у меня исправное!
Выдох облегчения.

Будь проклят тот день, когда я сел за баранку этого дебиана! )))
У меня debian 9, ntfs-драйвера «искаропки».
Прошу вас повторить мой эксперимент и поделиться результатами, если у вас есть ntfs-раздел на винте с полусотней гигабайт хлама на нём.


Без обид, но просто так чексуммить 100+ гигабайт вряд ли кто побежит. Тем более, что ты даже не удосужился уточнить, какой именно драйвер используется: ntfs-3g или ntfs.ko из ядра.

Кстати, правильно ли я понимаю, что

Первым делом я скопировал эти файлы с ntfs на ext4 и повторил тестирование. К моему удивлению, получилось 0 ошибок из 60.

означает, что с ext4 файлы читаются одинаково, но результаты чтения отличаются от того, что нативно читается виндой? Иными словами, при копировании тоже возникла ошибка?

kawaii_neko ★★★★
()

Очень много непоняток.

  • ОС. Если это в винде, где драйвер нтфс нативный - это одно. Если через нтфс-3г - совершенно другое.
  • Память. Если у тебя начала сбоить оперативка, тоже такое возможно.
  • Софт, которым ты открываешь свои архивы, включая даже ветку, из которой он у тебя собран.
Zhbert ★★★★★
()
Ответ на: комментарий от kawaii_neko

при копировании тоже возникла ошибка?

нет, не возникла
копирование 45Гб скорее пройдёт успешно, т.к. в среднем 1 ошибка на 350Гб

Без обид, но просто так чексуммить 100+ гигабайт вряд ли кто побежит

а чо такого?
это ж просто оставить комп работать на ночь
или ты боишься, что тебе потом счёт за электричество придёт? ))

и вообще, ты говоришь так, как будто я что-то для себя прошу ))
у тебя сидит точно такой же баг, только ты про это ещё не знаешь

какой именно драйвер используется: ntfs-3g или ntfs.ko из ядра

а как это определить?
могу только сказать, что mount говорит fuseblk
и что пакет ntfs-3g установлен

Egor_
() автор топика
Последнее исправление: Egor_ (всего исправлений: 1)
Ответ на: комментарий от Egor_

Я не совсем понимаю почему он тогда не распаковывается нормально. Если ошибка возникает при чтении раз в 350 Гб, то почему она возникает при распаковке 45 Гб архива? Может это не раз в 350 Гб, а раз в N минут?

vitruss ★★★★★
()
Ответ на: комментарий от vitruss

Если ошибка возникает при чтении раз в 350 Гб, то почему она возникает при распаковке 45 Гб архива?

да, ошибка возникла на 45Гб архиве, это было маловероятно, но благодаря этому случаю я её заметил
на 45Гб ошибка возникает нечасто, поэтому я тестирую прогоном почти 3Тб через хэш
равномерна ли вероятность ошибки - я не очень понял. мне кажется, что чем дольше тестируешь, тем меньше вероятность ошибки
на проведённых 60 чтениях ошибка случилась на №№ 1, 2, 8, 12, 13, 14, 17, 50

Egor_
() автор топика
Ответ на: комментарий от saahriktu

я уже понял, что на ЛОРе самый частый совет: $itemname ненужно )))

Egor_
() автор топика
Ответ на: комментарий от Dark_SavanT

Почему это не филиал. написано же «целью является создание основного информационного ресурса». Что в линуксе может основне́е ядра́?

Einstok_Fair ★★☆
()

это очень интересно. но всем лень. а ты memtest все же прогони по полной

zendrz ★★
()
Ответ на: комментарий от targitaj

но если железо багованое, есс тут не при чем. 350ГБ слишком мало, это явно бага

zendrz ★★
()
Ответ на: комментарий от kostyarin_

Ядерный - да. Все его баги заботливо описаны в его документации. ntfs-3g, который через fuse, у меня всегда работал без замечаний. Но он тормоз. Рапортовать в ядрёную багзиллу о его багах бессмысленно, это сторонний проект.

Jameson ★★★★★
()
Ответ на: комментарий от saahriktu

просто ты нолайфер и инцел, к которому не может придти тянощка с ntfs внешним диском

anonymous
()
Ответ на: комментарий от targitaj

оверпрайс и стоковые частоты медленные - требует разгона

anonymous
()

Первые года, когда 7z появился, запросто могло быть, что архив 7z архиватор не мог распаковать.
Поэтому вместо него использовал rar.

Кстати rar лучше использовать для больших объемов данных.
Почему?
Потому что при попытке взять из архива что либо 7z производит его полную распаковку /а если архив скажем 50GB …/.
Архив rar по другому устроен и у него такого безобразия как в 7z нет.

anonymous
()
Ответ на: комментарий от anonymous

Первые года, когда 7z появился, запросто могло быть, что архив 7z архиватор не мог распаковать.

Точнее более новая версия 7z могла не распаковать архив.
Ныне вроде 7z можно использовать.

anonymous
()

Это могут быть и не достижения, и не современного )

Вот тут Насколько все же важна ECC-память (комментарий) praseodim рассказывал как боролся с подобным в древности )

Запустил md5sum на ~85ГБ файл vbk на ntfs - пока вроде всё нормально считает.

Toxo2 ★★★★
()
Последнее исправление: Toxo2 (всего исправлений: 1)

При чем тут Линукс и в частности дебиан? К NTFS дровам приложил руку какраз мелкософт. Когда я возился с ntfs-3g в какой-то момент вылезло сообщение you can restart Windows now… ) От мелких всегда одни подляны

jtad
()
Последнее исправление: jtad (всего исправлений: 3)
Ответ на: комментарий от anonymous

Потому что при попытке взять из архива что либо 7z производит его полную распаковку /а если архив скажем 50GB …/. Архив rar по другому устроен и у него такого безобразия как в 7z нет.

Какой ужас…

https://i.stack.imgur.com/Lb7m2.jpg (solid / non-solid)

anonymous
()

Прошу вас повторить мой эксперимент и поделиться результатами

Двадцать пять комментариев и никто не написал НЮПА? ЛОР ты молодеешь и молодеешь.

Ну, серьёзно, кмк, тут столько специфичного и тебе нтфс и тебе гигабайтные файлы на нтфс, что просить это повторить и правда наивно.

А проблема скорее всего, как сказали, в памяти.

vvn_black ★★★★★
()
Последнее исправление: vvn_black (всего исправлений: 1)
Ответ на: комментарий от anonymous

Проверил лишний раз.

Не ужас, а медленно.

anonymous
()
Ответ на: комментарий от vvn_black

А проблема скорее всего, как сказали, в памяти.

Ностальгия.
Сколько лет прошло, а без содрогания вспомнить не удается.
Был такой диназавр М-6000.
Так вот возникла проблема.
Crash возникал не часто, но при работе определенной программы.
Вообщем как сказали электронщики «При записи в один из байт, производилась модификация и иного байта.».
Жуть!

anonymous
()
Ответ на: комментарий от anonymous

Вообщем как сказали электронщики «При записи в один из байт, производилась модификация и иного байта.».

Не программа была виновата, а железо.
Аналогичный баг /но уже не от железа, а программный/ был у компилятора Pascal.
И то и то вылечили.

anonymous
()
Ответ на: комментарий от ya-betmen

Все верно, пора выкинуть этот убогий нтфс.

То бишь в internals NTFS ни кто «не осилил» разобраться?

anonymous
()

Чтобы повторить эксперимент, достаточно посчитать хэш-сумму на объёме данных в 2.5 - 3 терабайта, считанных с NTFS-раздела в линуксе?

PeleWin
()
Ответ на: комментарий от i-rinat

Проверь память memtest’ом.

гонял сейчас memtest86+ в течение 8 часов, он ничего не нашёл
так что дело не в памяти

Egor_
() автор топика
Ответ на: комментарий от Egor_

гонял сейчас memtest86+ в течение 8 часов, он ничего не нашёл так что дело не в памяти

На других компьютерах то же глюки?

anonymous
()
Ответ на: комментарий от anonymous

при попытке взять из архива что либо 7z производит его полную распаковку /а если архив скажем 50GB …/. Архив rar по другому устроен и у него такого безобразия как в 7z нет.

это потому что 7z делает solid-архивы по умолчанию, а в rar нужно руками опцию -s указывать
кстати, я всегда её указываю

Egor_
() автор топика
Ответ на: комментарий от anonymous

На других компьютерах пробовали распаковать свой архив?

конечно
на том компе, где архив был создан, он успешно прошёл тестирование (прежде чем удалить файлы, которые я запаковал, я проверяю целостность архива)

только при чём тут структура архива?
баг не связан с логической структурой файла - я просто многократно считаю хеш-сумму одного и того же файла, и она иногда не совпадает

Egor_
() автор топика
Ответ на: комментарий от Egor_

это потому что 7z делает solid-архивы по умолчанию, а в rar нужно руками опцию -s указывать кстати, я всегда её указываю

Использую plugin FAR для паковки в 7z.
Опции:

  • нормальный;
  • добавить и заменить
anonymous
()
Ответ на: комментарий от Egor_

только при чём тут структура архива?

Об этом вам не писал.
Баг на других компьютерах воспроизводится?

anonymous
()
Ответ на: комментарий от fornlr

покупай вон Paragon NTFS

кошмар! платный драйвер для линукса!
и что, парагонцы платят авторам ntfs-3g, чтобы те свои баги не исправляли? )))

Egor_
() автор топика
Ответ на: комментарий от anonymous

Баг на других компьютерах воспроизводится?

Может быть программа, подсчитывающая хеш сумму глючит?

anonymous
()
Ответ на: комментарий от vvn_black

тут столько специфичного и тебе нтфс и тебе гигабайтные файлы на нтфс, что просить это повторить и правда наивно.

да вроде бы всё указывает на баг в линуксовом драйвере ntfs, и у тебя этот баг точно такой же у меня )))

А проблема скорее всего, как сказали, в памяти.

проверил, память нормальная
при хешировании файлов ошибка находится раз в 40 минут, а при тестировании памяти прошло 8 часов без ошибок

Egor_
() автор топика
Ответ на: комментарий от PeleWin

Чтобы повторить эксперимент, достаточно посчитать хэш-сумму на объёме данных в 2.5 - 3 терабайта, считанных с NTFS-раздела в линуксе?

да
если есть файл в 1Тбайт, то просто посчитай его хеш-сумму 3 раза

Egor_
() автор топика

Сделай эксперимент с файликами разного размера на NTFS-разделе:

$ dd if=/dev/urandom of=1gb.raw bs=1024K count=1024 # 1GiB
$ dd if=/dev/urandom of=4gb.raw bs=1024K count=4096 # 4GiB
$ dd if=/dev/urandom of=10gb.raw bs=1024K count=10240 # 10GiB

И т. д. Попробуй определить нижнюю границу. Вангую, она упрётся в твой объём RAM +/- пару ГБ.

Если ошибка с md5sum проявляется и на подобных файлах, то можно заводить баг в багтрекере твоего NTFS-драйвера.

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 3)
Ответ на: комментарий от greenman

Попробуй погонять mprime

в репозитории дебиана такой проги нет
иду на сайт https://www.mersenne.org/download
там можно скачать бинарник, но это не наш путь
скачиваю исходники и внутри вижу… бинарник! (*.o)
идите вы в попу с такими блобами

Egor_
() автор топика
Последнее исправление: Egor_ (всего исправлений: 1)
Ответ на: комментарий от anonymous

Баг на других компьютерах воспроизводится?

в этом и есть цель моего поста - убедиться, что баг воспроизводится на других компах (например, на твоём)

Egor_
() автор топика
Ответ на: комментарий от anonymous

Может быть программа, подсчитывающая хеш сумму глючит?

глючат две программы: rar и md5sum
и как избирательно они глючат: на одном разделе диска есть глюки, а на другом - нет )))

Egor_
() автор топика
Ответ на: комментарий от Egor_

глючат две программы: rar и md5sum и как избирательно они глючат: на одном разделе диска есть глюки, а на другом - нет )))

Где то, в чем то глюк есть.
Может быть дело и не в ОЗУ.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.