RAID, 2x500 - jaky zvolit?

[Fox!MURDER]

ufff to je mi protichudnejch poznatku ... taky jich par pridam


RAID0 - strip
- data se rozdeli na n casti, z nichz kazda se ulozi na jiny disk
rychlost: temer zdvojnasobeni sekvencnich read i write operaci, pri seeku zrychleni nulove.
redundance: nema redundanci. vypadek jedineho disku znici cele pole.
pozadavek: 2 a vice disku
kapacita: n*nejmensi disk

RAID1 - mirror
- vsechna data jsou ulozena ve stejne podobe na vsech discich
rychlost: pri dobrem raidici/sw raidu (fbsd6-gmirror je perfektni ukazka) muze zdvojnasobit rychlost pri seekujicim cteni. rychlost sekvencniho cteni a libovolneho zapisu zustava zhruba stejna - pozor! nezkrati samotny seek, jen zrychli hodne seekujici operace.
redundance: vypadek vsech disku, krom jednoho, je pripustny
pozadavek: 2 a vice disku
kapacita: nejmensi disk

RAID10 - stripped mirrors
- mirrory o q (q>=2) discich se spojuji do RAIDu 0
rychlost: zhruba kombinuje vyhody 0 i 1
redundance: vypadek vsech disku v jednom mirroru znamena ztratu dat
pozadavek: 4 a vice disku
kapacita: (n/q) * nejmensi disk

RAID5
- data se rozdeli na n-1 casti, ze kterych se pomoci postupneho XORovani vytvori redundantni data
pak se ukladaji v podobe (pet disku)

d1 d2 d3 d4 p
d2 d3 d4 p  d1
d3 d4 p  d1 d2
d4 p  d1 d2 d3
p  d1 d2 d3 d4

d1 - d4 jsou casti dat, p je parita
rychlost: tady to zacina byt slozitejsi ... co se rychlosti sekvencniho cteni/zapisu tyce a seekujiciho cteni, tak se vpodstate chova jako RAID0 z n-1 disku ... ovsem pokud zapisuje bloky dat mensi, nez je 1 blok tohoto raidu, musi se cely blok ze vsech n-1 disku precist, prepocitat redundantni data a znovu zapsat... (ale to opravdu jen v pripade nahodnych zapisu mensich bloku. pri sekvencnim zapisu mensich bloku to vetsinou radice/sw raidy resi tzv. extent cache, kam si ukladaji nekolik naposledy zapsanych bloku, aby nebylo nutne je znovu cist). muze mirne zatezovat CPU (Core Duo U2500 - 1.2GHz - 3GB/s)
redundance: vypadek 2 a vice disku znamena ztratu dat
pozadavek: 3 a vice disku

RAID 3
- stejny jako RAID 5, jen data se na disky ukladaji takto:

d1 d2 d3 d4 p
d1 d2 d3 d4 p
d1 d2 d3 d4 p
d1 d2 d3 d4 p
d1 d2 d3 d4 p

nevyhoda proti RAID5 je o neco mensi rychlost pri vypadku datoveho (ne paritniho) disku.

RAID 50 (a 30)
- je to vpodstate stejne jako u RAIDu 10, ale ve stripu se spojuji RAIDy 5 o q discich
rychlost: tady je to hodne osemetne ... a vyplati se zejmena pri spojovani poli na vice radicich.
redundance: vypadek dvou a vice disku z jednoho RAIDu 5, znamena ztratu dat
pozadavek: 6 a vice disku (sudy pocet)
kapacita: (n/q) * (q-1) * nejmensi disk

RAID 6
- velmi podobne RAIDu 5, ovsem data se deli na n-2 casti a pouzivaji se dva redundantni disky
rychlost: velmi podobne jako RAID5 s prihlednutim k mensimu poctu datovych disku. CPU zatezuje vice nez RAID 5 (Core Duo - U2500 1.2GHz - 1.4GB/s)
redundance: vypadek 3 a vice disku znamena ztratu dat
pozadavek: 4 a vice disku
kapacita: n-2 * nejmensi disk

JBOD (Just Bunch of Drives)
- jedna se o proste spojeni kapacity disku
rychlost: tady velmi zalezi na pristupu. pro sekvencni cteni/zapis je rovna rychlosti jednoho disku, pri nahodnem cteni zapisu zalezi na rozdeleni. pri opravdu nahodnem cteni i zapisu (a pro stouraly - stejne kapacite disku) by mel n krat znasobit rychlost.
redundance: zadna
pozadavek: 2 a vice disku
kapacita: soucet kapacity vsech disku

info o zatezi CPU plati pro SW based raidy (tj. ty implementovane na urovni OS, nebo ovladace (tzv. HostRAIDy - levne RAID radice a radice na zakl. deskach))

co se poznatku z realneho sveta tyce:
RAID5 opravdu nasobi rychlost sekvencniho zapisu (i cteni)
15x500G disk, 3Ware Escalade 95xx serie radic, 400MB/s cteni, 250MB/s sekvencni zapis.
RAID1 opravdu nezrychli sekvencni cteni jednoho streamu. vyzkouseno. zduvodneno. pri cteni 2 a vice streamu pomaha znacne.
RAID5 s jednim spare diskem se zda byt dostatecne bezpecnym (provozujem takovych raidu asi 40 a zatim vsechny prezily)
Kvalitni HW RAID radic udela stejnou sluzbu jako SW raid. vyhodou je hlavne snizeni zateze CPU, obcas jednodussi konfigurace a obcas vetsi moznosti, pripadne v nekterych pripadech (diky velke cache) vyssi rychlost. Na druhou stranu ovsem SW RAID (ten implementovany v OS) je uplne nezavisly na radici a tedy v pripade jeho odejiti, lze pole provozovat na jinem HW ... to neni vzdy pravda u HW raidu (nektere jsou vice kompatibilni, jine mene)

edit: mimochodem z linuxu mam overeno, ze mnohem vic, nez zmena raidu, nebo rychlejsi disky, pomuze rychlosti nahodneho cteni/zapisu dobre nakonfigurovany i/o scheduler ...

[Petrik]

Krasne vysvetlene, dekujeme
Par poznamek:
1) ty konfigurujes i/o scheduler v linuxu? ja myslel ze jde tak maximalne nejaky zvolit ...
2) rychlost zapisu RAIDu 5: kdyby to bylo se sekvencnim zapisem do RAIDu tak jednoduche, tak by mel preci dosahovat priblizne stejneho vykonu jako dosahuje stripe N-1, tedy -+ stejneho jako cteni. Tak to ale neni, vykon je temer polovicni (250 vs. 400). Paritu muze ukladat soubezne s daty a jelikoz je stejne velka, nemelo by to zabrat zadny cas navic....zrejmne tam ten radic / SW provadi jeste neco jineho a podle me to bude mit neco spolecneho se snahou o udrzeni konzistence pole v pripade padu....
3) Hlavni duvod, proc se nepouziva RAID 3, je ten, ze pri zapisu malych bloku je paritni disk brzda systemu a jelikoz je vzdy na stejnem disku, je to pri vice I/O pozadavcich problem. RAID5 ma distribuovanou paritu, takze tam toto nehrozi.
4) nekde jsem cetl ze nektere radice dokazi pri RAID-1 cist polovinu dat z jednoho a druhou polovin uz druheho, takze dosahuji podobneho vysledku cteni jako stripe.

[jan555]

ufff to je mi protichudnejch poznatku ... taky jich par pridam

Přidals . (byť chápu snahu, tak ty obecné specs jsou škoda místa - na webu jsou během vteřin mnohem detailnější a vzhledem k topicu je zbytečné řešit enterprise levely jako 50 nebo archiválie typu level 3, to už bychom tu rovnou mohli vysmahnout ty - řádově desítky! - existujících levelů)

Nebudu to nějak zvlášť rozebírat, ale jedno je důležité říct - nemíchejte jablka s hruškami, což se právě stalo. Ani nastavení řadičů ani reporty o výkonnosti NEJSOU aplikovatelné přes platformy a dokonce ani přes typy řadičů a co víc ani přes modely řadičů! Proto pokud se bavíme o desktop low-end řešeních RAIDu, NENÍ MOŽNÉ na ně aplikovat prakticky žádná podobná zjištění z prosumer nebo enterprise segmentu.

Kdybychom se bavili o slušných řadičích, tak vám také rovnou řeknu, ať se např. vykašlete na RAID5 a nahodíte rovnou RAID5EE a při dnešní ceně disků bych stejně z fleku řekl, ať si doma uděláte RAID1E0 (případně 01). Bohužel, ani na jeden z těchhle levelů nemají on-board řadiče nárok.

Kvalitni HW RAID radic udela stejnou sluzbu jako SW raid. vyhodou je hlavne snizeni zateze CPU, obcas jednodussi konfigurace a obcas vetsi moznosti, pripadne v nekterych pripadech (diky velke cache) vyssi rychlost.

Zásadní omyl. SW řadiče obecně HW řadičům odpovídají právě jen v základní funkčnosti, tzn. schopnosti poskytnout některé základní služby. Vlastnosti té služby jsou ale fakt jinde, viz ten odstaveček na začátku. I pokud vezmeš dva externí řadiče, se stejným feature-setem a cenou, tak jeden klidně rozseká ve výkonnosti druhý na kaši. Prostě proto, že má lepší procesor nebo algoritmus, nebo obojí. (RAID level říká jen princip, neříká už, jak cíle dosáhnout) Pokud se budeme bavit speciálně o level 5, tak tam je dobrý řadič (což je otázka už nějakých 10K) poznat tak, že kdo neviděl, neuvěří. A pokud si hodíš na SW řadič 10 disků do level 5, tak je takový řadič ve výkonu rozmasakruje v pohodě i se 3 disky - prostě je fajn, že SW řadiče dneska umí poskytnout v dostatečné kvalitě základní funkčnost, ale o nějakých výkonech tam řeč moc být nemůže. (právě to jsou ale řadiče, o kterých tu jde řeč ...)

[jan555]

4) nekde jsem cetl ze nektere radice dokazi pri RAID-1 cist polovinu dat z jednoho a druhou polovin uz druheho, takze dosahuji podobneho vysledku cteni jako stripe.

Takhle jsem to v reálu fungovat neviděl, samozřejmě lepší řadiče se chytají víc, ale ta logika nejde (a asi nemůže jít?) až tak daleko, aby byl schopný při random v realtime čase posoudit, který postup je u každého bitu/bit-setu rychlejší, tzn. imho to takhle nejde. (kdybys to někde našel, tak bych si to rád přečetl!)

Jiná srandička je RAID1E např. na ServeRAIDu 8i, který v pojetí právě IBMky (naopak třeba u Adaptecu to neplatí) zajistí read performance na úrovni RAID0. A když se to pak posune o level výš na 1E0, tak se při readu začnou dít HODNĚ zajímavé věci .

[Petrik]

To je zrejmne pokus o dost slusny flame, pokud SW radicem myslis i treba linuxovy MD RAID. Zasadni otazka: pracoval jsi nekdy s MD RAIDem v linuxu? Predpokladam, ze ne. Nova jadra umeji dokonce vychytavky typu 1E0 a pod, vykonem muzou byt dokonce pred HW radici, protoze jaksi nemaji zadne uzke hrdlo jako je napr. pomaly procesor na tom HW radici. Cena za to je vetsi zatizeni CPU, ale treba Athlon X2 3800+ dokaze generovat XORy rychlosti 6GBps (na jedno jadro), takze asi chapes, jak male je jeho vytizeni pri beznych rychlostech zapisu do pole. Dale se daji delat vychtavky typu RAID 3 z beznych disku a na paritni disk dat treba stripovane raptory, takove pole uz bude mit pomerne hodne rychly zapis. Dalsi vyhoda je ze MD RAID operuje na urovni diskovych oddilu, takze muzes kombinovat ruzne raidy na stejnych discich a pod. Dalsi vyhoda je IMHO provazanost RAID enginu s jadrem OS a hlavne s I/O schedulerem; umim si predstavit ze to pri velke I/O zatezi muze vyznamne pomoci, protoze I/O scheduler pracuje s jednotlivyma diskama a ne s jedinym polem takze muze lepe predpovidat a pod.

Zásadní omyl. SW řadiče obecně HW řadičům odpovídají právě jen v základní funkčnosti, tzn. schopnosti poskytnout některé základní služby. Vlastnosti té služby jsou ale fakt jinde, viz ten odstaveček na začátku. I pokud vezmeš dva externí řadiče, se stejným feature-setem a cenou, tak jeden klidně rozseká ve výkonnosti druhý na kaši. Prostě proto, že má lepší procesor nebo algoritmus, nebo obojí. (RAID level říká jen princip, neříká už, jak cíle dosáhnout) Pokud se budeme bavit speciálně o level 5, tak tam je dobrý řadič (což je otázka už nějakých 10K) poznat tak, že kdo neviděl, neuvěří. A pokud si hodíš na SW řadič 10 disků do level 5, tak je takový řadič ve výkonu rozmasakruje v pohodě i se 3 disky - prostě je fajn, že SW řadiče dneska umí poskytnout v dostatečné kvalitě základní funkčnost, ale o nějakých výkonech tam řeč moc být nemůže. (právě to jsou ale řadiče, o kterých tu jde řeč ...)

[jan555]

To je zrejmne pokus o dost slusny flame, pokud SW radicem myslis i treba linuxovy MD RAID.

Ne, to nemyslím. Moje chyba v zobecnění (a zřejmě také v tom, že se chci alespoň jakž takž udržet subjectu).

vykonem muzou byt dokonce pred HW radici, protoze jaksi nemaji zadne uzke hrdlo jako je napr. pomaly procesor na tom HW radici.

Tady by sis koledoval o flame ty ... (ale nebude, to není moje) Proto, co se tobě nelíbilo na tom, co jsem napsal, je jednoduché vysvětlení (viz výše) a není to záměrná dezinformace, což není případ téhle citace. Teoreticky je skutečně možné leccos, prakticky už je to horší. Nevím o tom, že by i zcela standardní IOP321 měl pro svůj účel slabý výkon a to je schopen obsluhovat pole s řádově větším počtem disků než můžeš na mobo kdy mít (a přitom má např. peak i/o spotřebu 1W). Pokud bychom se také bavili o procesoru jako slabším článku u čistě SW RAIDu, bude to především kvůli základním principům - např. nutnosti multi-překladu nebo nutnosti využívání zbytečně složité a nevyhovující architektury CPU. Ale to je snad jasné, proč dál asi může být SW RAID rychlejší jen teoreticky? Externí řadič profituje z vlastního procesoru (a věcí s tím spojených), u SW řadiče instrukce a data z portů na procesor levitují, nebo jak se tam dostanou? Nepotřebují a nevytěžují náhodou defacto kompletní hlavní cesty? Neznamená to náhodou latence, zátěž a omezení všeho ostatního? Ještě ti přijde, že SW řadič nemá žádné úzké hrdlo? Že je to zcela plnohodnotná alternativa?

Skutečně rád si přečtu (nemyšleno ironicky) nějaké materiály, kde je natestováno, že je SW RAID (samozřejmě v Linuxu) výkonnější než dedikovaný řadič a může tam být i vysvětleno, proč i Linuxové top-class enterprise servery jedou na dedikovaných FC řadičích s gigabyty cachí, proč nevím o žádném benchi, kde by zaznamenal SW řadič rekordy, atd. Zcela pochopím, že pokud sám provozuješ typicky file-server, že je to zcela dostačující a rozdíly nejsou zásadní, u většiny ostatních rolí bych si o tom dovolil zvesela pochybovat.

[Paolo]

Pěkně se to tu rozjelo a musím se jana555 zastat, protože debata začala o RAID řešeí na ICHxR čipsetu, tudíž debaty o HW RAID řadičích nebo SW - MD RAIDu jsou zcela off-topic.

na butchersonův dotaz odpovím ještě jednou: protože budeš mít jen jedo pole (jakoby jeden fyzický disk) tak se Ti bude častěji stávat, že budeš kopírovat (balit, rozbalovat, ...) data ze stejného disku na stejný disk a tam je RAID1 cca 2x rychlejší než RAID5 se třemi disky (hovořím o řešení RAID na ICHxR čipsetu).

Jinak RAID5 kopíruhe na druhý RAID5 rychlostí 50-80MB/s na NTFS pod WinXP (C2D 6400@3.2GHz, 2GB RAM @ 1000MHz) (hafo dlouhých souborů 100MB-2GB, při velkém to jede rychleji, při malých pomaleji), při kopírování z RAID5 na ten stejný RAID5 je rychlost mezi 15-30MB/s (stejný obsah).
Dále s vyšším zaplněním disku (1/2 oproti 9/10 zaplnění) je rychlost sníží o cca 20%.

[Fox!MURDER]

dobre, 6, 50 a 60 jsem si odpustit mohl, ale jsou tu tak nejak pro kompletnost tech bezne pouzivanejch, ten zbytek je uz doma relativne normalne pouzitelnej ... (proc RAID3 ano bylo zduvodneno nekde v mail archivech fbsd-geom, zkusim to najit ...)

1E je sice hezka hracka, ovsem nejak v ni nevidim ty vyhody, co ty, muzes mi prosim objasnit, kde se tam bere nejakej performance boost? tady bych zase docela rad videl nejaky benchmark ja (bez ironie - proste nechapu, kde by se tam cokoliv vzalo a neverim, ze se tam neco vezme)
- vsechny E-RAIDy mi prijdou spis jako technicky vychytavky a hracky, nez nejaky kdovijaky zazraky co se vykonu tyce ....

obecny specs sem pisu hlavne proto, ze tu vidim takovy misinformace jako, ze RAID1 zrychluje sekvencni cteni ... to by bylo proveditelne jen za predpokladu, ze o tom R1 OS vi a ze zamerne kvuli nemu dela hoooodne velky (radove vic jak MB) readahead

co se HW/SW reseni tyce tak samozrejme pri 20ti discich, bude HW radic v obrovske vyhode proti SW RAIDu, na druhou stranu, zase tu resime domaci segment kde se dostanem tak ke 4em diskum. priznavam ze jsem to hodne spatne napsal a hlavni pointa - totiz - radsi SW RAID v OS, nez HostRAID - z toho nejak neni pochopitelna, ale omluvte me ... byly skoro dve rano

ad. linux a scheduler - ano i scheduler se da hodne slusne konfigurovat ... staci napr u deadline prodlouzit trochu casy - pokud nepotrebujes realtime data - a za cenu trosku vetsich latenci pri cteni ziskas mnohem vyssi propustnost diky optimalizaci cteni

sel bych udelat benchmarky 4diskovyho RAID 5 Linux MD vs. 3Ware Escalade 9550SX ... ale neni cas mozna behem tejdne si s tim pohraju ...

Petrik: brzdu RAID3 pri normalnim provozu vidim leda v tom, ze pri cteni nemuzes (resp. muzes, ale zatezujes procesor) pouzit paritni disk pro cteni... zapisy na paritni disk mas stejne jako zapisy na ostatni disky - zapisuje se celej blok - a ano, pri dnesni konstrukci disku je jedno, jestli zapisujes blok 1KB, nebo 1MB

[jan555]

...

Když si najdeš chvíli na otestování, bude to super, už tenhle 3ware by měl bohatě stačit. (akorát je potřeba benchovat i/o operations, přímo DB, atd. a ne throughput nebo read, ale to je jasné)

My jsme tohle před cca 3-4 lety testovali na snad ideálním prostředí - nějakém malém IBM x-series s integrovaným řadičem s dedikovaným slotem právě na externí RAID (základní přídavná logika ServeRAID s bb cachí asi za 15K) a k tomu 2 sety stejných disků. (takže jsme efektivně eliminovali všechno mimo řadiče) Nepamatuji se už, co to bylo za server, řadič, disky ani Linux, výsledky jsem nearchivoval, takže to není žádný report, spíš jen pro zajímavost. Díky tomu, že jsme měli vlastní lab pro generování multi-user loadu, tak jsme viděli rozdíly opravdu velmi snadno.

Ad ten 1E level - on má různé implementace a např. Adaptec je konzervativní a gain tam moc není (a hlavní výhodou je tak možnost lichého i sudého počtu disků), naopak třeba na IBMce je díky principu zápisu a hlavně čtení možné dosáhnout read performance v úrovni level 0. Nechci to tu sáhodlouze rozepisovat, snadno popis najdeš. S hodně disky, dobrým řadičem a nízkými požadavky na bezpečnost je fakt super výkonný 1E0 (stripe 1E), pokud bys měl řadič a možnost, tak to pro zajímavost zkus. Jinak 1E a 1E0 jsou opravdu dost specifické levely, ne tak 5EE, ten kdo může, tak by měl používat místo level 5 - stejně disků, stejně parity, stejná bezpečnost, vyšší výkon. (jen ho moc řadičů imho ještě pořád neumí)

Ad RAID3 - nerozumím moc té vaší diskuzi ... RAID3 byl odjakživa specifický tím, že je to BYTE-LEVEL. Díky tomu měl také odjakživa nic moc read, slabý write a vyloženě tragický random write a rebuild (a obecně vůbec random operace). To je taky důvod, proč se dávno nepoužívá, tohle co popisujete by imho odpovídalo specifikaci RAID4, která byla dřív než pořádně začala spláchnutá level 5. Máte opravdu v Linuxu něco, co se jmenuje RAID3 a funguje to jinak?

[Petrik]

Sorry za OT, mozna by nebylo spatne udelat novy thread, myslim ze to je docela zajimave tema.

http://www.chemistry.wustl.edu/~gelb/castle_raid.html Tady mas namatkou jeden priklad, kdy je linuxovy MD RAID rychlejsi nez HW 3ware radic a nekdy dokonce o hodne. Ber v potaz, ze to platilo v roce 2004 a MD RAID se od te doby dost zmenil a zlepsil.
Nechci samozrejmne tvrdit, ze kazdy HW RAID je horsi nez MD, u velmi drahych radicu to tak s nejvetsi pravdepodobnosti nebude, ale na tom mojim tvrzeni, ze MD RAID nema zadne uzke hrdlo, si docela stojim. Trochu to rozeberu:
Jediny a zasadni rozdil mezi zatezi "hlavnich cest" u MD a HW RAIDu je v tom, ze u HW RAIDu system posila a cte data z jedineho blokoveho zarizeni (ten HW radic), kdezto u MD a SW RAIDu obecne musi zapisovat na vice zarizeni = disku ktere tvori to pole. U RAIDu 1 to znamena presne N-nasobnou zatez systemu, u RAIDu-0 je rozdil 0 a u RAIDu 5 je rozdil 1/N, protoze musi navic zapisovat paritu, coz normalne dela az radic + samozrejmne paritu pocita. Kdyz si ale uvedomis, ze procesor za 1500 bez dane (A64 X2 3800+) zvladne pocitat paritu (pomoci SSE2) rychlosti 6GBps na jedno jadro a ze zatez systemu pri cteni z RAIDu5 rychlosti 200MBps je cca 10-30%, tak sam uznas, ze se stale z vetsi casti flaka. Navic, architektura dnesnich PC, kdy jsou SATA radice pripojene pres velmi rychlou PCI-Express, ktera navic funguje stejne jako ethernetovy switch, tedy non-blocking architektura, zvlada takoveto prenosy levou zadni a je uplne jedno, zda je do toho zatizena treba i sitovka (rovnez pres PCI-E). Pokud tedy hovoris o radicich za 10tis a vic, musis u MD RAIDu uvazovat min Quad-core procesory, jejichz vytizeni bude i pri 400MBps zapisu do MD raidu skutecne zanedbatelne. Rozhodne ale existuji nasazeni, kdy i toto reletivne male vytizeni navic je problem a kdy se skutecne vyplati koupe draheho HW radice. Me osobne jako nejvetsi vyhoda HW radicu pripada spise to, ze maji zalozni baterii pro svou cache a pri vypadku napajeni jsou schopne data z cache na disky po obnoveni napajeni zapsat. toto MD RAIDu jaksi nidky umet nebude, bohuzel.
Me to pripada dost podobne jako v sitich, kdy oproti velmi sofistikovanym, ale drahym resenim jako napr. ATM vyhral jednoduchy a hloupy, ale velmi rychly ethernet. Vyhral hrubou silou, kdy veci jako QoS nechava na SW a sam neumi temer nic, ale to "neumi nic" provadi velmi rychle a levne. Dnesni HW se SATA a PCI-E a hlavne vicejadrovymi CPU (a hypertransportem) je pro SW RAIDy jako delany, jelikoz ma velmi rychle sbernice (oproti rychlosti disku) ktere se vzajemne neblokuji (jako napr. PCI nebo IDE), takze pokud nemluvime o entreprise nasazeni, vyplati se IMHO misto draheho radice koupit o to vykonnejsi HW a nasadit MD RAID. To plati samozrejmne pouze na UNIXu, na woknech bych se neco takobeho nidky neodvazil.


2Fox:
Another hit to write performance comes from the dedicated parity drive used in certain striping with parity implementations (in particular, RAID levels 3 and 4). Since only one drive contains parity information, every write must write to this drive, turning it into a performance bottleneck. Under implementations with distributed parity, like RAID 5, all drives contain data and parity information, so there is no single bottleneck drive; the overheads mentioned just above still apply though.

Ne, to nemyslím. Moje chyba v zobecnění (a zřejmě také v tom, že se chci alespoň jakž takž udržet subjectu).


Tady by sis koledoval o flame ty ... (ale nebude, to není moje) Proto, co se tobě nelíbilo na tom, co jsem napsal, je jednoduché vysvětlení (viz výše) a není to záměrná dezinformace, což není případ téhle citace. Teoreticky je skutečně možné leccos, prakticky už je to horší. Nevím o tom, že by i zcela standardní IOP321 měl pro svůj účel slabý výkon a to je schopen obsluhovat pole s řádově větším počtem disků než můžeš na mobo kdy mít (a přitom má např. peak i/o spotřebu 1W). Pokud bychom se také bavili o procesoru jako slabším článku u čistě SW RAIDu, bude to především kvůli základním principům - např. nutnosti multi-překladu nebo nutnosti využívání zbytečně složité a nevyhovující architektury CPU. Ale to je snad jasné, proč dál asi může být SW RAID rychlejší jen teoreticky? Externí řadič profituje z vlastního procesoru (a věcí s tím spojených), u SW řadiče instrukce a data z portů na procesor levitují, nebo jak se tam dostanou? Nepotřebují a nevytěžují náhodou defacto kompletní hlavní cesty? Neznamená to náhodou latence, zátěž a omezení všeho ostatního? Ještě ti přijde, že SW řadič nemá žádné úzké hrdlo? Že je to zcela plnohodnotná alternativa?

Skutečně rád si přečtu (nemyšleno ironicky) nějaké materiály, kde je natestováno, že je SW RAID (samozřejmě v Linuxu) výkonnější než dedikovaný řadič a může tam být i vysvětleno, proč i Linuxové top-class enterprise servery jedou na dedikovaných FC řadičích s gigabyty cachí, proč nevím o žádném benchi, kde by zaznamenal SW řadič rekordy, atd. Zcela pochopím, že pokud sám provozuješ typicky file-server, že je to zcela dostačující a rozdíly nejsou zásadní, u většiny ostatních rolí bych si o tom dovolil zvesela pochybovat.