reklama

RAID5 silent data corruption/detection

RAID5 silent data corruption/detection
« kdy: 22. 01. 2015, 09:25:04 »
Zdravím,
včear jsem přemýšlel jakým způsobem na je na sw RAID5 udělána detekce silent corruption.
Pokud nastane silent data corruption tak jakým způsobem je možno zjistit v jakém stripu k poškození došlo.
Jestli by v každém stripu byl použit paritní bit tak by bylo možné detekovat 1bitovou chybu ale co 2bity...
CRC pokud si sw raid nepočítá.
Díky za vysvětlení.

reklama


Re:RAID5 silent data corruption/detection
« Odpověď #1 kdy: 22. 01. 2015, 09:26:28 »
CRC pokud si sw raid nepočítá.
Mělo být:
CRC pokud vím si sw raid nepočítá.

Jenda

Re:RAID5 silent data corruption/detection
« Odpověď #2 kdy: 22. 01. 2015, 10:28:00 »
včear jsem přemýšlel jakým způsobem na je na sw RAID5 udělána detekce silent corruption.
Na linuxovém MD-RAIDu vůbec nijak. V rozumném operačním systému by na konci každého bloku nebo stripu bylo CRC nebo dokonce samoopravný kód. Na Linuxu to ale nikdo nedělá. Můžeš použít souborový RAID ZFS, které alespoň počítá CRC bloků souboru.

Re:RAID5 silent data corruption/detection
« Odpověď #3 kdy: 22. 01. 2015, 11:04:43 »
Na linuxovém MD-RAIDu vůbec nijak. V rozumném operačním systému by na konci každého bloku nebo stripu bylo CRC nebo dokonce samoopravný kód. Na Linuxu to ale nikdo nedělá. Můžeš použít souborový RAID ZFS, které alespoň počítá CRC bloků souboru.

Jak tak čtu tvoje komentáře z poslední doby, tobě musel Linux udělat něco opravdu hodně ošklivého.  :(

Tohle je o (filozofickém) pohledu na stavbu systému. Je otázkou, zda si tohle nemá řešit HW sám. Tedy HW (v tomto případě disk) vrátí buď data (vždy správná) nebo data nevrátí a ohlásí chybu. Mě (z hlediska oddělení rolí) nepřipadá úplně správné na straně SW řešit HW problémy. Kontrolovat ano, opravovat ne.

Jinak RAID5 (žádný) nepozná, který stripe je vadný už přímo z definice R5.

Existují systémy souborů, které implementují různé stupně redundance a také ukládají a kontrolují kontrolní součty. Takové FS (BTRFS, ZFS), potom poznají, že blok, který načetly z disku, je špatný (resp. že neodpovídá kontrolnímu součtu, může být špatný ten součet).

Jinak silent data corruption vznikají především úplně jinak než tím, že disk vrátí jiný blok. Tohle totiž lze ještě docela dobře detekovat (takže to není tak úplně silent).

Re:RAID5 silent data corruption/detection
« Odpověď #4 kdy: 22. 01. 2015, 11:38:32 »
Je otázkou, zda si tohle nemá řešit HW sám. Tedy HW (v tomto případě disk) vrátí buď data (vždy správná) nebo data nevrátí a ohlásí chybu.
Možná moderní disky se takto chovají. Ale na úrovni firmware disku. Jak jinak by probíhala detekce chyb a realokace sektorů.
Někde jsem našel že každý block má CRC ale je to informace z nějakého fóra.
Pokud by to tak bylo je samozřejmě zbytečné to řešit na úrovni raidu.

reklama


Re:RAID5 silent data corruption/detection
« Odpověď #5 kdy: 22. 01. 2015, 11:40:47 »
Jinak silent data corruption vznikají především úplně jinak než tím, že disk vrátí jiný blok. Tohle totiž lze ještě docela dobře detekovat (takže to není tak úplně silent).
Jak jinak tedy vzniká rád se poučím. Díky.

Kolemjdoucí

Re:RAID5 silent data corruption/detection
« Odpověď #6 kdy: 22. 01. 2015, 11:51:43 »
včear jsem přemýšlel jakým způsobem na je na sw RAID5 udělána detekce silent corruption.

Nijak a to ani SW ani HW RAID.

Na linuxovém MD-RAIDu vůbec nijak. V rozumném operačním systému by na konci každého bloku nebo stripu bylo CRC nebo dokonce samoopravný kód.

RAID tady není od zabezpečení dat, nýbrž jako ochrana před selháním HDD.

Je otázkou, zda si tohle nemá řešit HW sám. Tedy HW (v tomto případě disk) vrátí buď data (vždy správná) nebo data nevrátí a ohlásí chybu. Mě (z hlediska oddělení rolí) nepřipadá úplně správné na straně SW řešit HW problémy. Kontrolovat ano, opravovat ne.

HW to řeší, HDD má CRC na každý sektor (512 nebo 4096 byte) a SATA komunikace je zabezpečena CRC.
Samozřejmě to není dokonalé, ve spotřební elektronice kam spadají běžné PC a notebooky například není zabezpečena RAM/cache proti účinku kosmického záření a data z/do HDD se při I/O operaci proběhnou přes minimálně tři různé RAM/cache.

Re:RAID5 silent data corruption/detection
« Odpověď #7 kdy: 22. 01. 2015, 12:01:25 »
Možná moderní disky se takto chovají. Ale na úrovni firmware disku. Jak jinak by probíhala detekce chyb a realokace sektorů.
Někde jsem našel že každý block má CRC ale je to informace z nějakého fóra.
Pokud by to tak bylo je samozřejmě zbytečné to řešit na úrovni raidu.

Ano, každý blok uložený (fyzicky) na disku má na konci ECC, který kontroluje přímo samotný disk. ECC dovoluje malé chyby opravit a větší detekovat.

CRC má dále i samotné rozhraní mezi diskem a řadičem (SATA, SAS), kde se ověřuje přenos dat mezi diskem a řadičem. Každá sběrnice má nějakou vlastní formu CRC nebo i samoopravného kódu, přímo na úrovni HW.

Otázkou tak zůstává, kolik chyb může reálně projít až do OS.

Jak jinak tedy vzniká rád se poučím. Díky.

Tak samozřejmě různě. Asi nejhorší poškození dat, na které jsem v praxi narazil, způsobila jistá nejmenovaná takydatabáze, která se tvářila, že umí transkace (a spousta lidí tomu dodnes věří), ale příkaz rollback částečně nebo úplně ignorovala. Takže aplikace v nestandardní situaci správně zavolala rollback, každá normální db by data vrátila do původního stavu před transakcí, ale zrovna tahle se rozhodla jen pro částečný úklid.

Než si tohoto všimla obsluha aplikace (za normálních okolností to bylo neviditelné, což bylo dané návrhem aplikace, která zobrazovala relativně správná data*), tak byla chyba zpropagována na všechna záložní media (a ostatně data stará několik let by byla stejně k ničemu).

*) Což je poučení i pro návrh aplikace, chyby v datech by se měli co nejvíce amplifikovat a nikoliv potlačovat. Kdyby v tomto případě aplikace na vadných datech selhala, objevilo by se to v řádu minut.

Sice to není příklad klasického data silent cor. kdy zařízení vrátí jiná data než se tam uložila, ale výsledek je stejný. Formálně jsou data v pořádku, ale ve skutečnosti jsou vadná (nelze rozhodnout, které záznamy jsou správné a které měli být rollbacknuté).

Jenda

Re:RAID5 silent data corruption/detection
« Odpověď #8 kdy: 22. 01. 2015, 14:01:04 »
Jak tak čtu tvoje komentáře z poslední doby, tobě musel Linux udělat něco opravdu hodně ošklivého.
Ále, taková zatrpklost a trolling. Asi bych s tím mohl přestat :)

Tohle je o (filozofickém) pohledu na stavbu systému. Je otázkou, zda si tohle nemá řešit HW sám. Tedy HW (v tomto případě disk) vrátí buď data (vždy správná) nebo data nevrátí a ohlásí chybu. Mě (z hlediska oddělení rolí) nepřipadá úplně správné na straně SW řešit HW problémy. Kontrolovat ano, opravovat ne.
Tak v disku se to už řeší. Ale ještě tam máš ten SATA kabel, RAM/cache disku a řadiče (opravdu to má ECC? stačí jednoduché ECC typu parita, tj. nemůže se stát, že když už dojde k poruše, překlopí se hned 2 bity?) a PCIe, která nevím, jak na tom je s konzistencí. Zase když dojdeš takhle hluboko, tak si nemůžeš být jistý, že ti procesor správně počítá :)

Já se přiznám, že jsem silent data corruption ještě neviděl. Disk vždycky hodil chybu. Nemám žádné petabajty, ale jak se psalo, že dojde k chybě každých 12 TB, tak to můžu jednoznačně vyloučit.

Re:RAID5 silent data corruption/detection
« Odpověď #9 kdy: 22. 01. 2015, 14:42:30 »
Ále, taková zatrpklost a trolling. Asi bych s tím mohl přestat :)

To znám.

Tak v disku se to už řeší. Ale ještě tam máš ten SATA kabel, RAM/cache disku a řadiče (opravdu to má ECC? stačí jednoduché ECC typu parita, tj. nemůže se stát, že když už dojde k poruše, překlopí se hned 2 bity?) a PCIe, která nevím, jak na tom je s konzistencí. Zase když dojdeš takhle hluboko, tak si nemůžeš být jistý, že ti procesor správně počítá :)

Přenos po SATA kabelu je ošetřen přes nějaké CRC, stejně tak PCIE apod. Paměti mohou být ECC také. Cache v CPU ECC mají (min. u AMD).

Já se přiznám, že jsem silent data corruption ještě neviděl. Disk vždycky hodil chybu. Nemám žádné petabajty, ale jak se psalo, že dojde k chybě každých 12 TB, tak to můžu jednoznačně vyloučit.

U disků také ne. Měl jsem podezření, že se mi kazí zejména multimediální soubory (co šlo před lety přehrát to už dneska nejde), tak mám sha512 sumy všech souborů na disku, které nepravidelně kontroluji a za x let ani jedna vada. Nakonec jsem přišel na to, že se u přehrávačů snižuje schopnost přehrávat poškozené soubory, takže zatímco přehrávač před 8 lety s daným videem neměl nejmenší problém, tak letos už nelze přehrát (musel jsem to prohrat přes ffmpeg nebo mencoder a opravit kontejner). Stejně tak poškozené mp3 (o kterých jsem věděl, že jsou poškozené) se dřív přehrávaly v pohodě (výpadek frame sice byl slyšet, ale přehrávač se ho snažil zamaskovat), tak dneska přehrávače vydávají pazvuky.

Opět, kdyby přehrávače i před těmi 8 lety upozornily na vadný soubor, řešil bych to hned a nehledal bych problém tam kde není (ale co, kontrola sha512sum ničemu neuškodí).

 

reklama