1) pokud Vam rozumim, ty IDE disky byly v nejake externi kastli, ktera ma navenek SCSI - at uz je ta externi kastle plnohodnotny RAID, nebo "jenom JBOD", v kazdem pripade vsechna data tecou skrz jakysi IDE-to-SCSI radic, ktery je obvykle uzkym hrdlem podobne koncipovanych systemu. Nebo chcete rict, ze RAID5 byl realizovan touto jednotkou firmy Proware?
Jednotky SCSI-to-IDE od firmy Proware maji zrejme radice Areca s procesorem IOP303 nebo IOP321 (dve historicke rodiny) - od toho se odviji jejich pruchodnost. RAIDy s procesorem IOP321 umi tak max. 150 MBps RAID0 (podobne bude cteni z RAID5).
2) ten adaptec (29160 nebo 39160) byl zasunut v jake PCI sbernici? Pokud PCI 32@33, tak tato ma maximalni pruchodnost cca 100 MBps (half duplex). Pokud tuto otazku zformuluji jinak: jaky systemovy cipset mel stroj (PC), na kterem jste tento test provadel?
Osobne jsem videl 14 ks U320 SCSI disku ve stroji s cipsetem i7520 a s dvoukanalovym aic7902 (U320 Adaptec, jako 39320) - tj. ten dvoukanalovy cip mel smerem do PC k dispozici cca 1 GBps PCI-X 64@133 half-duplex. Tech ctrnact disku cetlo dohromady 320 MBps, coz je mene nez prosta suma jejich individualnich spickovych vykonu, a mene nez soucet obou kanalu SCSI. Nemel jsem na tom postaveny RAID, jenom jsem paralelne spustil linearni cteni po sektorech ze vsech 14 disku.
Neviem, preco sa ludia tak zenu za MB/s. Tie su dobre akurat tak, ked prenasam velky subor alebo pozeram film. Skutocne potrebne su IO/s, to je to na com stoji a pada vykon databazovych serverov. A podla toho, ci treba MB/s alebo IO/s, tak sa vybera aj typ RAIDu.
Už jsem si několikrát všiml, že pokud převezmete z osnews zprávičku o nějakém článku, automaticky připíšete autorství _článku_ Thomu Holwerdovi.
On je ale jen osnews editor, takže tu zprávičku jen zveřejnil (vždyť tam máte jasně napsáno "Linked by Thom Holwerda on 2005-12-06 13:18:16 UTC, submitted by cpina"). Je to jako kdyby někdo převzal tuhle zprávičku z roota a za autora článku prohlašoval Petra Krčmáře...
Na skutečného autora je odkaz dole pod článkem.