Administrace komentářů

Co dělám špatně, že jsou data poničená, když jeden disk chybí?

Všechno špatně. RAID funguje jedině tehdy, ví-li o něm filesystém a je-li integrovaný do filesystému. Tedy Btrfs nebo ZFS dávají smysl jako RAID. Ten RAID, o kterém filesystém neví, je náchylný k silent data corruption, což je přesně tato situace.

Problém je, že softwarový (ba i hardwarový, to je úplně jedno) RAID 5, který není integrovaný ve filesystému, splní svůj účel jedině tehdy, pokud disky selhávají stylem všechno nebo nic. Předpokládá se tedy, že disk buď vrací 100% správná data a nedělá nikde chyby, nebo okamžitě a úplně selže, aniž by kdy vrátil špatná data. Takový předpoklad je od praxe na hony vzdálený.

Kdyby tam byl Btrfs RAID 5 nebo ZFS RAIDZ, tohle by se nikdy nestalo díky automatickým checksumům, které filesystém používá. Pro příklad uvažme, jak se z RAIDu 5 čte. Máme-li pole s N disky, pak k přečtení dat stačí 4 disky a na pátém je paritní součet (ať už xor nebo něco sofistikovanějšího). Parita je distribuovaná, tedy každý RAID blok má paritní součet na jiném z disků, aby v RAIDu nebyl jeden přetížený paritní disk. Když je třeba přečíst data, stačí k tomu pouze N - 1 z N disků. Nikdo při čtení automaticky nekontroluje paritu na tom N-tém disku, jestli opravdu sedí — kvůli efektivitě, samozřejmě. Mnohem dalekosáhlejší důsledky z hlediska efektivity má v tomto směru třeba prokládané čtení z několika disků u RAID 1. Ale to už odbočuju. U RAID 5 s N disky je zkrátka potřeba N - 1 operací k přečtení toho, co se zapisovalo N operacemi.

U hardwarového nebo softwarového RAIDu 5 bez podpory ve filesystému se v případě poškození dat na discích přečtou a vrátí špatná data a nikdo problém neodhalí. Selže-li následně jeden z disků, teprve tehdy se při čtení použije parita. Byla-li původní data špatná, rekonstrukce pomocí parity vrátí zase špatná data, ať už je parita samotná zachovaná správně nebo špatně. Není proti tomu žádná účinná prevence!

RAID 1 bez podpory ve filesystému má tentýž problém. Při prokládaném čtení nezjišťuje, jestli se repliky shodují, a i kdyby se neshodovaly, bez checksumů nemá absolutně žádnou možnost zjistit, která z replik mluví pravdu.

RAID 5 v Btrfs nebo RAIDZ v ZFS naopak tohle všechno ustojí bez problémů. Dejme tomu, že při čtení z pole u jednoho disku nesedí checksum pro nějaký stripe. Pak filesystém zaprvé hned ví, na kterém disku jsou pro daný RAID blok špatná data, a zadruhé ví, že musí mimořádně pro tento blok přečíst také paritu (samozřejmě rovněž chráněnou checksumem!) a dopočíst správná data z parity a z N - 2 ostatních zdravých stripů. Navíc je namístě rovnou opravit stripe na tom disku, kde neseděl checksum, aby se pro celý RAID blok zase obnovila plná redundance.

Pro RAID 1 v Btrfs nebo ZFS platí totéž. Čte se prokládaně jako všude jinde a dokud checksumy sedí, je to v pořádku. Jakmile checksum nesedí, načte se daný blok z jiné repliky — z takové, kde checksum sedí — a následně se obnoví pořádek. Opět přímo filesystém ví, která replika selhává a odkud je možné ji obnovit.

Je tohle normální chování raid5?

Ano, je. RAID 5 bez podpory ve filesystému nedává smysl. Je náchylný přesně k těmto chybám, zejména když je na něm navíc ještě nějaký filesystém z minulého desetiletí, který nejen neumí RAID, ale dokonce zjevně ani nedělá checksumy dat. (Hrůza pomyslet!)

Postupem doby pravděpodobnost okamžitého totálního selhání celého disku klesá, zatímco pravděpodobnost silent data corruption roste. To druhé má taky souvislost s rostoucí kapacitou disků. RAID 5 bez podpory ve filesystému nechrání data před poškozením. Některá fakta se člověk naučí the hard way — tak už to v životě chodí.

<off_topic>

Už se těším, až mi jednou zase některý slavný místní žvanil bude tvrdit, že silent data corruption v praxi neexistuje a že disky selhávají jedině jako celek. Skvělou odpovědí pak bude odkaz na tento dotaz. (Ne že by se na webu neválelo hned několik barvitých popisů dalších podobných incidentů.)

</off_topic>