2x Raptor 36GB ADFD + 2x 80GB in RAID 0

[Remy!!!!]

Ik heb op dit moment 2x Raptor 36GB ADFD in RAID 0 staan,
Ik heb echter nog 2 80GB Maxtor 8MB SATA schijven over, als ik deze aan de RAID array zou toevoegen zal ik dan perfomancewinst maken??

Ik weet dat het niet super verstandig is om 4 schijven in RAID te plaatsen, echter wordt deze array alleen voor Windows + games gebruikt, back-up + belangrijke documenten worden op een schijf in het netwerk geplaatst.

Ik denk zelf dat het wel nut zal hebben, maar het probleem is dat de "normale" 80GB schijven maar 700RPM zijn, dus dit zou een bottleneck kunnen vormen i.c.m. de raptors, dit kan ik echter nergens vinden op GOT of google vinden.

Verder specs:
Proc: AMD 64 3500+
Mobo: Asus A8N-E
Geheugen: 4x 512MB PC3200

[Jimbolino]

probeer het en je weet het...
er zijn zat benchmarktools beschikbaar, hdtune, sandra hdtach e.d.

persoonlijk zou ik gaan voor
2xraptor raid0
2xmaxtor raid0
windows op je raptors en je swapfile op je maxtors...

[ Voor 18% gewijzigd door Jimbolino op 07-12-2006 15:06 ]

[Ravefiend]

Zonder twijfel een slecht idee om die 2 maxtors bij in je RAID0 te zetten. De suggestie hierboven is daarentegen warm aan te bevelen ...

[Remy!!!!]

Maar een swapfile wordt toch alleen gebruikt als het OS geheugen tekort komt?
Als dit het geval is dan lijkt het mij niet echt nodig aangezien er al 2GB aan geheugen in zit.
Als ik het verkeerd heb hoor ik het graag.

[maratropa]

Je pagefile (geen swapfile) moet je je geen zorgen om maken, gewoon op elk volume 1tje.

Door die 7200rpm schijven naast je raptors te hangen worden die raptors ook maar zo "snel" als die maxtors. Ik zou het nevernooit doen en ze gewoon als 2de raid 0 volume gebruiken.

[ Voor 3% gewijzigd door maratropa op 07-12-2006 18:56 ]

[BalusC]

Kijk eens in de FAQ van dit subforum

OM FAQ / Beleid
• Hoe/waarmee kan ik mijn schijf/schijven het beste indelen?
• RAID FAQ » Verschillende schijven in RAID mogelijk?

[Jimbolino]

maar als de traagste schijf de snelheid bepaalt dan kan het toch nog wel interessant zijn...

stel je maxtors doen 40mb/s en je raptors 60mb/s (fictieve waardes)
als je nu 2 raptors in raid0 heb je 120mb/s
zet je alle 4 in raid heb je (4x40mb/s) 160mb/s

de vraag is echter of dat kleine beetje snelheidswinst opweegt tegen het toegenomen risico op schijfcrashes...

[ Voor 19% gewijzigd door Jimbolino op 08-12-2006 02:15 ]

[BalusC]

Kijk niet alleen naar de STR's, maar ook naar de seektimes en de I/O performance. Het mixen van deze set zal een zware deuk op de seektime en de I/O performance van 2x Raptor RAID0 achterlaten.

[ Voor 5% gewijzigd door BalusC op 08-12-2006 09:19 ]

[Verwijderd]

BalusC schreef op vrijdag 08 december 2006 @ 09:18:
Kijk niet alleen naar de STR's, maar ook naar de seektimes en de I/O performance. Het mixen van deze set zal een zware deuk op de seektime en de I/O performance van 2x Raptor RAID0 achterlaten.

Als de I/O requests 'op' de raptor schijven neerkomen, zou het niet uit mogen maken. Heb je echter een te lage stripesize voor je random I/O, dan zal voor een I/O request 2 of meer schijven 'geraakt' worden. In dat geval verpest je wel je I/O performance want de request is pas voltooid als beide schijven hebben gelezen cq. geschreven. Dus als je al verschillende schijven mengt, zou ik een lekker grote stripesize aanhouden. Zodat de verschillende I/O's zo weinig mogen schijven overlappen, en idealiter maar 1. Tenzij het sequentiele I/O is natuurlijk, dan maakt het niet zoveel uit.

[maratropa]

Verwijderd schreef op vrijdag 08 december 2006 @ 10:35:
[...]

Als de I/O requests 'op' de raptor schijven neerkomen, zou het niet uit mogen maken. Heb je echter een te lage stripesize voor je random I/O, dan zal voor een I/O request 2 of meer schijven 'geraakt' worden. In dat geval verpest je wel je I/O performance want de request is pas voltooid als beide schijven hebben gelezen cq. geschreven. Dus als je al verschillende schijven mengt, zou ik een lekker grote stripesize aanhouden. Zodat de verschillende I/O's zo weinig mogen schijven overlappen, en idealiter maar 1. Tenzij het sequentiele I/O is natuurlijk, dan maakt het niet zoveel uit.

Maar doet zo'n onboard controller uberhaupt wel aan deze "slimme" manier van requests afhandelen?

[Verwijderd]

gladiool schreef op vrijdag 08 december 2006 @ 10:38:
[...]


Maar doet zo'n onboard controller uberhaupt wel aan deze "slimme" manier van requests afhandelen?

Er is niks 'slims' aan; een controller kan niet weten wat voor filesystem erop komt te staan en hoe die omgaat met requests. Veel filesystems houden totaal geen rekening met de mogelijkheid van 'stripe boundaries' en hanteren bijvoorbeeld een offset van 16 sectors (8KB). Tenzij je een stripesize van 8KB hebt, gaat daar dan je random performance! En ook al begint de filesystem op offset 0 (of offset 1024; geschikt tot en met 1MB stripesize), dan nog kan het zijn dat files die je ergens in het midden van het filesystem neerzet een andere 'boundary' krijgen.

Hoe NTFS/FAT dit doen weet ik niet; bij FreeBSD met UFS is het zo dat deze dus standaard een offset van 16 sectoren aanhoudt met disklabeling, maar door 'Dangerously Dedicated' mode te gebruiken of handmatig te labelen tot 1024KB offset, je deze boundary kunt verleggen en dan dus filesystem en stripe blocks 'aligned' zijn. Concreet houdt dat in dat als je een file schrijft van 128KB met een stripesize van 128KB; deze maar 1 fysieke schijf 'raakt' en niet 2 schijven. Resultaat: optimale random I/O performance.

N.B.: Dit soort problemen worden vaak over het hoofd gezien; zelfs op goede reviewsites.

[Abbadon]

Ja, zo heb ik ook altijd handmatig een offset meegegeven bij het aanmaken van een volume of device op een RAID array in/aan een Sun doos. Dit is allemaal hele interessante materie voor de diehards die het uiterste uit een array willen halen, maar ik denk dat we daarmee wel de situatie van de TS uit het oog verliezen.

Gewoon niet die vier verschillende disken in dezelfde array plaatsen, dat is echt het beste Maak er dan liever twee stripe sets van.