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é).