Printable View
Zdravim vospolok,
chcel by som zistit od tych, co maju RAID5 na Intelackych ICH R radicoch, aku maju rychlost citania a HLAVNE zapisu na svojich poliach.
Pri uvahach nad SW RAID5 som totizto narazil na dost brutal "rychlosti" zapisu (co logicky vyplyva z funkcnosti RAID5, ked XORuje procesor pri presuvani dat po zbernici hore-dolu) http://forums.slizone.com/lofiversio...php?t5202.html no Darth Maul (jediny o kom viem, ze tu ma RAID5) mi to nebol schopny potvrdit ani vyvratit...
už si nepamatuju kolik to bylo, ale určitě vím, že to bylo hodně mizerné, hlavně tady ten zápis; přikoupil jsem ještě jeden hdd a udělal s toho raid10...
XORovanim v CPU to IMHO nebude, v linuxovy MD RAID umi XORovat na jednom modernim jadru rychlosti cca 5-8GBps, takze i kdyby byla ta SW implementace hodne zprasena, tezko bude mene nez treba 1GBps, takze to brzda asi nebude. Zapis do RAIDu 5/6 brzdi predevsim fakt, ze je tam min o jedno cteni navic, kvuli prepocitani parity. Je mozne, ze ty operace zapisu a cteni ten SW radic neumi nejak inteligentne preusporadat. Hodne take muze udelat zvolena velikost stripe size. Tech 10 a 15MBps bude nejaka strasna buga, to prece nemuzou myslet vazne.
Petrik:
Ked si uvedomis ako to funguje (popisane je to v tom linku, co som hodil do uvodneho postu), tak je ta pomalost kludne mozna (4 disky v poli).
Neviem, preco sem Maul neprispeje, tak to spravim zanho ;D
Kopirovanie v ramci pola 3x wd7500aaks raid5 na ich9r ma bez mala 21MB/s...
U mna kopirovanie v ramci disku wd5000aaks na ich9r ako ahci single disk je bez mala 31MB/s...
Prave preto som zalozil tento thread a chcem realne skusenosti/testy.
Aha, to vysvetluje, proc full SW RAIDy timto netrpi. Oni totiz paritu spocitaji jeste pred tim, nez zacnou cokoli nekam posilat a zapisovat. Kdyz se dela full-stripe write, tak si ty data OS natahne do RAM, spocita paritu a pak to cele posle na jednotlive disky. takze RAID-5/6 na onborad raidech proste ne, to je dobre vedet :)
Pokud vim, tak obecne problem 5ky je predevsim rebuild = kdyz vypadne jeden z disku a vymeni se, tak to muze trvat hodiny a po tu dobu je pole temer nepouzitelny.
Cteni by melo byt (pokud je dobre implementovano) znacne rychlejsi proti samostatnymu disku (funguje to stejne jako strip).
Zapis, coz je oc tu bezi, by nemel byt nijak vyrazne ovlivnen a mel by +- odpovidat zapisu na samostatny disk. Dopocitavani neni nijak vypoctove narocne, viz ty GB vejs.
Ovsem co se zkusenosti tyce, nemam aktualne na tomhle chipu raid, ale na jinych jsem to zkousel a vzdy to fungovalo velice spatne.
Ten zapis je komplikovanejsi nez se zda. Pokud se nezapisuje cely full stripe pres vsechny disky, tak se musi precist zbyvajici neprepsane stripy, aby bylo mozne dopocitat paritu. Cim vetsi je stripe size, tim casteji k tomuto dochazi. Zaroven pak je ale zase mozne cist vice souboru naraz, protoze je vetsi pravdepodobnost, ze budou na vice discich. Jak jsem pochopil ten odkaz, co sem hazel Pit, tak u pseudo SW onboard RAIDu je problem v tom, ze kdyz chce OS zapsat neco na to pole, tak to posle tomu radici, takze presun z RAM do radice. Ten to ale obratem posila zpet do pameti a do CPU, aby mohl spocitat paritu (pomoci CPU) a pak to jde zase zpet do radice a az pak konecne na disky. Osobne se mi to moc nezda, ale mozne to je. Plne SW RAID toto presouvani tam a zpet neprovadi, protoze si muze udelat vypocet parity v pameti rovnou a hotovo.