2xRaptor36 v RAID0 @ Silicon Image 3112

[Dr4k3]

(Zpětně upraveno)

Jelikož se objevily na Storagereview a Anandtech nové testy, které ukazovali, že raid0 nemá praktický význam, chtěl jsem vědět, co je na tom pravdy. Protože zastávám názor, že rychlost disku ocení člověk teprve když na něj musí dlouho čekat, použil jsem jako test kopírování velkých adresářů s malými soubory, což je jedna z věcí, které dají disku zabrat a uživatel si může dát zatím kafíčko.

Pozor, uvedené výsledky se odvíjejí od faktu, že sil3112 je jeden z mála řadičů, které umí ukázat rychlost raid0 i u jiných věcí než u práce s gigabajtovými soubory.

Jak se testovalo:
Na jednom disku byla čerstvá instalace windows s několikadenním browsením po netu, tzn plný Temporary Internet Files.
Vždy jsem nastavil disk, vytvořil na něm dvě partišny o velikosti 20 nebo 40 GB a zbytek, zkopíroval na první z nich adresáře:
* Documents and Settings
- 98MB, 6400 souborů, většina souborů malinkatých, 0.5-4 KB, pár zipů které to vytáhnou na průměrný 15KB/soubor
* Program Files
- 100MB, 1400 souborů
* Windows
- 1.06GB, 8800 souborů

Následoval reboot a měřené kopírování pomocí Salamanderu na druhou partišnu.
Výsledky (druhý údaj udává velikost první partišny, vyjadřuje jak daleko se data kopírují; HR0=sil3112 raid0, ss=stripe size, SR0=dynamic disc striped volume):

kopírování souborů:
1x Raptor, 20GB - 240 s
2x Raptor SR0, 20GB - 101 s
2x Raptor SR0, 40GB - 103 s
2x Raptor HR0 4k ss, 40GB - 196 s
2x Raptor HR0 16k ss, 40GB - 182 s
2x Raptor HR0 128k ss, 40GB - 103 s

Je zajímavé, že kopírování Barracuda 7200.7 -> IxRaptor trvá déle než těch nejlepších 103 vteřin, ale nevím teď přesně kolik, nemám u sebe poznámky. Zjevně tady hraje už zapracoval větší acces time té Barracudy.

Pak jsem zkusil boot win do doby než přestane načítat:
1x Raptor - 20+-1 s
2x Raptor HR0 128k ss - 19+-1 s
Tzn žádný významný nárůst, v souladu s všeobecným povědomím.

Takže jak je vidět, RAID 0 může opravdu pomoct v kritických chvílích, kdy vše stojí na HDD.
V průběžném načítání jednotlivých souborů a stránek paměti z pagefile nebo load programů se síla RAID 0 neprojeví, úzké hrdlo je někde jinde - CPU, FSB, paměť, takže nás tady výkon disku ani moc nezajímá.

<flame>
Testy zvolené Storagereview (64k ss !! často File Server pattern apod) o výkonu na osobním PC řeknou fatk hodně, zvláště když vezmeme v úvahu časové rozložení testované zátěže z celého sezení. Mě zajímají jen kritické chvilky.

Stejně tak Anandtech zvolil syntetické testy, které mají testují výkon disku na operacích jako práce v office. Koho zajímá výkon hdd u office aplikací, když jsou načtené během půl vteřiny a zbytek života si sedí v ramce, to by mě fakt zajímalo.
</flame>

Jediné, co mě vážně mrzí, je fakt, že z SR0 se nedá bootovat (když jste šikovní, můžete tam ale přesunout PF a D&S). Při kopírování dělal SR0 nejlepší dojem co se týče cvrlikání disků - jemné, netrhané, plynulé)
Dále nedoporučuji namíchat dva dynamické disky tak, že by byl na jednom simple volume s windows, na druhém stejně velký tmp a zbytek kapacity striped volume s PF a D&S, subjektivně se mi to zdálo relativně pomalé.

Výhoda HR0 může pro někoho být cca 1.4-1.9x rychlejší hibernace. (závisí na okamžitém stavu paměti)
Pokud už dva stejné disky nemáte, bude to samozřejmě o jeden disk dražší (navíc u disků většinou platí, že cena dvou malých je věší než cena jednoho velkého).
V případě havárie přijdete o data z celého pole a z té zdravé půlky nic nevytáhnete, takže bych tam nedával 4 roky staré IBMko


Kdyby někoho zajímala základní konfigurace PC, tak EP-8RDA3+ (onboard Silicon Image 3112 připojený na PCI), Barton@2200MHz, 1GB RAM @ 400MHz FSB.[/i]

[MaWa]

jelikož se objevily na Storagereview a Anandtech nové testy, které ukazovali, že raid0 nemá praktický význam, musel jsem se přesvědčit o opaku sám.

RAID 0 nemá praktický význam při nějakém normálním použití PC (za což nepovažuji kopírování dat z oddílu na oddíl, což ty jsi vzal jako nejdůležitější součást tvé "obhajoby" RAID nuly).

jak moc byly ty tvoje testy reálný ? jak jsi zajistil, aby soubory byly stále na stejných místech ? tohle jsou pro někoho detaily, ale ve skutečnosti brutálně ovlivňují výkon disku. jak často se kopírují soubory mezi oddíly ? ano, pokud máš RAID 0 na toto, tak se to pak vyplatí...i když tvoje výsledky testů jsou více než zajímavé
přečti si toto... http://forum.pctuning.cz/viewtopic.php?t=12100 (obzvláště řádek 24 a dále). zamysli se nad tím, co se tam píše. zamysli se nad tim, jak funguje RAID 0. zamysli se nad tim, co je nejpomalejší část disku...a pokud toto všechno uděláš a vyjde ti, že RAID 0 se hodí na typické domácí PC (a 99% uživatelů, kteří třeba toto budou číst a budou tvrdit..."ale já grabuju video a zároveň poslouchám mp3ku a ještě píšu ve wordu - to už neni domácí PC" - ale je ), tak kontaktuj doktora Chocholouška.

klady RAID 0:

boot stejně dlouhý...protože do toho musíš započítat i inicializaci RAIDu, což je většinou pávě těch 5 sekund, které pak uštříš načítáním OS...takže nula od nuly pojde.
další neznám...jakákoliv jiná akce na domácím PC negeneruje takový I/O depth natoř chunk size, aby se RAID 0 vůbec mohl projevit. načítání her, programů, grabování do DivX...výkon bude stejnej. nebo do 5%.

zápory RAID0:
odejde jeden, odejdou oba.
2xvíc money (hlavní problém)
problémy s cachingem, ovladači a mnohými dalšími věcmi...

resume: dvojnásobná cena, 5% výkonu navíc (a to asi přehánim). pokud to někomu za to stojí a chce se předvádět s výsledky HD TAchu a Srandy, proč ne...jsou to jeho peníze. ale tvrdit, že RAID 0 má praktický výkonnostní význam (to tady tvrdíš ty) je prostě blbost...

jo a ještě něco...prosím, příště než se začneš navážet do SR testů (a obecně, než se do někoho a nebo do něčeho začneš navážet), zjisti si nejdřív fakta.... abys pak nevypadal jako *****
nikde na SR se totiž netvrdí, že IOMEter je na domácí PC...obzvláště, když tam píšou File Server Pattern...na home use tam maj IPEAK...

[Dr4k3]

-Kopírování souborů je jedna z věcí, u kterých si člověk povzdychne "proč je to sakra tak pomalé".
-Myslím že reálnější test než přímé měření požadované operace být už nemůže, nebo se pletu?
-Tím, že jsem je vytvářel pořád stejným způsobem... kopírováním na prázdnou partition.
Kopírování mezi oddíly zajistí to, aby se soubory kopírovaly dál než těsně vedle (i když kopírování v rámci volume dělá podobnou zátěž). Kopírování malých souborů v rámci disku je vynikající test jeho obecné rychlosti.

přečti si toto... http://forum.pctuning.cz/viewtopic.php?t=12100 (obzvláště řádek 24 a dále). zamysli se nad tím, co se tam píše. zamysli se nad tim, jak funguje RAID 0. zamysli se nad tim, co je nejpomalejší část disku...a pokud toto všechno uděláš a vyjde ti, že RAID 0 se hodí na typické domácí PC (a 99% uživatelů, kteří třeba toto budou číst a budou tvrdit..."ale já grabuju video a zároveň poslouchám mp3ku a ještě píšu ve wordu - to už neni domácí PC" - ale je ), tak kontaktuj doktora Chocholouška.

Nepíše se tam nic nového, samozřejmě. Grabování videa je jedna z věcí, kde se rychlý disk hodí - jeden disk zásobování datovým tokem surového RGB prostě nestíhá, že pane Karfík.

Klady RAID0:
Nevím co chceš na raidu inicializovat, bios řadiče tě zdrží i když tam máš jenom single disky.
Je zajímavé, že kopírování souborů tradičním stylem probíhá "soubor přečíst - soubor zapsat - další soubor", což je u malých souborů na acces time náročná aplikace s I/O queue depth 1, jestli se nepletu, a RAID 0 to zrychlí více než 2x.
Tisk velkých rastrů, hledání souborů /obsahu, načítání mailnewsového klienta s velkou databází zpráv, scanování ve velkém DPI (zvláště debilním originálním softem od HP), alt-tab z běžící hry do mailového klienta (mohutný swap paměti), grabování bez ztrátové komprese... mám pokračovat?
Taky nefragmentuješ zbytečně volné místo na několik disků, když je máš v jednom poli.

Zápory RAID0:
odejde jeden = mám problém
odejdou oba = mám problém
Nějak nevidím rozdíl. Důležitá data zálohuju, obnova systémové parition je otázka 15 minut, což je ve srovnání 30 dní reklamace u bývalé monimy nic. Kromě toho odchod disku do větčných lovišť je většinou způsoben dlouhodobým přehříváním, a že si zmenším MTBF@50°C ze 136 let na 68 mě moc nezajímá (ano vím že to znamená, že statisticky během 1 roku chcípne z 68 disků jeden).
Peníze - otázka není, jesli jeden disk, nebo dva v raidu - otázka je, jestli dva disky samotné nebo dva disky v RAID0 popř. jeden velký nebo dva malé v RAID0 (i když tady už do hry cena vstupuje kvůli různým poměrům Kč/GB) popř. dva disky v JBOD nebo dva disky v RAID0

Resume: cena není předmětem diskuze, rozčiluju se při čekání na počítač poloviční dobu a výsledkama z HDtachu se tak jako tak nepředvádím.
Nechci tvrdit, že se počítač nějak zázračně zrychlí, jen ukazuju, že v kritických chvílích nemusí uživatel čekat tak dlouho a jen tyhe kritické chvíle jsou práve ty okamžiky, když se člověk zamyslí nad tím, proč je to tak pomalé a kdy tu větší rychlost ocení.

V článku o tom, jestli mít R0 na domácím počítači uvádet link na testy s grafem IO/s vs. queue depth/drive count v operacích, které jsou ve skutečnoti roztahané do několikahodinového sezení a samy o sobě trvají několik desítek milisekund mi přijde zcestné. Mě zajímají okamžiky brutálního náporu na disky, které mají ale úplně jiné charakteristiky.

[MaWa]

-Kopírování souborů je jedna z věcí, u kterých si člověk povzdychne "proč je to sakra tak pomalé".

souhlas, vždyť píšu. pokud dvojnásobná cena někomu stojí za ušetřených pár sekund při jedné specifické operaci (nebo několika málo), budiž...

-Myslím že reálnější test než přímé měření požadované operace být už nemůže, nebo se pletu?

jasně, ale jde o to, že ta operace je normálně požadována jednou za uherský rok. existují i mnohem častější věci...

-Tím, že jsem je vytvářel pořád stejným způsobem... kopírováním na prázdnou partition.

looooooooool...naivko. to si fakt myslíš, že se ty data kopírovala stále na stejné místo ? kéž by to bylo tak jednoduché...
btw jaký byl filesystem ? nepíšeš ani OS....

Kopírování mezi oddíly zajistí to, aby se soubory kopírovaly dál než těsně vedle (kopírování v rámci volume dělá podobnou zátěž).

četls ten odkaz co jsem napsal výše ? pokud ano, tak určitě už víš, že jen 18% seeků je dál, než "těsně vedle"...takže podobnost s reálným testem je čistě náhodná

Kopírování malých souborů v rámci disku je vynikající test jeho obecné rychlosti.

co si představuješ pod pojmem "obecná rychlost" ?

Nepíše se tam nic nového, samozřejmě. Grabování videa je jedna z věcí, kde se rychlý disk hodí - jeden disk zásobování datovým tokem surového RGB prostě nestíhá, že pane Karfík.

no nevim...ale jeden dnešní rychlý disk grabovat video stačí...

Nevím co chceš na raidu inicializovat, bios řadiče tě zdrží i když tam máš jenom single disky.

pokud tam máš sata tak ano...to máš pravdu.

Je zajímavé, že kopírování souborů tradičním stylem probíhá "soubor přečíst - soubor zapsat - další soubor", což je u malých souborů na acces time náročná aplikace s I/O queue depth 1, jestli se nepletu, a RAID 0 to zrychlí více než 2x.

jaká byla průměrná velikost těch souborů ? alespoň orientačně - kilobajty ? stovky kilobajtů ? megabajty ?

Tisk velkých rastrů, hledání souborů /obsahu, načítání mailnewsového klienta s velkou databází zpráv, scanování ve velkém DPI (zvláště debilním originálním softem od HP), alt-tab z běžící hry do mailového klienta (mohutný swap paměti), grabování bez ztrátové komprese... mám pokračovat?

rastry - to se dělá doma běžně, že jo ? (platí i pro některé věci níže)
hledání - tam ti to raid nezrychlí, resp. ne o tolik, o kolik si myslíš...
načítání - to samé. jedině že bys pravidelně defragmentoval.
scanování - a ram nestačí ?
alt tab - toto dělám běžně na systému win2k s 512mb ram a nějakého mohutného swapu jsem si nevšimnul ?!? nebylo by lepší investovat do ram, pokud je jí málo ?

Taky nefragmentuješ zbytečně volné místo na několik disků, když je máš v jednom poli.

teď jsem nepochopil pointu

Nějak nevidím rozdíl. Důležitá data zálohuju, obnova systémové parition je otázka 15 minut, což je ve srovnání 30 dní reklamace u bývalé monimy nic.

to je čistá statistika...že odejde jeden disk ze dvou je větší, než že odejde jeden disk. a data v (_'_) jsou tak jako tak. to je ten rozdíl.

Kromě toho odchod disku do větčných lovišť je většinou způsoben dlouhodobým přehříváním, a že si zmenším MTBF@50°C ze 136 let na 68 mě moc nezajímá (ano vím že to znamená, že statisticky během 1 roku chcípne z 68 disků jeden).

první část - není pravda. naprostá většina disků odejde vadou materiálu, která nebyla odhalena při výrobě. a teplota může být jaká chce...
druhá část - MTBF znamená trochu něco jiného...

Peníze - otázka není, jesli jeden disk, nebo dva v raidu - otázka je, jestli dva disky samotné nebo dva disky v RAID0 popř. jeden velký nebo dva malé v RAID0 (i když tady už do hry cena vstupuje kvůli různým poměrům Kč/GB) popř. dva disky v JBOD nebo dva disky v RAID0

nejlepší je jeden disk na OS, druhý na data + swap...a omezit na minimální možnou kapacitu.

Resume: cena není předmětem diskuze, rozčiluju se při čekání na počítač poloviční dobu a výsledkama z HDtachu se tak jako tak nepředvádím.

cena je vždy předmětem diskuse, obzvláště v tomto státě, bohužel.

V článku o tom, jestli mít R0 na domácím počítači uvádet link na testy s grafem IO/s vs. queue depth/drive count v operacích, které jsou ve skutečnoti roztahané do několikahodinového sezení a samy o sobě trvají několik desítek milisekund mi přijde zcestné. Mě zajímají okamžiky brutálního náporu na disky, které mají ale úplně jiné charakteristiky.

ty operace na SR uváděné jsou realita...proto asi tam jsou, že....
ad brutální nápor na disky. doufám, že se shodneme na tom, že RAID 0 se vyplatí jen ve dvou případech:

1) I/O depth větší než 1 a zároveň data request number 2 je na jiném disku než data request nr. 1.
šance, že platí druhé uvedené je dejme tomu 50%. šance, že platí první uvedené je cca 20%. výsledek - 10%.
2) data request je dostatečně (je dostatečně STR-like), že se projeví téměř dvojnásobná rychlost RAID0 pole při čtení/zápisu. první platit na OS od microsoftu nemůže - tam jsou requesty trhány na 64kB kvuli responsiveness. druhé platí v cca 15% případů.

potom výsledek se prostě nevyplatí. za tu cenu. a tu nelze ignorovat. navíc nelze ignorovat ani to, jak často se "brutální nápor na disky" koná...

já s tebou v zásadě souhlasim, ano, existují některé silně specifické operace,kde se ti to raidem zrychlí i více než o těch 10%, ale musim trvat na tom, že prostě 99.9% uživatelů ten raid vůbec nevyužije. takže to, co je napsáno na SR a na anandtechu je prostě správně...
než aby se investovalo do raidu, kupte si radši další ram a vypněte pagefile...

[Locke]

Jeden z vas tady mluvi o voze a druhy o koze. Faktem je, ze pokud clovek pouziva aplikace, ktere hodne pracuji s diskem, temer bez ohledu na velikost RAM (napriklad vsemozna 3d studia, CADy, a co ja vim jeste), nebo se na compu striha video, tak proste raid tomu znatelne pomuze a neni co resit.

Ovsem na beznem "kancelarskem" compu kde se jede word, tu a tam nejaka ta hra + filmy, to absolutne ztraci smysl, zase na druhou stanu kdyz uz clovek ma v compu ty dva disky, tak proc to nezraidovat, dneska to umi pomalu kazda deska a jsou chvile, kdy vetsi rychlost potesi, i kdyz jich logicky na takovem compu moc nebude.

[Dr4k3]

No, myslím že když po rebootu vytvoříš novou partition, zformátuješ jí na NTFS a čerstvě na ní něco nakopíruješ, pak jí smažeš, rebootneš, vytvoříš, naformátuješ a zkopíruješ to tam znova (ze stejného místa), bude to stejné. S dostatečnou přesností. OS winXP, promiň.

četls ten odkaz co jsem napsal výše ? pokud ano, tak určitě už víš, že jen 18% seeků je dál, než "těsně vedle"..

Vzhledem k tomu, že doba přeskoku hlaviček o jednu stopu je srovnatelná s přeskokem o gigabajty, je to fakt celkem jedno

co si představuješ pod pojmem "obecná rychlost" ?

něco jako kombinaci jednotlivých teoretických údajů v relevantním reálném nasazení

no nevim...ale jeden dnešní rychlý disk grabovat video stačí...

teoreticky ano, prakticky tam není dostatečná rezerva, takže to občas kernel nestihne a dropne se pár framů

ad velikost souborů - koukni se k sobě

načítání - jelikož ty mailové úložiště jsou dělané jako databáze s ohledem na trvalý růst, jde např. o 60MB úsek v jednom fragmentu

scanování - A4@2400dpi má cca 2GB RGB s 8-bit na kanál. Když dáš 9600 dpi a 16 bitů na kanál, jdeš do háje -- to je samozřejmě určeno na fotky a negativy, ale stejně

alt tab - hrál jsi někdy Morrowind? Sim City 4? ) Na pozadí puštěný Photoshop, Outlook Express s velkými diskuzemi a stahování z ftp? s 512 MB je to docela peklo, to mi věř. Teď mám 1GB.

vysvětlím ohledně místa - když máš pět disků, na každém 400MB volného místa, už tam ISO cdčka steně nenacpeš a musel bys přesouvat data. S raidem nebo JBOD máš najednou 2GB ihned použitelného místa. Není to moc silný argumet, uznávám.

Pravděpodobnost, že jeden ze dvou disků chcípne nezávisí na faktu, jestli jsou v raidu nebo ne.

první část - není pravda. naprostá většina disků odejde vadou materiálu, která nebyla odhalena při výrobě. a teplota může být jaká chce...
druhá část - MTBF znamená trochu něco jiného...

Hmm, moje zkušenosti hovoří o opaku, možná se při větším tepelném namáhání vlivem dilatace vady materiálu častěji projevují, nevím. Ad MTBF - konkrétnější být nemůžeš?

nejlepší je jeden disk na OS, druhý na data + swap...a omezit na minimální možnou kapacitu.

Stejně na disk s OS dáš i data, neznám člověka, který by si nechal zahálet 40 GB volného místa vedle systému.

ty operace na SR uváděné jsou realita...proto asi tam jsou, že....
ad brutální nápor na disky. doufám, že se shodneme na tom, že RAID 0 se vyplatí jen ve dvou případech:
1) I/O depth větší než 1 a zároveň data request number 2 je na jiném disku než data request nr. 1.
šance, že platí druhé uvedené je dejme tomu 50%. šance, že platí první uvedené je cca 20%. výsledek - 10%.
2) data request je dostatečně (je dostatečně STR-like), že se projeví téměř dvojnásobná rychlost RAID0 pole při čtení/zápisu. první platit na OS od microsoftu nemůže - tam jsou requesty trhány na 64kB kvuli responsiveness. druhé platí v cca 15% případů.
potom výsledek se prostě nevyplatí. za tu cenu. a tu nelze ignorovat. navíc nelze ignorovat ani to, jak často se "brutální nápor na disky" koná...

ad SR - realita ano, ale jsou to operace zaznamenané za několik hodin provozu, kdy netvoří svojí vlastní dobou ani procento doby záznamu. Takže i kdybys ty operace provedl intantně, na výsledku se to projeví nepatrně. Jde povětšinou o různé načítání a přednačítání na pozadí, občas spuštění programů, swapy na pozadí, záznamy do logů, změny registrů atd. Práce s velkými daty tam pak tvoří v IO operacích jen malé procento, přestože jde ve skutečnoti o kapacitně velké objemy. Výsledkem je, že v grafu IO/s nehrají tyhle mohutné datové přenosy moc velkou roli, i když svým významem by měly, protože na ně se nejvíce čeká.

v bodu 1) mi nezbývá než dodat, že je navíc třeba, aby velikost requestu nepřesáhla stripe size. Ty %-odhady jsou ovšem čistě teoretické.
ohledně bodu 2.2) - ale těch diskutabilních 10% jsou právě většinou mnou zmiňovaté okamžiky načítání větších dat. Kromě toho když je první request větší než stripe size, efektivně se ti zdvojnásobí disková cache jednoho místa (16 MB už není k zahození), což má efekt i na malé náhodné requesty relativně daleko za původním

BTW za vypnutou pagefile by tě spousta znalců uškrtila

Musím s tebou souhlasit, že RAM je základ, a musím si přestat o sobě myslet, že jsem normální uživatel.

Nějak se nám ty posty prodlužujou, ale padají z toho zajímavé výsledky

[MaWa]

No, myslím že když po rebootu vytvoříš novou partition, zformátuješ jí na NTFS a čerstvě na ní něco nakopíruješ, pak jí smažeš, rebootneš, vytvoříš, naformátuješ a zkopíruješ to tam znova (ze stejného místa), bude to stejné. S dostatečnou přesností. OS winXP, promiň.

s dostatečnou přesností celkem jo. ale někdy wokna a driver na ntfs (a caching) trochu "ujede" a nakopíruje to někam uplně jinam ...takže měls to ještě před dalšim testingem projet třeba jen inicializací speeddisku od Nortona - ten ti přesně řekne, kde kterej soubor je...a můžeš alespoň zjistit, jestli se to nenakopírovalo někam uplně jinam než v předcházejícím testu.

Vzhledem k tomu, že doba přeskoku hlaviček o jednu stopu je srovnatelná s přeskokem o gigabajty, je to fakt celkem jedno

to jako myslíš vážně ?

něco jako kombinaci jednotlivých teoretických údajů v relevantním reálném nasazení

jasně, ale tim jsi otestoval rychlost jen v tom jednom relevantím nasazení. které se děje jednou za rok třeba. navíc to kopírování malejch souborů by vypadalo uplně jinak třeba s highpoint řadičem...tam by to možná bylo pomalejší než single disk a 100%ně pomalejší než read z jednoho disku a write na druhý disk. můžeš být rád, že máš Sil, to je dneska po intelu ich5/6r a via vt8237 nejlepší řadič s nejlepšíma driverama. kdybys měl řadič typu highpoint, splakal bys při tomhle testu nad výsledkem. takže to, že zrovna tvůj raid 0 řadič se chová takhle dobře je dost celkem náhoda a bohužel se to nedá říct o všech řadičích.

teoreticky ano, prakticky tam není dostatečná rezerva, takže to občas kernel nestihne a dropne se pár framů

dělal jsem to prakticky...a žádný frame nikdy nevypadl. win2k, 512mb ram, write na prázdnej hitachi 7k250 160gb 8mb cache. ale to je asi relativní.

ad velikost souborů - koukni se k sobě

už jsem napsal výše...ovladače.

načítání - jelikož ty mailové úložiště jsou dělané jako databáze s ohledem na trvalý růst, jde např. o 60MB úsek v jednom fragmentu
scanování - A4@2400dpi má cca 2GB RGB s 8-bit na kanál. Když dáš 9600 dpi a 16 bitů na kanál, jdeš do háje -- to je samozřejmě určeno na fotky a negativy, ale stejně

no pokud jsou v jednom fragmentu, tak to jo...ale to se ani trochu neblíží k "domácímu" použití, které ty na začátku napadáš, že SR v tom nemají pravdu...

alt tab - hrál jsi někdy Morrowind? Sim City 4? ) Na pozadí puštěný Photoshop, Outlook Express s velkými diskuzemi a stahování z ftp? s 512 MB je to docela peklo, to mi věř. Teď mám 1GB.

hraju třeba ut2k4, na liště outlook, trillian a spuštěný dc++, antivirák, firewall, mozilla...a alt tab mi nedělá problémy. ono možná to bude proto, že jak jsem psal, mám swap na jinym disku než OS, a hned na začátku. takže celý disk se v tu chvíli může starat jen o swap a druhý disk jen o OS/game data...každý na svý kšandě of course...a jede to líp než na raidu...páč tam by se ty disky musely useekovat....chvili načíst něco z os, pak swap atd atd atd...

vysvětlím ohledně místa - když máš pět disků, na každém 400MB volného místa, už tam ISO cdčka steně nenacpeš a musel bys přesouvat data. S raidem nebo JBOD máš najednou 2GB ihned použitelného místa. Není to moc silný argumet, uznávám.

tak na slabé argumenty to je 1:1

Pravděpodobnost, že jeden ze dvou disků chcípne nezávisí na faktu, jestli jsou v raidu nebo ne.

to jsem netrvdil...ale odejde jeden - odejdou všechny data.

Hmm, moje zkušenosti hovoří o opaku, možná se při větším tepelném namáhání vlivem dilatace vady materiálu častěji projevují, nevím. Ad MTBF - konkrétnější být nemůžeš?

mtbf se počítá tak, že uděláš třeba svazek 50ti disků a necháš je běžet. a pokud první disk umře např. po 60 dnech, tak je MTBF počítáno jako

početdiskůxčaskterýběželybeztohoabynějakýo dešel...v tomto případě 50x24x60...nějakých necelých 80 000 MTBF. pak se to ještě dá ukrátit tím, že se vystavují extrémní zátěži/teplu. pak je ten multiplikátor třeba 3x. takže třeba pokud budeme mít 200 disků, pojedou 14 dní IOMeter bez přestání a budou v zavřenym case bez větráků, kde se bude smažit prescott (takže teplota v case bude 40C, teplota disku přes 50C), tak by MTBF mohla být např. 3x200x24x15x3...650 000 MTBF...

Stejně na disk s OS dáš i data, neznám člověka, který by si nechal zahálet 40 GB volného místa vedle systému.

jasně, ale o to nejde. k těm datům přistupovat nebudeš, když bude extrémní zátěž na první disk. takže ti tam "vadit" v tu chvíli nebudou.

ad SR - realita ano, ale jsou to operace zaznamenané za několik hodin provozu, kdy netvoří svojí vlastní dobou ani procento doby záznamu. Takže i kdybys ty operace provedl intantně, na výsledku se to projeví nepatrně. Jde povětšinou o různé načítání a přednačítání na pozadí, občas spuštění programů, swapy na pozadí, záznamy do logů, změny registrů atd. Práce s velkými daty tam pak tvoří v IO operacích jen malé procento, přestože jde ve skutečnoti o kapacitně velké objemy. Výsledkem je, že v grafu IO/s nehrají tyhle mohutné datové přenosy moc velkou roli, i když svým významem by měly, protože na ně se nejvíce čeká.

pokud se nepletu tak na SR mají i highend diskmark a gamemark...v prvním jmenovaném se myslim i něco s videem dělá. taky v tomhle testu je pak rozdíl nad 10% u raidu...
tady jde o systematiku měření. měřit jen to, co říkáš ty, ale s vědomím, že se to děje jednou za delší dobu ? nebo měřit to, jak se na PC skutečně pracuje/hraje/doplňtedlepotřeby ?

v bodu 1) mi nezbývá než dodat, že je navíc třeba, aby velikost requestu nepřesáhla stripe size. Ty %-odhady jsou ovšem čistě teoretické.

request nemůže být na widlích větší než 64kilo...takže proto máš u 128kb stripe takový nárůst v tom tvym kopírování ...a nikdo normální snad na doma (když už teda ten raid má) nemá stripe 32kb nebo méně...pokud to nemá na nějaké special operace a nemá to ověřené praxí.
ty % jsou čistě praktické

ohledně bodu 2.2) - ale těch diskutabilních 10% jsou právě většinou mnou zmiňovaté okamžiky načítání větších dat. Kromě toho když je první request větší než stripe size, efektivně se ti zdvojnásobí disková cache jednoho místa (16 MB už není k zahození), což má efekt i na malé náhodné requesty relativně daleko za původním

mmnt teď tě vůbec nechápu. na co je ti 2xvelká disková cache, když načítáš jeden request ? obzvláště daleko za minulým requestem ? vždyť šance, že by to mohlo bejt nacachovaný je tak jedna ku milionu !!! tam (a i všude jinde) je omezení doba přesunu té hlavy, ne nějaká cache !!! a tam ti raid fakt nepomůže.

BTW za vypnutou pagefile by tě spousta znalců uškrtila

tak si dej ten swap na ramdisk...swap budeš mít, ale vlastně ho mít nebudeš

Nějak se nám ty posty prodlužujou, ale padají z toho zajímavé výsledky

jo to jo...už dlouho jsem s někym nepokecal...

[Dr4k3]

to jako myslíš vážně ?

Read seek avg : 5.2
Full stroke : 10.2
Track-2-Track : 0.7
nejmenší stopa (track) by měla mít 614 sektorů, což dělá 307 KB
největší cirka dvojnásobek
seek přes dejme tomu 500KB je tedy 0.7ms
seek přes 15GB (cca 8000 krát větší vzdálenost) má 5.2ms
Tomu já říkám srovnatelné hodnoty.

jasně, ale tim jsi otestoval rychlost jen v tom jednom relevantím nasazení. které se děje jednou za rok třeba. navíc to kopírování malejch souborů by vypadalo uplně jinak třeba s highpoint řadičem...tam by to možná bylo pomalejší než single disk a 100%ně pomalejší než read z jednoho disku a write na druhý disk. můžeš být rád, že máš Sil, to je dneska po intelu ich5/6r a via vt8237 nejlepší řadič s nejlepšíma driverama. kdybys měl řadič typu highpoint, splakal bys při tomhle testu nad výsledkem. takže to, že zrovna tvůj raid 0 řadič se chová takhle dobře je dost celkem náhoda a bohužel se to nedá říct o všech řadičích.

Samozřejmě ale mají tyhle různé nasazení vztah vůči sobě, jistou korelaci výkonu tam najdeš. Jde jen o to, jak moc velkou a já myslím že dostatečně.
Ad řadič - tím ale přichází úplně jiná rovina diskuze o hodnověrnosti výsledků většiny testů, že? I těch na SR/AT.
BTW graf v HDTachu na tom sil3112 R0 poli nemá typickou sestupnou tendenci ale je to docela trhaná stálá křivka.

dělal jsem to prakticky...a žádný frame nikdy nevypadl. win2k, 512mb ram, write na prázdnej hitachi 7k250 160gb 8mb cache. ale to je asi relativní

.
Já to testoval na prázdném 2mb cache 60GB 180GXP, ntfs, winxp

no pokud jsou v jednom fragmentu, tak to jo...ale to se ani trochu neblíží k "domácímu" použití, které ty na začátku napadáš, že SR v tom nemají pravdu...

pošta je domácí použití. A nezapomínej, že ty největší lamičky si posílají největší maily (2MB příloha s ppt prezentací atd.)

hraju třeba ut2k4, na liště outlook, trillian a spuštěný dc++, antivirák, firewall, mozilla...a alt tab mi nedělá problémy. ono možná to bude proto, že jak jsem psal, mám swap na jinym disku než OS, a hned na začátku. takže celý disk se v tu chvíli může starat jen o swap a druhý disk jen o OS/game data...každý na svý kšandě of course...a jede to líp než na raidu...páč tam by se ty disky musely useekovat....chvili načíst něco z os, pak swap atd atd atd...

Nevím jak je UT2k4 náročné na paměť, ale Q3A taky alttabuju instantně
Ale zní to hezky, budu muset zkusit. Stačí sehnat druhý 180GXP 60GB, udělat s ním SR0 a dát tam pagefile

to jsem netrvdil...ale odejde jeden - odejdou všechny data.

hm, já to vnímám tak, že mám problém tak jako tak.... ale většina lidí by asi souhlasila s tebou

Ad MTBF ... čili zhruba to co jsem říkal, jen jsem to řekl málo statisticky

request nemůže být na widlích větší než 64kilo...takže proto máš u 128kb stripe takový nárůst v tom tvym kopírování ...a nikdo normální snad na doma (když už teda ten raid má) nemá stripe 32kb nebo méně...pokud to nemá na nějaké special operace a nemá to ověřené praxí.
ty % jsou čistě praktické

Nemůže být větší, ale to neznamená, že nemůže být roztažený přes dva stripy. Špatně jsem se vyjádřil. BTW na tom silu když dáš vytvořit pole automatiky, udělá ss=16KB Takže bych se ani nedivil kdyby to tak spousta lidí měla.

Navíc se do toho plete zarovnávání souborů v NTFS na 32KB (myslím) úseky (které se pak ignoruje když dochází místo) a ukládání miniaturních souborů přímo do MFT

mmnt teď tě vůbec nechápu. na co je ti 2xvelká disková cache, když načítáš jeden request ? obzvláště daleko za minulým requestem ? vždyť šance, že by to mohlo bejt nacachovaný je tak jedna ku milionu !!! tam (a i všude jinde) je omezení doba přesunu té hlavy, ne nějaká cache !!! a tam ti raid fakt nepomůže.

Na to, že když pošleš další request, je podle statistik velká šance, že bude blízko za prvním, potenciálně v cache. Ani jeden znás asi nezná přesně adaptivní algoritmus cachování který disky používají, ale věřím že při šanci na využití 1e-6 by na disk nikdo nedal pro tyto účely 8MB paměti

tak si dej ten swap na ramdisk...swap budeš mít, ale vlastně ho mít nebudeš

já jsem ovšem spíše příznivec malého pagefile někde na disku Dávat to do ramdisku mi přijde jako plýtvání pamětí, kterou může OS využít jako diskovou cache.

Spíš by to chtělo zjistit, jak nakombinovat Program Files, Games, Documents and Settings, Windows a pagefile na jednotlivé disky/pole např na dva nebo tři. Respektvie zjistit, co se používá s čím najednou a co ne tak moc. A jestli to má cenu zjišťovat.

[MaWa]

Read seek avg : 5.2
Full stroke : 10.2
Track-2-Track : 0.7
nejmenší stopa (track) by měla mít 614 sektorů, což dělá 307 KB
největší cirka dvojnásobek
seek přes dejme tomu 500KB je tedy 0.7ms
seek přes 15GB (cca 8000 krát větší vzdálenost) má 5.2ms
Tomu já říkám srovnatelné hodnoty.

no nevim...pokud má nějaká veličina minimální hodnotu 0.7, maximální hodnotu 15, tak mi teda potom hodnoty 1 a 5 nepřijdou jako "skoro stejné"...jiný by to bylo, kdyby minimum bylo 0 a max třeba 100...

Samozřejmě ale mají tyhle různé nasazení vztah vůči sobě, jistou korelaci výkonu tam najdeš. Jde jen o to, jak moc velkou a já myslím že dostatečně.

?!? jaká různá nasazení ?!?

Ad řadič - tím ale přichází úplně jiná rovina diskuze o hodnověrnosti výsledků většiny testů, že? I těch na SR/AT.

tak teď sis teda blbě naběhnul ...je vidět, že nevíš, co to je IPEAK. o anandtechu se nevyjadřuju, tam nevim jak se testuje, ale IPEAK na SR je vůči těmto věcem imunní (pokud se to explicitně nevypne)...a nejem vůči nim. jde prostě "až k disku", nezajímá ho nějaký pokaždý jiný caching woken, nezajímají ho ani drivery na řadič (igh-level drivery myslim) atd...

BTW graf v HDTachu na tom sil3112 R0 poli nemá typickou sestupnou tendenci ale je to docela trhaná stálá křivka.

nj protože seš omezenej PCI...a možná i SATAnem

Já to testoval na prázdném 2mb cache 60GB 180GXP, ntfs, winxp

tak to máš "smůlu"...tohle je jediný nedochůdče z rodiny 180gxp...a taky už neni nejnovější.

pošta je domácí použití. A nezapomínej, že ty největší lamičky si posílají největší maily (2MB příloha s ppt prezentací atd.)

jo, to sice jo, ale na 2MB příloze se teda RAID neprojeví ani náhodou. navíc - myslíš, že si wokna tu přílohu uloží do jednoho fragmentu ? ani omylem...hezky jí rozkouskuje = konečná pro raid 0, jakmile to má číst...

Nevím jak je UT2k4 náročné na paměť, ale Q3A taky alttabuju instantně
Ale zní to hezky, budu muset zkusit. Stačí sehnat druhý 180GXP 60GB, udělat s ním SR0 a dát tam pagefile

ut2k4 je poněkud novější než q3a...takže asi žere víc paměti. ale kolik, to netušim, nikdy jsem neměl potřebu to nějak zkoumat. je fakt, že to nehraju uplně na nejvyšší detaily, mam jenom gf4 ti4400 128mb, takže jedu na 1024*768 na vyšší střední detaily...což to taky může ovlivnit.

Ad MTBF ... čili zhruba to co jsem říkal, jen jsem to řekl málo statisticky

no...zhruba asi jo...ale četl jsem to po tobě třikrát a moc moudrej sem z toho nebyl, tak jsem napsal svojí variantu

Nemůže být větší, ale to neznamená, že nemůže být roztažený přes dva stripy. Špatně jsem se vyjádřil. BTW na tom silu když dáš vytvořit pole automatiky, udělá ss=16KB Takže bych se ani nedivil kdyby to tak spousta lidí měla.

velikost stripe - njn, když tomu lidi nerozuměj...

Navíc se do toho plete zarovnávání souborů v NTFS na 32KB (myslím) úseky (které se pak ignoruje když dochází místo) a ukládání miniaturních souborů přímo do MFT

zarovnávání na 32kb ?!? wtf ?

Na to, že když pošleš další request, je podle statistik velká šance, že bude blízko za prvním, potenciálně v cache. Ani jeden znás asi nezná přesně adaptivní algoritmus cachování který disky používají, ale věřím že při šanci na využití 1e-6 by na disk nikdo nedal pro tyto účely 8MB paměti

aha tak to jo...no já předpokládal, že když píšeš, že předcházející request byl "daleko", tak i ten následující bude zase "daleko" (prostě random, ne nějaká lokalizovaná pattern)...a tudíž bude impossible ho nacachovat
read cache v zásadě funguje tak, že disk načte sektor, který je requested, a pokud nemá nic dalšího na práci (což minimálně chvíli platí vždy), tak načte do zásoby i celej zbytek tý stopy...resp. nechá tam něco rezervu podle velikosti a tak...většinou tam nechá i kus předcházejících dat...ale v zásadě to funguje takto.

já jsem ovšem spíše příznivec malého pagefile někde na disku Dávat to do ramdisku mi přijde jako plýtvání pamětí, kterou může OS využít jako diskovou cache.

no když jde o výkon...tak neni co řešit. ale já osobně taky dávám přednost "hdd tuningu" a patlám se s tim, kde má bejt swap, kde os, kde data, jak velký clustery, na jaký kšandě, jaký oddíly...je to levnější a je to zábavnější

Spíš by to chtělo zjistit, jak nakombinovat Program Files, Games, Documents and Settings, Windows a pagefile na jednotlivé disky/pole např na dva nebo tři. Respektvie zjistit, co se používá s čím najednou a co ne tak moc. A jestli to má cenu zjišťovat.

obecně je nejlepší koupit dva disky s maximální možnou kapacitu na trhu (tzn dnes 7k400 400gb), na prvnim udělat ntfs oddíl s co nejmenší velikostí na os, dokumenty, programy a na druhym udělat ntfs oddíl o velikosti třeba 2gb a do něj nacpat swap a nastavit ho na pevnou velikost 2gb...a zdefragmentovat...
popř. pokud je to "mission critical" aplikace, tak koupit ještě třetí disk a dát tu aplikaci (+ její data) na třetí disk sólo
výhody tohoto jsou, že v zásadě je cena stejná jako u raidu, ale nemusíš se děsit jakou nastavit stripe, jestli bude řadič fungovat nebo se srát, a taky když odejde jeden disk tak ti neodejdou všechny data...

[Dr4k3]

různá použití.. ale to je jedno..

tak teď sis teda blbě naběhnul ...je vidět, že nevíš, co to je IPEAK. o anandtechu se nevyjadřuju, tam nevim jak se testuje, ale IPEAK na SR je vůči těmto věcem imunní (pokud se to explicitně nevypne)...a nejem vůči nim. jde prostě "až k disku", nezajímá ho nějaký pokaždý jiný caching woken, nezajímají ho ani drivery na řadič (igh-level drivery myslim) atd...

hmm, čili opravdu reálný test v reálných podmínkách, už chápu :-P

nj protože seš omezenej PCI...a možná i SATAnem

nn, myslím že to u jiných disků nedělá.. ještě se na to podívám

tak to máš "smůlu"...tohle je jediný nedochůdče z rodiny 180gxp...a taky už neni nejnovější.

jj, ale bohužel jsem neměl jiný.. je to už 2 roky co jsem ho dostal.

jo, to sice jo, ale na 2MB příloze se teda RAID neprojeví ani náhodou. navíc - myslíš, že si wokna tu přílohu uloží do jednoho fragmentu ? ani omylem...hezky jí rozkouskuje = konečná pro raid 0, jakmile to má číst...

Budu muset vymyslet způsob jak uměle fragmentovat soubor a pak otestovat jeho načtení do ramdisku. Snad budou stačit tři najednou kopírované ISO

ut2k4 je poněkud novější než q3a...takže asi žere víc paměti. ale kolik, to netušim, nikdy jsem neměl potřebu to nějak zkoumat. je fakt, že to nehraju uplně na nejvyšší detaily, mam jenom gf4 ti4400 128mb, takže jedu na 1024*768 na vyšší střední detaily...což to taky může ovlivnit.

Jo, Morrowind a SC4 jsou proslulé paměťovou náročností, kdyžtak se někoho zeptej

zarovnávání na 32kb ?!? wtf ?

hrozně blbě se to hledá, ale četl jsem sáhodlouhé pojednávání o problematice defragmentace NTFS a bylo to tam někde zmíněný. Něco jako že winAPI defragmentační funkce zarovnají malé soubory na nějaké úseky, nevím jestli to bylo zrovna 32k. Možná to byly 4 clustery.

obecně je nejlepší koupit dva disky s maximální možnou kapacitu na trhu (tzn dnes 7k400 400gb), na prvnim udělat ntfs oddíl s co nejmenší velikostí na os, dokumenty, programy a na druhym udělat ntfs oddíl o velikosti třeba 2gb a do něj nacpat swap a nastavit ho na pevnou velikost 2gb...a zdefragmentovat...
popř. pokud je to "mission critical" aplikace, tak koupit ještě třetí disk a dát tu aplikaci (+ její data) na třetí disk sólo
výhody tohoto jsou, že v zásadě je cena stejná jako u raidu, ale nemusíš se děsit jakou nastavit stripe, jestli bude řadič fungovat nebo se srát, a taky když odejde jeden disk tak ti neodejdou všechny data...

a pak že je moje řešení drahé

[MaWa]

hmm, čili opravdu reálný test v reálných podmínkách, už chápu :-P

pořád budeš rejpat co ?
když by to bylo ovlivněný cachingem atd, tak se ti to nelíbí, a když neni, tak se ti to taky nelíbí. uvědom si, že IPEAK se test zaměřený na disk. ne na řadiče atd. JEn na disky. a jediný způsob, jak exaktně určit, jestli je lepší disk A nebo disk B je podstrčit ty data přímo disku. bez cachingu kernelu, bez ovladačů, bez nějakýho driveru na filesystem.
samozřejmě - JEDNOU toto všechno proběhne, a to v prvním testování. prostě se na PC normálně pracuje a IPEAK všechny requesty loguje (detailně)- tzn zapracovává tam i ten caching apod. ale ten log se pak přehrává na dalších discích nízkoúrovňově, což je jediná možnost, jak nemít výsledky zkreslený.

hrozně blbě se to hledá, ale četl jsem sáhodlouhé pojednávání o problematice defragmentace NTFS a bylo to tam někde zmíněný. Něco jako že winAPI defragmentační funkce zarovnají malé soubory na nějaké úseky, nevím jestli to bylo zrovna 32k. Možná to byly 4 clustery.

no mě to s tim hledáním řikat nemusíš, moc dobře to znám sám...to většinou člověk někde něco přečte, pak za půl roku to potřebuje najít a upřesnit si, a pak probírá tunama odkazů, co jsou v bookmarks a hledá
jinak máš pravdu, jsou to 4 clustery...ale funguje to až od verze NTFS 5.0, afaik.

a pak že je moje řešení drahé

no já napsal ideální řešení. a tvoje řešení není ideální, takže nemusí být stejně drahé jako to moje
ale jsem si celkem jist, že pokud by se za stejné money mělo udělat buď raid 0 pole nebo muj setup, tak že to moje by bylo výkonnější. minimálně na každém obvyklém domácím/highendovém/game PC...

[Crus]

"nejlepší je jeden disk na OS, druhý na data + swap...a omezit na minimální možnou kapacitu."

Tim swapem myslis soubor pagefile.sys? Jak prosimte udelam aby se mi ukladal na jiny disk? A jak omezim minimální možnou kapacitu a na kolik? Diky

[Dr4k3]

Tim swapem myslis soubor pagefile.sys?

jistě

Jak prosimte udelam aby se mi ukladal na jiny disk? A jak omezim minimální možnou kapacitu a na kolik? Diky

winxp:
(win+break) nebo (pravým na tento počítač, vlastnosti) nebo (ovládací panely, systém),
potom karta upřesnit, v oblasti výkon tlačítko nastavení, karta upřesnit, tlačítko změnit. Po provedení změn na každém disku musíš zmáčknout nastavit, jinak se to zruší.

win2k je podobně, jenom se tam některý tlačíka jmenujou trochu jinak..

[Richardus]

Uvaha nad vyhodami

Ked nemas raid a odide ti disk = data v **** a si bez disku.
Ked mas raid a odide ti jeden disk = data v **** , ale druhy disk mozes dalej pouzivat.
Ked mas raid a odidu ti dva disky = data v **** , mas sakra smolu , ale velmi nepravdepodobne.

[Rainbow]

Najlepsie je mat aspon 2 disky bez RAIDu. Najdolezitejsie veci mozes skopirovat na oba. Mal som 3 disky, ale jeden uz zacal odchadzat a dalsi tichy SCSI nemam...

[Louis]

když uvažuju o tom setupu by Wallace: na druhým disku SWAP na zvláštní partišně (např. jak píšeš 2GB) - je nutná samostatná partition - není to zbytečné - nestačí, že je na druhém disku? Jo a dá se nějak nastavit "neviditelnost" partition - aby se normálně používala, ale nebyla defaultně přístupná - štve mě, když mám 4 partition a zrovna nevím, kde jsou soubory, který chci... takže bych skoval partition se systémem a se swapem jde to?

[MaWa]

na začátku proto, že disk je tam nejrychlejší. a četl jsem nějaký pokec od inženýra od MicroSoftu, že se k swapu většinou přistupuje sekvenčně...
za druhé proto, že když bude mezi datama, těžko mu nařídíš, aby byl na začátku disku, a bude fragmentovanej...
můžeš tomu maximálně nepřiřadit písmenko (ve win2k/xp/2k3)...jenže to se k tomu swapu pak zase nedostane systém...takže to asi nejde

edit: jo a nemusí to být 2GB. prostě podle toho, kolik máš RAM a co děláš. já třeba mám 512MB RAM, nedělám v žádnym CADu, jenom kancelářský aplikace + nějaký hry, takže mam swap taky na 512MB a je to

[Louis]

Jo, to je jasný, že to nemusí být 2GB . S tím začátkem disku - to je jasnej argument a s fragmentací taky. Škoda toho, že nejde nějak zkrýt, měl jsem tušení, že jsem to někde zahlíd (Partition Magic?)...dík

[Fox!MURDER]

idealni jsou 4 disky a RAID0+1
a kdyz je ten raidovaci algoritmus dobre napsanej tak dostanete 4nasobnej vykon pri cteni, dvojnasobnej na zapis velkejch souboru, rozumnou redundanci a celkem slusnej narust vykonu pri fragmentovanym FS.
jinak ja bych do RAID0 sel leda na disky na kterejch by byly velky soubory. Na maly soubory ne ...