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-раздел на винте с полусотней гигабайт хлама на нём.


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

Да, я на торрентах когда-то словил удивительное открытие. Туда-сюда 500 гиг скопировал (всё В ВЕНДЕ) и потом перехешировал. Вот это было открытие! Так что, уже дошло про необходимость EEC или пока еще нет?

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

Для начала, мемтестов сейчас имеется ТРИ. Но это не поможет. Память скорее всего рабочая, просто ты ловишь глитчи или как оно там называется. Вот эти вот гении выше - они просто никогда ничего объёмного не считали. А может им просто везёт. Данные бьются, это факт, и на современных объёмах это уже становится заметно. Лечится применением ECC.

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

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

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

Ну ты уже увидел. Или не увидел? Как вариант, можешь еще попробовать кабель SATA поменять, если у тебя там sata.

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

Ну ты уже увидел. Или не увидел?

я увидел, что глюки на ntfs-разделе есть, а на ext4-разделе нет.
как отсюда следует, что неисправна именно память?

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

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

Ах, я дурак, до конца первое сообщение не дочитал. У тебя правда странный случай. Нативно и там и там ошибок не показывает. А если запустить венду в виртуальной машине, выдать есть ntfs диск целиком и так тест прогнать? Я-то у себя с торрентами словил открытие нативно, в родной ФС.

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

Был оригинальный софт memtest86 written by Chris Brady. С него запилили форк Memtest86+, который опен и фри https://www.memtest.org/. Бывший оригинальный софт теперь принадлежит, развивается и продаётся компанией PassMark https://www.memtest86.com/. И есть еще мемтест от автора S&M https://testmem.tz.ru/testmem5.htm

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

эти мемтесты говно и ничего не ловят, для твоего testmem5 нужен специальный конфиг, чтобы он что-то ловил: https://github.com/integralfx/MemTestHelper/blob/master/DDR4%20OC%20Guide.md

что комично, когда последний раз разгонял, быстрее всего ловил ошибки обычный 7z b, правда не ручаюсь, что с битой памятью или на другом железе будет то же самое

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

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

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

ещё в DRAM Calculator for Ryzen более-менее норм тест памяти

anonymous
()

Когда выясните причину, то просьба рассказать.

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

Запустил бесконечный цикл на нескольких файлах от 3 до 8 Гб размером. Пока посчиталось около 50 Гб, ошибок, понятное дело, пока нет. Как дойдёт хотя бы до терабайта, отпишусь.

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

bitfade тест тоже запускал?

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

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

пока вроде всё нормально считает

Всё, закончилось. ~7 часов, ~2.5 ТБ. Ошибок нет.

Делал так:

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

Исходные данные такие:

$ cat /sys/class/block/sdd/device/model
WDC WD10EFRX-68F

$ grep -w 'DATA' /etc/fstab
UUID=F2D291F3D291BBF3  /mnt/DATA ntfs rw,uid=1000,gid=1000,dmask=0000,fmask=0111 0 0

$ stat -c "%s" 1.vbk
91540979712

$ file 1.vbk
1.vbk: dBase III DBT, version number 0, next free block index 9

$ ntfs-3g --version
ntfs-3g 2017.3.23 external FUSE 29

$ fusermount --version
fusermount version: 2.9.9

$ xuname
Void 5.4.30_1 x86_64 GenuineIntel uptodate rrrmFFFF

Результат такой:

912d356b5bab2b1dd012dc1838a97955  1586409117.txt
912d356b5bab2b1dd012dc1838a97955  1586409931.txt
912d356b5bab2b1dd012dc1838a97955  1586410745.txt
912d356b5bab2b1dd012dc1838a97955  1586411561.txt
912d356b5bab2b1dd012dc1838a97955  1586412375.txt
912d356b5bab2b1dd012dc1838a97955  1586413190.txt
912d356b5bab2b1dd012dc1838a97955  1586414005.txt
912d356b5bab2b1dd012dc1838a97955  1586414819.txt
912d356b5bab2b1dd012dc1838a97955  1586415635.txt
912d356b5bab2b1dd012dc1838a97955  1586416450.txt
912d356b5bab2b1dd012dc1838a97955  1586417266.txt
912d356b5bab2b1dd012dc1838a97955  1586418081.txt
912d356b5bab2b1dd012dc1838a97955  1586418895.txt
912d356b5bab2b1dd012dc1838a97955  1586419709.txt
912d356b5bab2b1dd012dc1838a97955  1586420523.txt
912d356b5bab2b1dd012dc1838a97955  1586421337.txt
912d356b5bab2b1dd012dc1838a97955  1586422152.txt
912d356b5bab2b1dd012dc1838a97955  1586422966.txt
912d356b5bab2b1dd012dc1838a97955  1586423780.txt
912d356b5bab2b1dd012dc1838a97955  1586424595.txt
912d356b5bab2b1dd012dc1838a97955  1586425409.txt
912d356b5bab2b1dd012dc1838a97955  1586426223.txt
912d356b5bab2b1dd012dc1838a97955  1586427037.txt
912d356b5bab2b1dd012dc1838a97955  1586427851.txt
912d356b5bab2b1dd012dc1838a97955  1586428666.txt
912d356b5bab2b1dd012dc1838a97955  1586429480.txt
912d356b5bab2b1dd012dc1838a97955  1586430294.txt
912d356b5bab2b1dd012dc1838a97955  1586431108.txt
912d356b5bab2b1dd012dc1838a97955  1586431922.txt
912d356b5bab2b1dd012dc1838a97955  1586432737.txt

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

Запустил бесконечный цикл на нескольких файлах от 3 до 8 Гб размером
Ошибок нет.

Файлы возможно в кеше были. Так что не всё так однозначно.
Надо бы кеш обнулять ещё.

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

Файлы тестируются по очереди: файл1, файл2, …, файл7, потом заново файл1, файл2, …, файл7.

Суммарный размер файлов 36 Гб. Объём ОЗУ 8 Гб. Кажется, у системы тут нет возможности закэшировать файлы.

Пока что посчиталось чуть более 360 Гб, пока ошибок нет.

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

Тфу, смешались в кучу лошади и люди (ох уж этот ваш Cpp). Ну все поняли и хорошо.

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

Пока посчиталось чуть больше одного гигабайта, ошибок нет. Процесс продолжается.

[pelewin@pwcomp ~]$ cat /sys/class/block/sdb/device/model
WDC WD5000AAKS-0

[pelewin@pwcomp ~]$ grep 'HDD_DATA' /etc/fstab
UUID=8B53EDAC49EEBD04   /run/media/pelewin/HDD_DATA      ntfs-3g defaults                   0 0

[pelewin@pwcomp ~]$ ntfs-3g --version
ntfs-3g 2017.3.23 external FUSE 29

[pelewin@pwcomp ~]$ fusermount --version
fusermount version: 2.9.9
PeleWin
()
Ответ на: комментарий от EXL

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

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

результаты тестирования:

первый файл

dd if=/dev/urandom of=10g bs=1024K count=10240 # 10GiB
for i in {1..240}; do md5sum 10g; done

все 240 хеш-сумм одинаковы

второй

dd if=/dev/urandom of=40g bs=1024K count=40960 # 40GiB
for i in {1..60}; do md5sum 40g; done

из этих 60 хеш-сумм три отличаются от остальных (№№ 23, 48, 56)

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

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

Попробуй найти плохую планку памяти проводя эксперимент без неё (хотя это так себе способ и можно забраковать хорошую планку вместо плохой).

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

а можете показать ваш

$ sudo ntfsinfo -m /dev/sdXN
? (X и N поменять на свои)

Вдруг там что-то необычное.

Вон на Launchpad Ubuntu пишут про проблему с большими секторами (правда там он даже не монтируется).

Я уж и в Debian10 перезагрузился, там и hdd, и ssd проверил разделы с ntfs - нет никаких ошибок.

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

2.5 Гб посчиталось, по 67 раз каждый из семи файлов. Ошибок нет, думаю, можно останавливать процесс.
Попробую создать и потестировать на 40-гигабайтовом файле.

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

Поменяй память и HDD.

поменяю, но только на водку!

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

а можете показать ваш

$ cat /sys/class/block/sda/device/model
ST4000DM004-2CV1

$ grep 'NTFS' /etc/fstab
/dev/disk/by-uuid/2672FD0772FCDC8D /NTFS1200 auto nosuid,nodev,nofail,x-gvfs-show,noexec 0 2

$ mount | grep 'NTFS'
/dev/sda1 on /NTFS1200 type fuseblk (rw,nosuid,nodev,noexec,relatime,user_id=0,group_id=0,allow_other,blksize=4096)

$ ntfs-3g --version
ntfs-3g 2016.2.22AR.1 integrated FUSE 28

$ fusermount --version
fusermount version: 2.9.7

$ sudo umount /dev/sda1
$ sudo ntfsinfo -m /dev/sda1
Volume Information
	Name of device: /dev/sda1
	Device state: 11
	Volume Name: NTFS_1200G
	Volume State: 91
	Volume Flags: 0x0080
	Volume Version: 3.1
	Sector Size: 512
	Cluster Size: 4096
	Index Block Size: 4096
	Volume Size in Clusters: 308281343
MFT Information
	MFT Record Size: 1024
	MFT Zone Multiplier: 0
	MFT Data Position: 24
	MFT Zone Start: 786432
	MFT Zone End: 39321599
	MFT Zone Position: 786432
	Current Position in First Data Zone: 39321599
	Current Position in Second Data Zone: 0
	Allocated clusters 66496 (0.0%)
	LCN of Data Attribute for FILE_MFT: 786432
	FILE_MFTMirr Size: 4
	LCN of Data Attribute for File_MFTMirr: 2
	Size of Attribute Definition Table: 2560
	Number of Attached Extent Inodes: 0
FILE_Bitmap Information
	FILE_Bitmap MFT Record Number: 6
	State of FILE_Bitmap Inode: 80
	Length of Attribute List: 0
	Number of Attached Extent Inodes: 0
FILE_Bitmap Data Attribute Information
	Decompressed Runlist: not done yet
	Base Inode: 6
	Attribute Types: not done yet
	Attribute Name Length: 0
	Attribute State: 3
	Attribute Allocated Size: 38535168
	Attribute Data Size: 38535168
	Attribute Initialized Size: 38535168
	Attribute Compressed Size: 0
	Compression Block Size: 0
	Compression Block Size Bits: 0
	Compression Block Clusters: 0
	Free Clusters: 27765977 (9.0%)
Egor_
() автор топика
Ответ на: комментарий от EXL

я тут подумал, а вдруг это случайность, что на 10Гб файле не было ошибок?
а вдруг ошибка появится, если сделать не 240 чтений, а больше?
сделал ещё 930 чтений. по-прежнему 0 ошибок

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

Я думаю что про ЕСС память ты всё правильно сказал. Объемы, когда это действительно объемы, уже приближаются к числам, при которых возникают ошибки.

То, что пациент использует разные ОС…

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

Всё, сдаюсь. Пардон.

Загрузился с LiveCD Debian 9.12, всё что можно такое же как у вас и в версиях ПО, и в параметрах NTFS.

Не получается воспроизвести ошибки.

Всё-таки это что-то аппаратное на вашей стороне.

Может стоит вам напилить не 10+40, а 10+10+10+10+10 и проверить все десятки? Ну... так... фантазировать, так фантазировать )

Ссылку почти по теме на Хабр тут оставлю в режиме записной книжки. Даже если там не ваш случай, зато там в комментариях интересная история про IBM-Sun.

Toxo2 ★★★★
()

Вспомнил старую тему

Сканер изменений в содержимом файлов, атрибуты которых не менялись.

Плюс

Выбор Ext4 или xfs под базу данных. Посоветуйте (комментарий)

Вот с чем регулярно сталкиваюсь и на ext4, и на xfs — это редкие повреждения данных в файлах на больших объёмах. Что-то порядка нескольких сбоев (3-6) на 2Тб данных за месяц-два. Хорошо видно на раздачах торрентов — они ловят такое.

.
.
.

Но если под виндой нет ошибок, то вышепроцитированное и не при чём, получается.

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

Если сделать предположение, что драйвер ntfs при загрузке каждый раз оказывается в области сбойной памяти… Надо попробовать сделать так, что бы он загрузился в другой участок памяти. Передать ядру при загрузке memmap=#M$###M option?

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

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

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

Это линукс, никто тебе ничем не обязан. Напиши свой драйвер NTFS или кушай, что дают, не подавись.

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

вотжежбляхамуха
ставлю только первую половину димов - нет ошибок
ставлю только вторую половину димов - дохрена ошибок (10 из 60)

получается, что я исполнил роль мальчика, который кричал «волки»
а вы все, кто «накаркал» мне битую память - вы оказались правы…

мораль сей басни: memtest - полная херня
мораль №2: память ballistix не брать

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

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

наверное, ты прав

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

Значит ли это, что виндовый драйвер в родном окружении (на винде) проверяет чексуммы секторов или что-то в этом роде? В случае несовпадения перечитывает заново. Аналогично и родной ext4 драйвер линя. Потому что, если проблема в памяти, то ошибки были бы везде. Я точно знаю, что ntfs-3g не использует журнал. Может быть дело в контрольных суммах ATA команд.

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