wykrywanie i korekcja zgnilizny bitów za pomocą mdadm

17

Mam zamiar ponownie zorganizować wszystkie dyski twarde w moim domowym pudełku linuksowym nas i chciałbym użyć raidu mdadm do ochrony danych i jego elastyczności do przekształcania tablic. Zanim jednak użyję do tego mdadm, chciałbym wiedzieć, jak radzi sobie z zgnilizną bitów . W szczególności rodzaje zgnilizny bitów, które nie powodują nieodwracalnych komunikatów o błędach odczytu wysyłanych z dysku twardego.

Biorąc pod uwagę, że będę prawdopodobnie przy użyciu co najmniej 21TB dysków twardych w 8 dysków w NAS i różnych ofert na prawdopodobieństw o awarii na dyskach, myślę, że w trakcie przebudowy z jednej awarii dysku jestem uzasadnione prawdopodobieństwo spotkania jakaś forma zgnilizny bitów na pozostałych dyskach. Jeśli jest to niemożliwy do naprawienia błąd odczytu na jednym z dysków, że dysk faktycznie zgłasza go jako błąd, uważam, że powinno to być w porządku w przypadku raid6 (prawda?). Jednak jeśli dane odczytane z dysku są złe, ale nie są zgłaszane jako takie przez dysk, nie widzę, jak można to automatycznie poprawić nawet przy pomocy raid6. Czy to coś, o co musimy się martwić? Biorąc pod uwagę artykuł Jest rok 2010 i RAID5 nadal działai moje własne udane doświadczenia w domu i pracy, rzeczy niekoniecznie są tak zgubne i ponure, jak wierzą w to bzyczące słowa i marketing, ale nienawidzę konieczności przywracania kopii zapasowych tylko z powodu awarii dysku twardego.

Biorąc pod uwagę, że wzorce użytkowania będą, pisz co najwyżej kilka razy, a od czasu do czasu czytaj, będę musiał wykonać czyszczenie danych . Widzę na wiki archlinux polecenia mdadm do czyszczenia danych jako tablicy

echo check > /sys/block/md0/md/sync_action

następnie, aby monitorować postęp

cat /proc/mdstat

Wydaje mi się, że odczyta wszystkie sektory wszystkich dysków i sprawdzi, czy dane pasują do parzystości i odwrotnie. Chociaż zauważam, że w dokumentach duży nacisk kładziony jest na stwierdzenie, że istnieją znaczące okoliczności, że operacja „sprawdź” nie będzie w stanie automatycznie poprawić, a jedynie wykryć i pozostawi to użytkownikowi naprawienie.

Jakie poziomy RAID mdadm powinienem wybrać, aby zmaksymalizować ochronę przed gniciem bitów i jakie czynności konserwacyjne i inne kroki ochronne powinienem wykonać? A przed czym to mnie nie ochroni?

Edycja: Nie zamierzam uruchamiać RAID vs ZFS ani żadnej innej technologii QA. Chcę wiedzieć konkretnie o rajdzie mdadm. Dlatego też pytam w systemach Unix i Linux, a nie w SuperUser .

Edycja: czy odpowiedź: mdadm może korygować tylko URE, które są zgłaszane przez systemy dyskowe podczas szorowania danych i wykrywa cichą zgniliznę bitów podczas szorowania, ale nie może / nie naprawi tego?

BeowulfNode42
źródło
Jeśli chodzi o ochronę danych, główną korzyścią, którą widzę w ZFS, jest to, że szoruje lokalizacje dysków plików za każdym razem, gdy czytasz plik. Właśnie dlatego mam teraz konfigurację z ZFS. Ale i tak muszę regularnie wykonywać pełne peelingi. Mam 2 pule ZFS, każda z 3 dyskami, i chcę uaktualnić system do 8 dysków, w którym dowolny dysk może ulec awarii i nadal będzie 1 dodatkowy dysk nadmiarowy, a ZFS nie jest elastyczny, aby umożliwić taką zmianę kształtu. Ponieważ i tak odbudowuję, ponownie odwiedzam mdadm.
BeowulfNode42,
Do tej pory miałeś szczęście z RAID5 / 6. Faktem jest, że jest rok 2013, a RAID nadal cierpi z powodu dziury w zapisie. Jeśli stracisz moc po zapisaniu danych, ale przed zapisaniem parzystości, właśnie zepsułeś swoje dobre dane i możliwe jest, że z niekonsekwencją twoja tablica również wznosi toast. Dzięki RAID5.
bahamat
Chodzi o to, że to, co chcesz zrobić, najlepiej zrobić na warstwie systemu plików. W przeciwnym razie potrzebujesz sposobu na wykrycie i najlepiej skorygowanie bitów, być może w sytuacji zmniejszonej lub zerowej redundancji, a RAID po prostu nie jest do tego odpowiedni. Nie tylko nie ma gwarancji, że i tak nie skończy się zgnilizna bitów (co się stanie, jeśli jeden dysk ulegnie awarii, a inny źle odczyta bit z talerza?), Ale zwykły RAID również nie ma pojęcia, co jest ważne, a co nie tylko hałas. Ponieważ ZFS szoruje tylko dane odniesienia , zgnilizna bitów na nieużywanej części dysku staje się problemem.
CVn
Naprawdę nie można oczekiwać, że nałożenie losowego systemu plików na wiele dysków (nawet z redundancją) nagle ochroni cię przed awarią pamięci. Nie jestem na świętej krucjacie, aby wprowadzić ZFS do mas (chociaż uważam, że jest to świetny wynalazek i sam go używam w Linuksie do praktycznie wszystkiego oprócz partycji root, która jest ext4 na mdraid1 dla kompatybilności oprogramowania), ale Rozumiem również, że Twój jest jednym z problemów, które ZFS zaprojektowano od podstaw w celu rozwiązania: gwarantowanego wykrywania i, jeśli to możliwe, naprawy uszkodzenia danych bez względu na przyczynę.
CVn
Myślę, że powinieneś zmienić swoje wymagania. Czy naprawdę potrzebujesz ochrony Bitrot nawet w przypadku zastosowania korekcji błędów? Czy wiesz, jak mało prawdopodobne jest, aby istniał bitrot PODAJĄC, że został on również poprawiony przez ECC dysku?
jaskiniowiec

Odpowiedzi:

5

Szczerze mówiąc, wydaje mi się dość zaskakujące, że odrzucisz RAIDZ2 ZFS. Wydaje się, że prawie idealnie odpowiada twoim potrzebom, z wyjątkiem faktu, że nie jest to Linux MD. Nie jestem na krucjacie, aby wprowadzić ZFS do mas, ale prosty fakt jest taki, że twój jest jednym z rodzajów problemów, które ZFS został zaprojektowany od podstaw do rozwiązania. Poleganie na macierzy RAID (dowolnej „zwykłej” macierzy RAID) w celu zapewnienia wykrywania i korekcji błędów, być może w sytuacji zmniejszonej lub zerowej redundancji, wydaje się ryzykowne. Nawet w sytuacjach, w których ZFS nie może poprawnie naprawić błędu danych, może przynajmniej wykryć błąd i poinformować, że wystąpił problem, umożliwiając podjęcie działań naprawczych.

Nie musisz wykonywać regularnych pełnych operacji w ZFS, chociaż jest to zalecana praktyka. ZFS sprawdzi, czy dane odczytane z dysku odpowiadają temu, co zostało zapisane podczas odczytu danych, aw przypadku niezgodności albo (a) użyj redundancji, aby zrekonstruować oryginalne dane, lub (b) zgłoś błąd we / wy Aplikacja. Ponadto czyszczenie jest operacją online o niskim priorytecie, zupełnie różną od kontroli systemu plików w większości systemów plików, które mogą mieć zarówno wysoki priorytet, jak i offline. Jeśli używasz szorowania i coś innego niż szorowanie chce wykonywać operacje we / wy, szorowanie zajmie miejsce na tylnym siedzeniu. Scrub ZFS zastępuje zarówno scrub RAID, jak i metadane i dane systemu plików sprawdzanie integralności, jest więc o wiele bardziej dokładne niż tylko szorowanie macierzy RAID w celu wykrycia jakiejkolwiek zgnilizny bitów (co nie mówi, czy dane mają jakiś sens, tylko że zostały poprawnie zapisane przez kontroler RAID).

Nadmiarowość ZFS (RAIDZ, tworzenie kopii lustrzanych, ...) ma tę zaletę, że nieużywane lokalizacje dysków nie muszą być sprawdzane pod kątem spójności podczas przeszukiwania; podczas przeszukiwania sprawdzane są tylko rzeczywiste dane, ponieważ narzędzia przechodzą przez łańcuch bloków alokacji. Jest to to samo, co w przypadku niepotrzebnej puli. W przypadku „zwykłego” RAID należy sprawdzić wszystkie dane (w tym wszelkie nieużywane lokalizacje na dysku), ponieważ kontroler RAID (sprzętowy lub programowy) nie ma pojęcia, które dane są rzeczywiście istotne.

Korzystając z RAIDZ2 vdevs, dowolne dwa dyski składowe mogą ulec awarii, zanim istnieje ryzyko faktycznej utraty danych z powodu awarii innego dysku, ponieważ nadmiarowość dwóch dysków jest niemożliwa. Jest to zasadniczo to samo, co RAID6.

W ZFS wszystkie dane, zarówno dane użytkownika, jak i metadane, są sumowane (z wyjątkiem sytuacji, gdy nie zdecydujesz się tego zrobić, ale jest to zalecane przeciw), a te sumy kontrolne służą do potwierdzenia, że ​​dane nie uległy zmianie z jakiegokolwiek powodu. Ponownie, jeśli suma kontrolna nie zgadza się z oczekiwaną wartością, dane albo zostaną zrekonstruowane w sposób przezroczysty, albo zgłoszony zostanie błąd we / wy. Jeśli zostanie zgłoszony błąd we / wy lub scrub identyfikuje plik z uszkodzeniem, będziesz wiedział, że dane w tym pliku są potencjalnie uszkodzone i możesz przywrócić ten konkretny plik z kopii zapasowej; nie ma potrzeby pełnego przywracania tablicy.

Zwykła, nawet podwójna parzystość, macierz RAID nie chroni przed sytuacjami, takimi jak na przykład awaria jednego napędu, a jeszcze inne niepoprawnie odczytują dane z dysku. Przypuśćmy, że jeden z dysków uległ awarii, a gdziekolwiek z innych dysków jest jeden bit: nagle masz niewykrywalne uszkodzenie i jeśli nie będziesz zadowolony z tego, będziesz musiał przynajmniej go wykryć. Aby zminimalizować to ryzyko, należy zsumować sumę kontrolną każdego bloku na dysku i upewnić się, że suma kontrolna nie może zostać uszkodzona wraz z danymi (ochrona przed błędami, takimi jak zapisy w locie, zapisy sieroce, zapisy w niewłaściwych lokalizacjach na dysku itp.), Które jest dokładnie tym, co robi ZFS, o ile włączone jest sumowanie kontrolne.

Jedynym prawdziwym minusem jest to, że nie można łatwo rozwinąć RAIDZ vdev poprzez dodanie do niego urządzeń. Istnieją obejścia tego problemu, które zwykle obejmują takie rzeczy jak rzadkie pliki jako urządzenia w vdev, i bardzo często określane jako „nie zrobiłbym tego, gdyby były to moje dane”. Dlatego jeśli wybierzesz trasę RAIDZ (niezależnie od tego, czy korzystasz z RAIDZ, RAIDZ2 czy RAIDZ3), musisz z góry zdecydować, ile dysków chcesz w każdym vdev. Chociaż liczba dysków w wirtualnym urządzeniu wirtualnym jest stała, można je zwiększyć stopniowo (upewniając się, że nie przekracza progu nadmiarowości wirtualnego interfejsu wirtualnego), zastępując dyski dyskami o większej pojemności i zapewniając pełny resilver.

CVn
źródło
5
W moim pierwotnym pytaniu starałem się unikać argumentu zfs vs raid, ponieważ jest na ten temat wiele informacji. Chcę konkretnych informacji o mdadm. Ponadto, ponieważ nie będę czytał wszystkich danych wystarczająco często, aby zapewnić regularne czyszczenie danych, będę musiał regularnie wymuszać pełne czyszczenie tablicy, niezależnie od zfs lub raid.
BeowulfNode42
@ BeowulfNode42 osobiście Sugeruję użycie sum kontrolnych warstwy aplikacji dla wyjątkowo ważnych danych (np. Użyj sha256 do sumy kontrolnej ważnych danych). ZFS może to zrobić na blok, co moim zdaniem jest przesadą. Myślę, że to wyjaśnia, dlaczego niewiele systemów plików sumuje sumę kontrolną swoich bloków, tak jak robi to ZFS, ponieważ moim zdaniem jest to IMO.
jaskiniowiec
1
@caveman Nie wiem o tobie; Bardzo podoba mi się to, że nie muszę stale sprawdzać sumy plików, aby mieć pewność, że nie zostały uszkodzone. Oczywiście, w zdecydowanej większości przypadków nie ma korupcji , w którym to przypadku nie wyrządzono żadnej szkody (dzięki ZFS możesz wybrać algorytm sumy kontrolnej spośród garści, abyś mógł wybrać preferowany punkt wzdłuż kontinuum bezpieczeństwa / wydajności), ale zautomatyzowane sumy kontrolne na poziomie systemu plików gwarantują, że nie ma nieskorygowanego uszkodzenia, ponieważ jeśli tak, dowiesz się o tym, w przypadku ZFS, otrzymując błąd We / Wy zamiast uszkodzonych danych.
CVn
@ MichaelKjörling nope nie „gwarantuje” (zmniejsza jedynie prawdopodobieństwo niewykrycia błędów w stosunku do kontroli tylko na dysku, o kwotę, której nikt jeszcze nie określił! Dlatego nikt tak naprawdę nie wie, jak użyteczne jest sumowanie kontrolne ZFS :)), plus możesz użyć prostego opakowania „odczytującego” i „zapisującego”, które w przejrzysty sposób wykonuje dla ciebie sumę kontrolną. Nie trzeba umieszczać tej fantazyjnej rzeczy w przestrzeni jądra.
jaskiniowiec
3
@caveman nie, zfs nie jest na ten temat. Nie są też możliwe implementacje RAID, które nie są mdadm. Chcę wiedzieć o mdadm. Głosowałem już za tą odpowiedzią, jak tylko mogę, a wasze komentarze na temat odpowiedzi na temat niedziałający, wypełniając więcej informacji na temat odpowiedzi na temat nie na temat, nie pomagają w pierwotnym pytaniu.
BeowulfNode42
3

Ta odpowiedź jest wynikiem rozumowania opartego na różnych dowodach, które znalazłem. Nie wiem, jak działa implementacja jądra Linuksa, ponieważ nie jestem programistą jądra i wydaje się, że istnieje sporo bezsensownych dezinformacji. Zakładam, że jądro Linux dokonuje rozsądnych wyborów. Moja odpowiedź powinna mieć zastosowanie, chyba że się mylę.

Wiele napędów wykorzystuje ECC (kody korekcji błędów) do wykrywania błędów odczytu. Jeśli dane są uszkodzone, jądro powinno otrzymać URE (nieodwracalny błąd odczytu) dla tego bloku z dysku obsługującego ECC. W tych okolicznościach (i poniżej jest wyjątek) kopiowanie uszkodzonych lub pustych danych na dobrych danych oznaczałoby szaleństwo. W tej sytuacji jądro powinno wiedzieć, które dane są dobre, a które złe. Według It is 2010 i RAID5 nadal działa… artykuł:

Rozważ tę alternatywę, o której wiem, że może być używana przez co najmniej kilku dostawców macierzy. Gdy dysk w woluminie RAID zgłasza URE, kontroler macierzy zwiększa liczbę i spełnia wymagania we / wy, odbudowując blok z parzystości. Następnie wykonuje ponowne zapisywanie na dysku, który zgłosił URE (potencjalnie z weryfikacją), a jeśli sektor jest zły, mikrokod zostanie ponownie przypisany i wszystko będzie dobrze.

Jednak teraz wyjątek: jeśli dysk nie obsługuje ECC, dysk polega na uszkodzeniu danych lub oprogramowanie układowe jest szczególnie niefunkcjonalne, wówczas URE może nie zostać zgłoszony, a uszkodzone dane zostaną przekazane do jądra. W przypadku niedopasowania danych: wydaje się, że jeśli używasz 2-dyskowego RAID1 lub RAID5, jądro nie może wiedzieć, które dane są poprawne, nawet gdy nie jest on zdegradowany, ponieważ istnieje tylko jedna parzystość blok i nie zgłoszono URE. W 3-dyskowym RAID1 lub RAID6 pojedynczy uszkodzony blok nie oznaczony URE nie pasowałby do redundantnej parzystości (w połączeniu z innymi powiązanymi blokami), więc właściwe automatyczne odzyskiwanie powinno być możliwe.

Morał tej historii jest następujący: korzystaj z napędów za pomocą ECC. Niestety nie wszystkie dyski obsługujące ECC reklamują tę funkcję. Z drugiej strony, bądź ostrożny: znam kogoś, kto używał tanich dysków SSD w macierzy RAID1 z 2 dyskami (lub macierzy RAID10 z 2 kopiami). Jeden z dysków zwrócił losowo uszkodzone dane przy każdym odczycie określonego sektora. Uszkodzone dane zostały automatycznie skopiowane na prawidłowe dane. Jeśli SSD używał ECC i działał poprawnie, jądro powinno było podjąć odpowiednie działania naprawcze.

sudoman
źródło
1
Myślałem, że wszystkie współczesne dyski twarde mają jakąś formę wewnętrznego ECC. To, czy jest skuteczne, prawidłowe, czy działa nieprawidłowo, to inna sprawa. ECC musi być używane wewnętrznie w napędzie, aby móc zgłosić URE. Cicha zgnilizna bitów, którą najbardziej mnie interesuje, nie zgłasza URE nawet na dyskach, które go obsługują, ponieważ uważają, że mają poprawne dane, gdy ich nie mają.
BeowulfNode42
Przez zgniliznę bitów zakładam, że masz na myśli przypadkowe odwracanie bitów. W każdym razie ECC jest zaprojektowany do wykrywania odwróconych bitów. Według Wikipedii korekcja błędów Reeda-Solomona jest popularnym formatem ECC wynalezionym w 1960 roku i nadal jest stosowana na dyskach Blu-Ray + HDD. Jeśli odkryjesz, że ten algorytm jest wyjątkowo niezawodny, na twoje pytanie należy odpowiedzieć, ponieważ przyzwoity nowoczesny sprzęt z definicji jest tak samo dobry, jeśli nie lepszy, nawet jeśli nie znasz przyzwoitości sprzętu po prostu przez patrząc na to.
sudoman
1
Zgnilizna bitów może również wystąpić z powodu innych problemów, na przykład gdy jakiś problem powoduje, że głowice napędowe nie są odpowiednio ustawione do miejsca, w którym myśli, że pisze i przenosi się na pobliskie sektory. Może to naprawić sektor, nad którym zamierzał pracować, ale pobliski sektor zostanie uszkodzony. Jeśli zdarzy się, że zapisano dane + ecc w taki sposób, że ECC dla pobliskiego sektora zgłasza się jako w porządku, to dysk nigdy nie będzie wiedział, że ma problem. O wiele bardziej prawdopodobne, że niektóre nieuczciwe oprogramowanie nakazuje napędowi zapisywanie złych danych, dysk twardy wiernie przechowuje te złe dane. np. zła komenda dd
BeowulfNode42
2

Dla potrzebnej ochrony wybrałbym RAID6 + zwykłą kopię zapasową poza siedzibą w 2 lokalizacjach.

W każdym razie osobiście szoruję raz w tygodniu, a kopię zapasową wykonuję co noc, co tydzień i co miesiąc, w zależności od ważności danych i szybkości zmiany.

djsmiley2k w ciemności
źródło
1
ale jakie funkcje wykrywania / korekcji zgnilizny bitów to oferuje?
BeowulfNode42
1
RAID6 z częstym szorowaniem oferuje pewną ochronę przed gniciem bitów, ponieważ podwójna parzystość skutecznie tworzy trzy wersje tego samego bloku, więc można przeprowadzić „głosowanie”, która wersja jest odpowiednia. AFAIK, szorowanie RAID6 w Linuksie DM-RAID robi właśnie to, proszę mnie poprawić, jeśli się mylę.
P.Péter,
1
@ P.Péter Zdaję sobie sprawę, że matematyka MUSI używać systemu głosowania, ale czy mdadm? Czy znasz jakieś dokumenty na ten temat lub miałeś osobiste doświadczenie, które doprowadziło cię do tego wniosku? Zwłaszcza w świetle odpowiedzi Ethana.
BeowulfNode42
To było jakiś czas temu, ale niejasno pamiętam, zanim przeczytałem o mechanizmach mdadm RAID6. Przepraszamy, niezbyt konkretny. :( Chyba moglibyśmy użyć prawdziwego eksperta od mdadm ...
P.Péter
2

Nie mam wystarczającej liczby przedstawicieli do skomentowania, ale chcę zauważyć, że system mdadm w systemie Linux NIE koryguje błędów. Jeśli powiesz mu, aby „naprawił” błędy podczas szorowania, powiedzmy, RAID6, jeśli występuje niespójność, „naprawi” to, zakładając, że części danych są poprawne i ponownie obliczone parzystość.

Ethan
źródło
1
Wydaje się to raczej mało prawdopodobne, chyba że cię źle zrozumiem. Czy masz na myśli, że dane z uszkodzonych bloków często są kopiowane przez prawidłowe bloki? Wymagałoby to, aby zły blok nie pochodził z napędu obsługującego ECC (a tym samym nie zgłaszałby URE) i abyś używał RAID5 lub 2 kopii RAID1 (zamiast RAID6, jak sugerowałeś).
sudoman
@sudoman podczas szorowania, jeśli podsystem Linux MD wykryje niezgodność między danymi a parzystością, ślepo przyjmuje, że parzystość jest niepoprawna i ponownie zapisuje ją na podstawie danych. Możliwe jest użycie podwójnej parzystości RAID 6, aby dowiedzieć się, co jest złe, ale podsystem Linux MD tego nie robi.
Mark
1
Ethan, nie sądzę, że masz jakieś odniesienia do tych informacji? lub przykłady osobistych doświadczeń, którymi chcesz podzielić się tym, co pamiętasz? Biorąc pod uwagę to, że wygenerowało to tumbleweed, nawet anegdotyczne informacje byłyby pomocne. Od czasu opublikowania tego Q miałem problemy z mdadm RAID1 dla napędu rozruchowego, na (tanich) pendrive'ach USB, gdy 1 z nich poszło źle. Niektóre dochodzenia później wskazują, że wadliwa pamięć USB nie ma wystarczającej ilości lub nie ma możliwości sprawdzenia błędów, lub po prostu nie zapisuje danych w niektórych blokach i nie powoduje błędu zapisu. Musiałem ponownie zainstalować system operacyjny.
BeowulfNode42
-2

bit rot fud.? pewnie...

Chyba musisz porozmawiać z SEAGATE. (zapomnieć? czy to wymówka)? wszystkie dyski mają teraz 100-bitową korekcję ECC, musisz najpierw udowodnić zgniliznę.
Założę się, że nie możesz. (czy FUD ma się czym martwić, prawda?) jak strach przed duchami lub # 13? i nie zrobione tutaj. wydarzyło się zero dowodów. i, co gorsza, brak dowodu przyczyny.

Najpierw określ, co oznacza zgnilizna bitów. ouch ... HDD: ECC sprawdza dane (nawet 1 bit) względem 100-bitowej pamięci ECC. jeśli jest niepoprawny, poprawia go, jeśli ciągle zawiedzie silnik SMART, na pewno na dyskach SAS, logicznie zastępuje klaster lub sektor tym, który jest dobry. za pomocą zapasowych klastrów. naprawia to uszkodzenie. Tak, wszystkie dyski rosną od początku do końca, od pierwszych dysków IBM po NOW. ale teraz przeprowadzamy samodzielną naprawę. Przeczytaj pełne oficjalne dokumenty Seagate. niekończące się tam i dowiedz się, jak działa dysk. dobrze?

to trwa, dopóki nie zabraknie części zamiennych (mózg HDD, inteligentny), a następnie SMART krzyczy KONIEC ŻYCIA. (lub jeszcze wcześniej, jak HP), powiedzmy, kontroler HP P420, cały czas to obserwuje. Mój nawet e-maile do mnie, pokazując BLISKO SPARE klastrów. Czasami części zapasowe idą o wiele szybciej, pewny znak zagłady wkrótce (10 lat jest pewien, mniej w śmieciowych sata.

Nazywam się BOGUS, a FUD na zgniliznie bitów.

Domyślam się, że ktoś zabawkowy komputer źle zapisał dane, z jakichkolwiek powodów. nie działa pamięć ECC? Ups, prawdziwe serwery mają ECC RAM. zainfekowany wirusem. lub utrata zasilania podczas zapisu (brak UPS>?)? lub ma złą pamięć.? lub ESD uszkodzony. Lub zasilacz robi mnóstwo hałasu (źle)

Dzwonię do FUD tutaj. Przepraszam,

savvy2
źródło
1
Właśnie wyjaśniłem, że mówię o moim systemie domowym, więc sprzęt klasy ECC i serwerowy nie mieści się w moim przedziale cenowym. Moje domowe laboratorium jest znacznie bardziej podatne na nieoczekiwane straty mocy, nawet z jego mini-upami lub innymi przypadkowymi zdarzeniami, takimi jak upadek wieży lub coś takiego. Istnieje wiele innych sposobów, w których HDD może zostać poproszony o przechowywanie niewłaściwych danych i poproszenie HDD o przechowywanie bitów ECC dla tych niewłaściwych danych. Nie dbam o to, jak wystąpiły błędy, chcę je łatwo naprawić.
BeowulfNode42