Видимо AMD такая AMD: https://www.phoronix.com/forums/forum/hardware/processors-memory/1097646-next...

Да, от железа зависит, это факт. У некоторых десятки ошибок в день по ОЗУ бывает.

Бред! Это нерабочий комп если так. У меня телефон на android аптайм по пол года держит, один раз хотел аптайм до года довести, забыл зарядить на 250 день. Ошибка в памяти это например значит в селекте из базы индекс не сработает и пропадет запись, ты такое видел хоть раз в своей жизни? А если вспомнить что адресация со смешением не туда вывозит Segmentation fault?

500 гиг ненужно гонять по сети, TCP/IP не надежен с точки зрения целостности данных, там в заголовке есть 16 битное значения для чексуммы, а это значит что если случайным образом мутировать каждый пакет (наводкой с проводки), то с шансом 1 к 65535 пакет может быть побитым без обнаружения, а теперь подели это значение на количество пакетов для передачи одного файла. Работал админом у провайдера, там я файлы передавал по 10 мегабитному Ethernet, физически работающему по коаксиальному кабелю, шансы передать не побив 100 метров были не высоки и тогда я открыл для себя md5sum. Все высокоурожайные протоколы используют

Так что можешь 500 гиг не гонять по сети, а использовать например sha256sum, он считает файал с диска в оперативку (кусками в буфер) и если оперативка работает с ошибками получаемая сумма будет всегда разной.

Может тогда правильнее отключить swap и просто поместить файл на tmpfs?

Хехе. Проведи простой эксперимент. Возьми попереливай пару раз туда-сюда терабайт торрентов и потом проведи перехеширование. Ох, был у меня день с открытием… Кароч, данные бьются постоянно и непрерывно.

А если при этом писать или читать с другого диска то ощибок будет ещё больше.
В общем данные бьются в sata контролёре южного моста и если сначала файл с торрента скачать на tmpfs и только потом с tmpfs копировать на диск то ошибок не будет. Тоже и при копировании с одного диска на другой, если копировать не на прямую, а через копирование на tmpfs то ошибок опять не будет.

Да, это знакомо. Скорее всего ваш торрент клиент говно.

Тоже вариант, т.к. буфер то будет маленький фрагмент аллоцировать в оперативки для нужд подсчета суммы, один раз при запуске программы будет выполнено что-то типа void *buffer = malloc(1024), но смысла конечно заморачиваться с tempfs в реальности нету, лучше уж memtest, который специально под это дело создавался. Просто если память настолько битая, все эти контрольные суммы периодически чудили. А я такого не помню, помню когда выкладывали файлы у которых чексумма не сходилась с декларируемой, но это было вполне воспроизводимо из раза в раз.

Тоже вариант. Но почему тогда на фильмах иногда появляются глюки?

Но почему тогда на фильмах иногда появляются глюки?

Проверка работоспособности ECC памяти (комментарий)

Если кому интересно, ECC в этой связке работает. Но EDAC в ядре пока не готов и мониторинга ошибок нет.

Просто у тебя чипсет очень сильно устарел - ужп даже PCI-E 4.0 не тянет... Обнови матплату и сразу все заработает лучше прежнего!

Вот ответ на предмет обсуждения.

sudo dmidecode -t 17 | grep -i width

А «не лохи» даже не заметили этого, продолжили дальше выяснять, кто из них лох и меряться пиписьками в вопросах, ответы на которые они не знают точно. Уже и про частоты поговорили, и про напряжения, и про «оверклоцкерскую» память с лохами и даже вообще перешли на PCI-E 4, т.е. всем насрать на сабж.

З.Ы.: на всякий случай, команда выше показывает ширину слова (или как там правильно не знаю), т.е. для обычной non-ecc памяти 64 бита (8х8), для ecc - 72 бита (8х9).

А вот тут вообще весело:

Total Width: 128 bits
Data Width: 64 bits