Administrace komentářů

Chjo ...

1) ctes v JEDNOM threadu linearne z disku. Tomu se rika raw read. To je taky to cisilko, ktery se u disku udava - marketingovej krasozvast. Protoze v REALU takhle z disku NIKDY cist nebudes. Blizi se tomu cteni nefragmentovanych (nebo velmi malo fragmentovanych) velkych souboru.

2) pri takovymhle cteni muze uloziste dosahovat pomerne velkych rychlosti cteni, odpovidajicich poctu disku ktery ctou. Na (priklad) R5 ctou vzdy vsechny disky, takze rychlost se (teoreticky) jednoduse nasobi poctem disku.

3) jakmile ale budes cist dva soubory najednou ... tak to padne nahubu, protoze hlavicky litaji tam a sem. Pak se zacne uplatnovat jedinej skutecne realne parametr a to je IOps. Jak sem psal, nejrychlejsi existujici disky se dostanou nekam k hranici 200. Neboli, zvladnou 200 Input/Output operaci za sekundu. Ten limit je danej fyzikou.

4) a protoze jak sam pises, hodlas zaroven cist a zaroven zapisovat (a navic jeste ve vic lidech), tak jednoduse zapomen na to, ze dokazes bez diskovyho pole s SSD nebo desitkama disku saturovat Gbit. To neni fyzikalne mozny.

A pro predstavu, mam tu pole s 48x 15k diskama, a v provozu, kdy na to leze rekneme kolem 30 lidi to da, pokud z toho budu neco velkyho nasavat, kolem 250MB/s. Ty lidi tam negenerujou zadnou silenou zatez, ale bohate to staci na to, aby to pole ani zdaleka neatakovalo ty hyperteorii, ktera je rekneme nekde kolem 8GB/s. Ve skutecnosti to da mozna tu 1/10. Ostatne, ani technologie ktera se na to pouziva s necim takovym vubec nepocita, fiber ma totiz max 8Gbit podle verze.

BTW: Nevim co chces optimalizovat na sambe, ta neni limitujicim faktorem prenosu, na "levnych" kramech je to prakticky vzdy CPU pripadne uzasne zapojeni ala USB.

Jo, ty se radsi budes starat o 10 sitovek ktery budou kazdej pes jina ves... a spotrebu budou jen ty sitovky mit jako 4 switche.

http://www.czc.cz/d-link-dgs-1100-08/153228/produkt

Hmm, 1k3 s dani ... chci videt, jak delas PC bridge, kterej da tech 16Gbit ...