Ik denk het wel. Op die manier kan Ghost de ghost-image namelijk kleiner maken door de vrije ruimte niet op te slaan; alleen de files zelf. Anders zou je echt een 1:1 kopie hebben ofwel een raw image inclusief alle NTFS metadata.
In eerste instantie was er sprake van Raid5, kleine vergissing bij het typen. Maar ook Raid0 gaat er volgens mij met random-IO niet echt op vooruit, maar goed, daar schreef je zonet nog een (interessant) stuk over.
Ik heb aardig wat benchmarks gedaan en kan je vertellen dat RAID0 wel degelijk random I/O performance verbetert.
Maar het performance voordeel kan behoorlijk gecasteerd worden als er een stripe block misalignment plaatsvindt of de stripesize te klein wordt ingesteld. In beide gevallen verlies je het voordeel van parallellisatie.
Dit zijn benchmarks met globaal afwisselend lezen en schrijven. Volgens mij is dat niet helemaal vergelijkbaar met het gedrag bij het benaderen van de files van je OS. Daarbij schrijf je niet zo vaak. Kortom is het performance-verschil ook zo duidelijk bij random-lees-IO of met een kleiner aandeel schrijf-acties?
Ik zie niet waarom write anders zou zijn dan read; alleen bij parity RAID zal dat anders zijn omdat bij schrijfacties daarbij pariteit moet worden berekend; en RAID5 ook een zogenaamde 'write hole' heeft. Bij RAID0 geldt dit niet en kost schrijven evenveel 'moeite' als lezen. Dus ja: ook bij 100% random read heb je een vergelijkbaar performancevoordeel bij RAID0. Eventueel kan ik nog wat extra benches draaien voor je om dit te bevestigen.
Waarom is latency niet belangrijk?
De latency is ongeveer omgekeerd evenredig met het aantal I/O operaties per sec. (mits per I/O minder dan 500 kB ingelezen wordt, wat precies 1 omwenteling is, en de gevraagde data niet in de cache van de schijf zit)
Latency is een beetje een apart begrip. In principe is het alleen belangrijk hoeveel gegevens je kunt verstoken naar je schijf / RAID array. Dat meet je dan in I/O operaties per seconde (IOps) of MB/s (die twee zijn uit te rekenen, <grootte van I/O> * IOps = MB/s).
Latency is de tijd die het kost eer een I/O request voltooid is. Bij een enkele schijf is dat de tijd die het kost voor een seekactie en het sequentieel uitlezen; dat laatste gaat met 60MB/s+ erg snel; dat eerste kan wel veel tijd kosten. Stel je leest 1MB contigious (dat betekent: aaneensluitend; niet verspreid over de disk maar achter elkaar dus) dan kost dat bijvoorbeeld 12ms seektime (het opzoeken van de beginsector) en 1/60=16,7ms transfertime, plus de tijd dat de I/O interface (controller e.d.) nodig hebben. 12+16,7 = 28,7ms dus zeg dat je met 30ms klaar bent. Dat is de latency van deze I/O actie.
De vraag is: wat maakt het uit als de latency hoger is en het dus langer duurt eer een request terugkomt? Het gebruik van RAID of een andere 'storagelaag' (zoals via ethernet) kan de latency verhogen, maar de throughput kan gelijk blijven. Bij ethernet storage kan het zijn dat het langer duurt eer de data 'aankomt' maar je wel 100MB/s kan halen ofzo. Welk nadeel biedt een hogere latency dan? Dat hangt erg van je applicatie af; soms maakt het niets uit zoals bij kopieeracties en is alleen de throughput van belang. Maar soms zal een applicatie moeten 'wachten' op een I/O request. Bijvoorbeeld als een applicatie een configuratiebestand uitleest. Dan zal het wachten tot deze binnen is en pas op basis van de inhoud daarvan verdere I/O ondernemen. In dat geval kan de latency een belangrijke rol spelen. Maar over het algemeen is de latency niet belangrijk; en al helemaal niet voor schrijf acties aangezien de applicatie daar niet op hoeft te wachten, die schrijft een bepaalde I/O en kijkt er niet meer naar om.
Dan de vraag in hoeverre latency en throughput met elkaar verbonden zijn. En ja je hebt gelijk: met een enkele disk is die inderdaad (bijna) omgekeerd evenredig met de throughput, mits we de seeks buiten beschouwing laten. Maar dat mag eigenlijk geen latency heten aangezien dat de totale tijd is die een I/O request duurt dus ook de seekacties, ook de behandeling door de controller, de interface, etc. Maar nu hebben we het over een enkele hardeschijf. Wat nu als je 4 schijven in RAID0 hebt? De schijven zijn identiek dus ze kennen dezelfde latency; toch kun je met 4 schijven theoretisch een vier maal hogere throughput halen. De latency wordt daar niet lager van, maar de uiteindelijke IOps wel hoger! Om weer terug te komen op de autosnelweg: als je auto's 100km/h rijd dan is de latency om 100 kilometer te rijden dus een uur. Heb je nou 4 auto's rijden dan wordt de latency daar niet minder van, maar de throughput wel vier maal hoger.
Zelf denk ik dat je latency moet vergeten; het is in feite alleen belangrijk als een applicatie een leesactie uitvoert waar het echt op moet wachten; dat maakt de 'performance' wat ingewikkeld uit te rekenen en te meten. In principe is alleen IOps en dus MB/s belangrijk (de throughput). Bij geheugen (RAM) is latency overigens wel enorm belangrijk, mogelijk nog belangrijker dan throughput. Dit omdat de CPU dus enorm vaak op het relatief trage geheugen moet wachten en die tijd dus verloren gaat.
Goed gebruik van NCQ kan de gemiddelde latency van een schijf behoorlijk verlagen.
Ik had ergens gelezen (test hier @tweakers mischien) dat NCQ bij Raid-toepassingen vrijwel geen voordeel te bieden had, maar of dat op Raid-1 of 5 sloeg, of ook op 0, weet ik niet meer.
Volgens mij heb je een iets te rooskleurig beeld van NCQ. Ik ben er niet zo van onder de indruk in elk geval. Sowieso heb je er alleen baat bij als je multiconcurrency (zeg maar multiuser) access patroon hebt. Bijvoorbeeld bij database servers; daarbij kan NCQ voor een leuke (gratis) winst zorgen. Voor een windows desktop? Mwah; nee niet echt. Ik zie ook niet precies in waarom NCQ minder nuttig zou zijn in combinatie met RAID0. Oke, door de parallellisatie zal een andere disk worden ingezet om de I/O afvallige request te behandelen dus NCQ zal minder vaak 'nodig' zijn hierdoor. In feite heb je 4 (of hoeveel schijven je ook hebt) disks die kunnen seeken en dus zal NCQ minder hard nodig zijn. NCQ kan voor single user overigens ook performanceverlies betekenen. Tevens verschilt het erg per hardeschijf-model of NCQ goed geimplementeerd is en dus nuttig kan zijn. Bij de raptors was dit niet echt het geval, kan ik me vaag herinneren.
Ik heb mijn D- en C-partitie beide op dezelfde 160 GB 8 Mb cache schijf staan.
Als ik met grote files bezig ben op de D-partitie, reageren andere programma's in Windows erg traag. Je staat ervan te kijken hoe vaak Windows nog files van de C-schijf nodig heeft.
Bijvoorbeeld een nieuwe tab openen in je browser etc.
Ik gebruik zelf eigenlijk geen windows meer. Bij het openen van een nieuwe tab
zou er geen I/O hoeven plaats te vinden. Zelf ben ik voorstander van het minimaliseren van I/O tot een absoluut minimum. Derhalve ben ik ook fel tegenstander van swapping. In feite zijn alle oude 'trage' PCs traag omdat ze swappen. Soms kan dat niet anders, ok. Maar de traagheid die jij beschrijft zou je juist mooi kunnen opvangen met parallellisatie (RAID0) of nog leuker een Areca RAID controller, dat werkt al helemaal super.
:strip_icc():strip_exif()/u/3171/Ray.jpg?f=community)
en die wil ik als RAID5 installeren en mijn Windows-installatie daarop overzetten.
:strip_icc():strip_exif()/u/92085/crop5aa165833d640_cropped.jpeg?f=community)
Als het goed is wordt de status door de bijgeleverde software ook wel getoond of mogelijk in het RAID BIOS.
:strip_icc():strip_exif()/u/30381/Monion_Driver60x60.jpg?f=community)
:strip_exif()/u/2603/icon.gif?f=community){kind=icon}
Een mirror van twee 300GB 7200rpm HDD's levert net zoveel nuttige ruimte op, minstens even goede redundancy, is stukken goedkoper en in combinatie met zo'n controller nog eens sneller ook! 
/u/87784/USM60.png?f=community)
:strip_icc():strip_exif()/u/96899/blackberry_lp.jpg?f=community)
:strip_exif()/u/2172/crop57acf4ac04e70.gif?f=community)
:strip_exif()/u/120076/crop662cc528d7e2f_cropped.webp?f=community)
/u/91387/moffin_aangepast_klein.JPG?f=community)