LINUX.ORG.RU
ФорумTalks

ecc vs non ecc

 , ,


1

2

https://stackoverflow.com/questions/23587591/software-memory-bit-flip-detection-for-platforms-without-ecc

Most available desktop (cheap) x86 platforms now still nave no ECC memory support (Error Checking & Correction). But the rate of memory bit-flip errors is still growing (not the best SO thread, Large scale CERN 2007 study "Data integrity": "Bit Error Rate of 10-12 for their memory modules ... observed error rate is 4 orders of magnitude lower than expected"; 2009 Google's "DRAM Errors in the Wild: A Large-Scale Field Study"). For current hardware with data-intensive load (8 GB/s of reading) this means that single bit flip may occur every minute (10-12 vendors BER from CERN07) or once in two days (10-16 BER from CERN07). Google09 says that there can be up to 25000-75000 one-bit FIT per Mbit (failures in time per billion hours), which is equal to 1 - 5 bit errors per hour for 8GB of RAM ("mean correctable error rates of 2000–6000 per GB per year").

So, I want to know, is it possible to add some kind of software error detection in system-wide manner (check both user and kernel memory). For example, create a patch for Linux kernel and/or to system compiler to add some checksumming of every memory page, and try to detect silent memory corruptions (bit-flips) by regular recomputing of checksums?

For example, can we see all writes to memory (both from user and kernel space), to distinguish between intended memory changes from in-memory bit flips? Or can we somehow instrument all codes with some helper?

I understand that any kind of software memory ECC may cost a lot of performance and will not catch all errors, but I think it can be useful to detect at least some memory bit-flips early, before they will be reused in later computations or stored to hard drive.

I also understand that better way of data protection from memory bitflips is to switch to ECC hardware, but most PC there are still non-ECC.

Я подозреваю, что любая ошибка в памяти - это практически 100% сегфолт какой-то аплекухи. Если сегфолтов нет - значит и ошибок нет. Я подозреваю, что bit flips - сильно преувеличенная проблема. Вообще, если есть ошибка, значит должен быть тест, с помощью которого можно эту ошибку выявить. Где взять тест? Может bit flips появляется раз в три года. Может быть bit flips появляется при 100% загрузке ram и тогда она тупо перегревается и начинает сбоить? Тогда ее можно охлаждать, чтобы этого избежать

★★★

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

Я подозреваю, что любая ошибка в памяти - это практически 100% сегфолт какой-то аплекухи.

С чего бы? Большая часть памяти – куча с данными. Если данные поехали, то ты этого не заметишь.

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

Есть. ECC память называется.

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

Если данные поехали, то ты этого не заметишь

Ага, тогда вообще можно /dev/urandom в ram писать и всё будет тип-топ, ты даже не заметишь, лол

Есть. ECC память называется

в твоих мечтах. На самом деле надо озу примонтировать и писать туда файл, равный размеру озу, перед этим проверить md5. Потом из оттуда читать и сверить опять md5. Я вангую, что за сутки не будет не одного сбоя в нонстоп режиме и вся инфа про 1-5 ошибок в час - это джинса, чтобы доверчивые товарищи покупали ECC память

PS: кто напишет баш скрипт для теста? И мы все вместе проверим, насколько эта инфа соответствует действительности

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

С чего бы? Большая часть памяти – куча с данными. Если данные поехали, то ты этого не заметишь.

Ну я бы так не сказал. Открой бинарник, поменяй в нем любой символ и попробуй запустить. В лучшем случае где-то будет сбой который ты можешь увидеть через сутки. А в худшем просто не запустится.

Даже если пользовательские данные (за данные программы, описания переменных, их типы, имена и тд я вообще молчу) видоизменятся так что в int прилетит char вместо int'a - последствия будут фатальными.

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

А что будет обеспечивать консистентность md5?

Кстати да. Хороший вопрос. Если память битая, то участок кода отвечающий за проверку консистетности md5 - тоже может оказаться битым, и не проходить проверку даже если хеш правильный.

Наверное для этого нужен отдельный SoC со своей заведомо рабочей ОЗУ.

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

а этого мало? При изменении хоть одного бита хэш уже будет отличаться

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

А зачем её обеспечивать? Если что-то повредилось, то в 99.999... % случаев проверка целостности не пройдёт, по тем или иным причинам, повредились ли данные, сам хэш или модуль проверки. Чтобы она успешно прошла в случае некорректных данных, нужно повредить именно тот бит, который отвечает за возврат true/false. Шансы на это настолько низкие, что можно пренебречь в замерах статистики.

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

Где взять тест? Может bit flips появляется раз в три года. Может быть bit flips появляется при 100% загрузке ram и тогда она тупо перегревается и начинает сбоить?

Поставить ECC память и мониторить лог. В случае выявления и корректировки ошибки это событие пишется в лог.

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

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

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

На самом деле надо озу примонтировать и писать туда файл, равный размеру озу, перед этим проверить md5.

Ну ты memtest изобрёл :D

Ток зачем тебе файл? Зачем вообще что-то в память писать? Запускаешься в DOS, делаешь md5 памяти с разницей в сутки и всё.

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

Ну ты memtest изобрёл :D

если memtest так и работает, тогда я под столом от смеха т.к мемтест обычно на сутки запускают и по результату должно быть ноль ошибок, что доказывает, что всё это «за час от 1 до 5 ошибок» полная лажа

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

Если мемтест так и работает, тогда вообще ничего на баше писать не надо. Уже и так всё предельно ясно

serg002 ★★★
() автор топика

Я подозреваю, что любая ошибка в памяти - это практически 100% сегфолт какой-то аплекухи. Если сегфолтов нет - значит и ошибок нет.

А вот фейсбук с гуглом в этом сомневаются

https://research.facebook.com/publications/revisiting-memory-errors-in-large-scale-production-data-centers-analysis-and-modeling-of-new-trends-from-the-field/

https://scontent.fkiv1-1.fna.fbcdn.net/v/t39.8562-6/240831230_531879224586720_8134760914647720916_n.pdf?_nc_cat=108&ccb=1-7&_nc_sid=ad8a9d&_nc_ohc=HoZWzoOFp8cAX8VvQZW&_nc_ht=scontent.fkiv1-1.fna&oh=00_AT_inzbniBOFZh-8Ii1ge9ayzHC5NYXXcZvt9O7no0oPww&oe=635596E6

http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf

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

если memtest так и работает, тогда я под столом от смеха т.к мемтест обычно на сутки запускают и по результату должно быть ноль ошибок, что доказывает, что всё это «за час от 1 до 5 ошибок» полная лажа

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

hateyoufeel ★★★★★
()

это практически 100% сегфолт какой-то аплекухи

зависит как в аппликухе обрабатываются исключения

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

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

в твоих мечтах. На самом деле надо озу примонтировать и писать туда файл, равный размеру озу, перед этим проверить md5. Потом из оттуда читать и сверить опять md5. Я вангую, что за сутки не будет не одного сбоя в нонстоп режиме и вся инфа про 1-5 ошибок в час - это джинса, чтобы доверчивые товарищи покупали ECC память

Правильно протестировать память не так просто как кажется. Ошибка может возникать не всегда и не на любых данных. Например, если писать все 11111111 или 00000000 ее может не возникнуть, а только если чередовать 1010101 или наоборот, то есть, от паттернов зависеть. От количества одновременно записываемой памяти, режима адресации и много чего еще. Ошибка может быть не в планках памяти, а в кэше процессора и наоборот, если писать и тут же считывать, кэш процессора при некоторых условиях может замаскировать сбой в планке.

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

так что в int прилетит char вместо int'a - последствия будут фатальными.

А если вместо Вася, прилетит Уася или Вася- или ещё что такое раз в сутки в рандомной софтине из 50 запущенных в системе, ну не заметишь почти 100%. Или в логе не тот символ 1 из гигабайта будет , разве заметишь? Да даже в цифре, если это не баланс на карте, то тоже не факт что заметишь. А если 1 бит в текстуре, так там и килобайт не факт что заметишь за один кадр пока она на валидную не обновится.

Loki13 ★★★★★
()

Я помню что во времена 286-х процов часто пользовался тестированием только что созданного архива (размером порядка мегабайта или может даже меньше) и регулярно в них находились ошибки - надо было архивировать заново. За последние 10 лет (на многогигабайтных объёмах уже) ни разу подобного не встречал.

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

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

Ага, озушка дырявое корыто. Это прям мечта производителей памяти с ECC. Но на самом деле всё не так, как ты описал. И проверить это можно только на практике. Я гарантию даю, что если писать в рам и чекать по мд5, то за сутки не будет не одной ошибки

serg002 ★★★
() автор топика

ECC это защита памяти от внешнего воздействия эл. магнитного излучения, магнитного/электрического полей, физического, вибрация тряска (микромомент плохого контакта). ЕЦЦ нужен там где это может проявится очень легко, серверные с кучей железа как в консервной банке, на северном и южных полюсах включая экватор и космическое пространство, в мобильных рабочих станциях и любых движущихся штуках со встроенным ЭВМ при условии что память не распаяна, а в слотах. То есть там где битик памяти может быть случайно по очевидным причинам получить не то значение или не совсем то.

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

Ну и ещё ецц может сказать что мол хозяин этой памяти кабзда есть куча ошибок и они нифига не фиксятся, меняй планочку-тяночку лол.

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

Но если ты собрался со своим ноутом в стратосферу на воздушном шарике то поставь с ЕЦЦ и попутно обклей ноутпук алюминиевой фольгой на которую подай напряжение что-бы частицы космические врезающиеся под углом 90 градусов испытывали поперечное ускорение от проходящего по фольге тока и тем самым снижали свою скорость и не передав свой заряд затвору транзистора планки памяти прошив его насквозь. Я могу ещё бреда выдумать =).

любая ошибка в памяти - это практически 100% сегфолт

Если задета область кода то да неизбежно что-то пойдёт не так, если ошибка в данных то ничё не заметишь, разве что \0 строки превратится во что иное или ещё чего подобное. Будет ошибка в области памяти где «лежит» картинка то просто у этого файлика будут хеш суммы не совпадать того что на ХДД и тому что в РАМ

LINUX-ORG-RU ★★★★★
()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 1)
Ответ на: комментарий от serg002

Ну проверь. Выключи свап, создай tmpfs, в него запиши что-нить и проверь через месяц. Хотя я бы вместо md5 использовал сидированный рандом-генератор. Даже сделал такую прогу когда-то, правда для жёстких дисков, но с файлом в tmpfs она так же сможет работать.

/* (c) firk 2012-2022 */
#define _FILE_OFFSET_BITS 64
#include <sys/time.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <time.h>
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

typedef unsigned char uchar;
typedef unsigned int uint32;
typedef unsigned long long uint64;

/*************************************************************************************************/
/*************************************************************************************************/
static void r4(uint32 * d0, uint32 * d1, uint32 * d2, uint32 * d3) {
  uint32 a, b, c, d;
  a=*d0;b=*d1;c=*d2;d=*d3;
  a+=b;d^=a;d=(d<<16)|(d>>16);
  c+=d;b^=c;b=(b<<12)|(b>>20);
  a+=b;d^=a;d=(d<<8)|(d>>24);
  c+=d;b^=c;b=(b<<7)|(b>>25);
  *d0=a;*d1=b;*d2=c;*d3=d;
}
static void r16(uint32 * d) {
  r4(d+0,d+4,d+8,d+12);
  r4(d+1,d+5,d+9,d+13);
  r4(d+2,d+6,d+10,d+14);
  r4(d+3,d+7,d+11,d+15);
  r4(d+0,d+5,d+10,d+15);
  r4(d+1,d+6,d+11,d+12);
  r4(d+2,d+7,d+8,d+13);
  r4(d+3,d+4,d+9,d+14);
}
static void genrandom512(uint32 * res, uint32 * key, uint32 * nonce, uint32 * seq) {
  uint32 tmp[16], i;
  tmp[0] = 0x61707865;
  tmp[1] = 0x3320646E;
  tmp[2] = 0x79622D32;
  tmp[3] = 0x6B206574;
  tmp[4] = key[0];
  tmp[5] = key[1];
  tmp[6] = key[2];
  tmp[7] = key[3];
  tmp[8] = key[4];
  tmp[9] = key[5];
  tmp[10] = key[6];
  tmp[11] = key[7];
  tmp[14] = nonce[0];
  tmp[15] = nonce[1];
  tmp[12] = seq[0];
  tmp[13] = seq[1];
  for(i=0;i<16;i++) res[i]=tmp[i];
  for(i=0;i<10;i++) r16(tmp);
  for(i=0;i<16;i++) res[i]+=tmp[i];
}
static void genrandom1M(uchar * res, uint32 * key, uint64 seq, uint32 blocksize) {
  unsigned i;
  uint32 s[2];
  if(blocksize==1048576) {
    s[0] = (uint32)(seq << 14);
    s[1] = (uint32)(seq >> 18);
    for(i=0; i<16384; i++,s[0]++) genrandom512((uint32*)(res+i*64), key, key+8, s);
  } else if(blocksize==65536) {
    s[0] = (uint32)(seq << 10);
    s[1] = (uint32)(seq >> 22);
    for(i=0; i<1024; i++,s[0]++) genrandom512((uint32*)(res+i*64), key, key+8, s);
  } else if(blocksize==4096) {
    s[0] = (uint32)(seq << 6);
    s[1] = (uint32)(seq >> 26);
    for(i=0; i<64; i++,s[0]++) genrandom512((uint32*)(res+i*64), key, key+8, s);
  } else if(blocksize==512) {
    s[0] = (uint32)(seq << 3);
    s[1] = (uint32)(seq >> 29);
    for(i=0; i<8; i++,s[0]++) genrandom512((uint32*)(res+i*64), key, key+8, s);
  }
}
static void str2key(uint32 * r, uchar const * src) {
  unsigned i;
  uchar c;
  for(i=0; i<10; i++) {
    if(c = *src) src++;
    r[i] = (i*2038074133) ^ c;
  }
  i = 0;
  while(c=*(src++)) { r[i] = (r[i] * 1294471) ^ c; i = (i+1)%10; }
}

/*************************************************************************************************/
/*************************************************************************************************/
static unsigned long get_ticks(void) {
  static time_t begintime = 0;
#ifndef OLD_TIME
  struct timespec ts;
  if(!clock_gettime(CLOCK_MONOTONIC, &ts)) {
    if(!begintime) begintime = ts.tv_sec;
    return ((unsigned long)(ts.tv_sec-begintime))*1000 + (unsigned long)(ts.tv_nsec/1000000);
  }
#endif
  {
    struct timeval tv;
    gettimeofday(&tv, NULL);
    if(!begintime) begintime = tv.tv_sec;
    return ((unsigned long)(tv.tv_sec-begintime))*1000 + (unsigned long)(tv.tv_usec/1000);
  }
}

/*************************************************************************************************/
/*************************************************************************************************/
static int mode;
static uint32 key[10];
static int device_fd;

static int process_block(uint64 seq, uint32 bs, unsigned loglatency) {
  static uchar buf[1048576];
  static uchar wbuf[1048576];
  long n;
  unsigned long t1, t2, t3;

  if(mode & 2) genrandom1M(wbuf, key, seq, bs);

  t1 = get_ticks();
  if(lseek(device_fd, seq*bs, SEEK_SET)<0) { printf("lseek(blk=%llu) error %d (%s)\n", seq, errno, strerror(errno)); return -1; }
  t2 = get_ticks();
  if(!(mode & 1)) {
    n = read(device_fd, buf, bs);
    if(n<0) { printf("read(blk=%llu) error %d (%s)\n", seq, errno, strerror(errno)); return -1; }
  } else {
    n = write(device_fd, wbuf, bs);
    if(n<0) { printf("write(blk=%llu) error %d (%s)\n", seq, errno, strerror(errno)); return -1; }
  }
  t3 = get_ticks();

  if(n!=(long)bs) {
    uint64 totbytes;
    totbytes = seq*bs+n;
    printf("%s(blk=%llu) processed only %ld bytes of %ld\n", (mode & 1)?"write":"read", seq, n, (long)bs);
    printf("it seems that total size of hdd is %llu bytes\n", totbytes);
  }

  if(t3-t1 > loglatency) printf("block %llu has latency %lu (%lu+%lu)\n", seq, t3-t1, t2-t1, t3-t2);
  
  if(mode==2 && n && memcmp(buf, wbuf, n)) {
    printf("block %llu mismatched!\n", seq);
    return -1;
  }

  if(n!=(long)bs) return 0;
  return 1;
}

int main(int argc, char ** argv) {
  int r;
  char const * device;
  int blocksize;
  long long startblock;
  long long currblock;
  int loglatency;
  if(argc!=6) {
usage:  printf("Usage: hddwscan <mode> <device> <blocksize> <starting block> <loglatency>\n"
               "  <mode> is read|write:key|verify:key\n"
               "  <blocksize> only 1048576 supported\n"
               "  <loglatency> is minimum latency to log\n");
        return 0;
  }
  if(!strcmp(argv[1],"read")) mode = 0;
  else if(!strcmp(argv[1],"write")) mode = 1;
  else if(!strncmp(argv[1],"verify:",7)) { mode = 2; str2key(key,(uchar*)argv[1]+7); }
  else if(!strncmp(argv[1],"write:",6)) { mode = 3; str2key(key,(uchar*)argv[1]+6); }
  else goto usage;
  device = argv[2];
  blocksize = atoi(argv[3]);
  startblock = atoll(argv[4]);
  loglatency = atoi(argv[5]);
  if(blocksize!=512 && blocksize!=4096 && blocksize!=65536 && blocksize!=1048576) {
    printf("Valid block size is 512, 4096, 65536, 1048576\n");
    return 0;
  }
  if(startblock<0) startblock = 0;
  if(loglatency<0) loglatency = 0;
  if(mode & 2) printf("using key %08X %08X %08X %08X %08X %08X %08X %08X %08X %08X\n", key[0], key[1], key[2], key[3], key[4], key[5], key[6], key[7], key[8], key[9]);
  printf("Starting \"%s\" for %s, blocksize %d, starting block %lld, logging when latency >%d ms\nWaiting 10 seconds...\n", argv[1], device, blocksize, startblock, loglatency);
  sleep(10);

  currblock = startblock;
  device_fd = open(device, (mode & 1)?O_RDWR:O_RDONLY);
  if(device_fd<0) { printf("open(%s) error %d (%s)\n", device, errno, strerror(errno)); return 0; }

  while(1) {

    if(!(currblock%10)) {
      if(mode==0) printf("Reading %s block %lld\r", device, currblock);
      else if(mode==1) printf("Zero-writing %s block %lld\r", device, currblock);
      else if(mode==2) printf("Verifying %s block %lld\r", device, currblock);
      else if(mode==3) printf("Writing %s block %lld\r", device, currblock);
      fflush(stdout);
    }

    r = process_block(currblock, blocksize, loglatency);
    if(r<=0) { close(device_fd); return r; }
    currblock++;
  }
}

В начале

./hddwscan write:h45wh543h34 /path/to/tmpfs/file 1048576 0 1000
оно будет писать пока место не закончится или пока ctrl-c не нажмёшь

проверка

./hddwscan verify:h45wh543h34 /path/to/tmpfs/file 1048576 0 1000

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

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

Может банально дискеты/FDD сбоили? Я сбои ОЗУ для себя открыл минимум во времена k6-2 и игрищ с разгоном на формозовских материнках.

yu-boot ★★★★
()
Ответ на: комментарий от serg002

Ага, озушка дырявое корыто. Это прям мечта производителей памяти с ECC. Но на самом деле всё не так, как ты описал. И проверить это можно только на практике. Я гарантию даю, что если писать в рам и чекать по мд5, то за сутки не будет не одной ошибки

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

vaddd ★☆
()
Ответ на: комментарий от yu-boot

Почему сразу дискеты, там жёсткие диски уже давно были. Ну вобщем может это и не память была, да, а ошибки на линиях данных при записи на носители информации.

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

Когда мы лепили всякие промконтроллеры на первых 86-286 - тоже частенько сталкивались с большим количеством ошибок, но это явно были ошибки работы с периферией, а не сбои памяти. Если редко писать-читать, то в памяти данные могли крутиться без сбоев долго

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

какая связь между кучей с данными и запускаемым бинарником?

А бинарник по-твоему как запускается ?

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

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

А сегфолты в любом случае маловероятны, данных в памяти намного больше чем кода.

А если указатель в структурке попортится?

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

А если вместо Вася, прилетит Уася или Вася

Смотря что на этого «Васю» подвязано.

Кроме того, программой является не только ридер книжек со сказкой про Васю. Ею еще является драйвер файловой системы.

Если тебе в таблицу ФС прилетит Уася вместо Васи, то в лучшем случае Вася свой файл найдет в хомяке у Уаси, а в худшем случае учитывая сложность, буферизацию и кэширование современных ФС, одна буква вызовет целый каскад фатальных изменений.

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

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

Я наверное тебя разочарую, но «данные» - это понятие растяжимое. С чего ты взял что мы говорим о просмотрщике картинок и фотке котиков ? Может речь идет о драйвере nvme, который так же является программой размещаемой в памяти, и «данные» для него - это твои файлы ?

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

то в лучшем случае Вася свой файл найдет в хомяке у Уаси, а в худшем случае учитывая сложность, буферизацию и кэширование современных ФС, одна буква вызовет целый каскад фатальных изменений.

У меня есть скачанные фильмы с торрентов, в количестве 200-500Гб, лежат они годами на ФС и я иногда чекаю ФС с помощью fsck. После чего проверяю торрент. Так вот поврежденных данных бывает до 5-10% за пару лет. Они соответственно перекачиваются. Но если я захочу посмотреть фильм с 5% повреждений, он вполне себе нормально отработает с парочкой фризов и пятком артефактов.

ЗЫЖ Я год жил со сбоящей памятью, так вот, проблемы были только при компиляции чего-то большого, бывали сегфолты компилятора, но часто помогало всего лишь запустить компиляцию повторно и всё получалось. А если у меня сефолтнется какая плазма или балу раз в неделю, я перезапущу и даже не обращу на это внимания.

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

А если у меня сефолтнется какая плазма

А если не плазма, а расписание самолетов ?

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

Что-то overдохрена

Так он же сказал что год жил со сбоящей памятью. Результат налицо. Какой-нибудь драйвер ext4 считал файл в память (который в данном случае и является данными этой программы) для буферизации, кеширования, индексирования или еще хрен пойми чего, оно там в памяти поменялось, после чего сflush'илось на носитель уже в видоизмененном виде.

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

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

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

Мы говорим о том, что большинство байтов в памяти на большинстве компов - это именно данные в самом бытовом понимании - всякие тексты, картинки, аудио и видео. Какая конкретно программа их обрабатывает в данный момент, драйвер ли диска или браузер - не важно, сбой бита в картинке приведёт максимум к «ой что-то картинка не загрузилась, нажму ctrl-F5».

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

Я помню что во времена 286-х процов часто пользовался тестированием только что созданного архива (размером порядка мегабайта или может даже меньше) и регулярно в них находились ошибки - надо было архивировать заново. За последние 10 лет (на многогигабайтных объёмах уже) ни разу подобного не встречал.

Я это еще даже в эпоху P-II и даже P-III и первых Атлонов встречал. Даже в компьютерных журналах были советы. Не факт кстати, что дело в RAM было, а не глюках чипсета и кабелей IDE. Как-то субъективно с переходом на SATA все надежнее стало.

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

Бинарник запускается и, внезапно, создает кучу из объектов, которыми оперирует в рантайме. Но этой кучи в самом бинарнике нет. И «изменение кучи» никак не коррелирует с изменением незапущенного бинарника. А азы подучи, они тебе помогут не выставлять себя идиотом.

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

Какая конкретно программа их обрабатывает в данный момент, драйвер ли диска или браузер - не важно, сбой бита в картинке приведёт максимум к «ой что-то картинка не загрузилась, нажму ctrl-F5».

Да о чем говорить, игроки любят разгонять посильнее, выжимая FPS из компа. Причем нормальных тестов такие компы уже не проходят. Но им нормально. Гамы гамятся, fps мутится =)

Игроделы кстати как-то учитывают и стараются лишнего не нагружать что ли. Потому что Cyberpunk 2077 поначалу у некоторых падал как раз похоже из-за глючного железа.

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

Секция .code копируется в память и выполняется оттуда. Изменение одного байта в этой области практически 100% краш. Иди ты подучи азы

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

А как насчет сценария изменения байта в куче через месяц после запуска, м? Когда там не только те объекты, которые создались при старте, но и что-то еще?

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

Почему частный? Когда это ECC позиционировалось как решение для нищеброд-десктопов? А если у нас сервер - у нас релизный цикл, и ПО работает месяцами.

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

Возможно это потому, что я люблю частенько(2-3 раза в месяц) вырубить комп 5сек нажатием кнопки power. Ну и при fsck у меня каждый раз что-то да исправляется, какие-нибудь inodes.

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

Изменение одного байта в этой области практически 100% краш

Если в твоей программе 100500 менюшек и опций, то сбой одной из них крашнет(не факт) приложение только в случае обращение к этому месту программы. А то что не факт, что крашнет, тоже, т.к. можно вообще все исключения прехватывать, писать в лог и проглатывать. Тогда крашнет программу только что-то сильно критичное, а не в процедуре расчета на какую позицию вывести строку. Ну не выведется строка, может ты и не заметишь, если этот код будет в try\catch обернут.

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

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

Но это сценарий битой памяти, а не ошибок, ECC тут не при чём.

George
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)