Nieuwe hdd TPM/Cache

[Hellum]

Ik ben van plan om een nieuwe hdd te kopen maar ik zit tussen twee te twijfelen:

-Western Digital 1TB Intellipower SATA300, 64MB cache (5400 tpm)

-Samsung spinpoint 1TB SATA300 32MB cache 7200 tpm.

 

mijn vraag is, wat is in de praktijk sneller, de samsung zal sneller data kunnen ophalen, maar de WD kan meer veelgebruikte taken ophalen en tijdelijk opslaan, heeft iemand ervaring?

 

MVG. Gerard

[theparasol]

5400 toeren gebruik je als je systeem stil moet zijn.

7200 toeren of hoger als performance telt.

 

32 of 64 mb cache zegt mij niets, als er maar wat opzit.

 

Als je echt performance wilt ga je voor SSD schijf en zet je er een stille 5400 bij naast voor de bulk data.

[Hellum]

het cache is de buffer die wordt gebruikt omdat de processor veel sneller kan verwerken dan de hdd (is mij geleerd) ik ga toch maar voor de samsung, die is goedkoper

 

MVG. Gerard

[theparasol]

Hebben ze je niet goed geleerd dan.

 

Het is de buffer tussen printplaat en platters op de hdd zelf. Is bedoelt om veelvuldige read/write changes van zelfde data te bufferen.

 

Die cache helpt je geen lor als je readaccess hebt van grote datablokken. En of het nu 32 of 64 mb is... ach als er maar wat op zit. Verschils is meetbaar maar bij normaal gebruik niet merkbaar.

[grunnsat]

De cache van een schijf moet niet verward worden met de cache van een operating system. Bij een schijf wordt het resultaat van alle leesopdrachten eerst in de cache van de schijf geladen, en pas daarna doorgestuurd naar het systeem. Vaak zal meer data ingelezen worden dan waarom gevraagd wordt. Er is een grote statistische kans dat een volgende leesopdracht om die volgende datablokken vraagt, en dan staan die al vast in cache zodat ze direct aangeleverd kunnen worden.

 

Schrijfopdrachten kunnen ook opgevangen worden door de cache, maar vaak staat die functie uit. De reden daarvan is dat het dan niet zeker is dat die data weggeschreven is naar schijf als een systeem onreglementair uit valt. Professionele raid controllers hebben ook cache geheugen, maar writes worden daar alleen in opgevangen als de accu van die controller volledig opgeladen is en zijn levensduur niet overschreden is.

 

De cache van een schijf heeft niet als functie vaak gebruikte datablokken paraat te houden, dat is een functie van de systeem cache.

[Hellum]

ik denk inderdaad dat ik de boel door elkaar haal, de samsung werkt in ieder geval goed

 

MVG. Gerard

[grunnsat]

Ik moet het verhaal over de schrijfopdrachten iets aanpassen. Ook alle schrijfopdrachten komen in cache. Alleen staat de write cache normaal gesproken in "write through" mode. Dat houdt in dat de data zo snel mogelijk wordt weggeschreven naar naar schijf, en pas nadat dit gebeurd is meldt de diskcontroller aan het systeem dat de write opdracht gelukt is.

 

De write cache kan ook in "write back" mode staan. In die situatie wordt de data naar de cache geschreven, en meldt de diskcontroller direct daarna terug dat write opdracht gelukt is. Het feitelijk wegschrijven naar schijf gebeurd dan op een (iets) later tijdstip. Dit kan de performance van een applicatie behoorlijk versnellen. Maar als de stroom van de schijf onverwacht uitvalt kan deze methode van werken behoorlijk catastrofaal zijn voor de betrouwbaarheid van de data.

[theparasol]

Zo Grunnsat weer wat wiki's lopen lezen om kennis op te frissen

 

Op raidcontrollers kan cache zitten, dat is echter niet de cache die op de printplaten van de individuele harddisks zitten.

Is in de regel ook fiks groter.

Zit altijd een accu bij op de raidcontroller, als de power eraf gaat (welke oen gebruikt nu geen ups bij zijn server?!) zal door de accu de data beperkt bewaart blijven, ik meen ca 3 dagen ofzo. Kom je bij de thuissystemen niet tegen.

Nogmaals beetje cache prima, in de regel profiteert alleen kleine read/write acties hiervan. Bv database aanpassing (lees record, bewerking, schrijf terug, lees weer record, bewerking, schrijf terug, lees vorig record, bewerking schrijf terug)

 

Het zal het omzetten van een wav file naar mp3 geen seconde sneller maken.

[grunnsat]

Origineel bericht van: theparasol

Zo Grunnsat weer wat wiki's lopen lezen om kennis op te frissen

Nee hoor, storage specalist is mijn beroep.

Citaat:

Op raidcontrollers kan cache zitten, dat is echter niet de cache die op de printplaten van de individuele harddisks zitten.

Dat zeg ik ook niet, de functie komt echter aardig overeen.

Citaat:

Is in de regel ook fiks groter.

Niet als je de gezamenlijke cache van de aangesloten (SATA) schijven bij elkaar optelt. Een eenvoudige raidcontroller heeft vaak zoiets als 256MB cache, vier SATA schijven hebben ook 4 x 64 = 256MB cache.

Citaat:

Zit altijd een accu bij op de raidcontroller, als de power eraf gaat (welke oen gebruikt nu geen ups bij zijn server?!) zal door de accu de data beperkt bewaart blijven, ik meen ca 3 dagen ofzo.

Er zit niet altijd een accu op. Sommige simpele controllers hebben in het geheel geen accu, bij anderen is het een optie.

Citaat:

Kom je bij de thuissystemen niet tegen.

Soms wel.

Citaat:

Nogmaals beetje cache prima, in de regel profiteert alleen kleine read/write acties hiervan. Bv database aanpassing (lees record, bewerking, schrijf terug, lees weer record, bewerking, schrijf terug, lees vorig record, bewerking schrijf terug)

Kleine random leesopdrachten (database) profiteren nooit van cache. Die moeten namelijk per definitie van schijf gehaald worden (random!) Een gemiddelde leesopdracht kost ca. 10ms.
Kleine random schrijfopdrachten profiteren heel sterk van cache als write back aan staat. Omdat de opdracht in cache geplaatst wordt duurt een schrijfopdracht veel minder als 1ms.

Citaat:

Het zal het omzetten van een wav file naar mp3 geen seconde sneller maken.

Een beetje afhankelijk van de vraag hoe goed de software en de cache algoritmes zijn. Zo'n wav file is een groot sequentieel bestand. Als alles goed is opgezet zal de raidcontroller "begrijpen" dat er sequentieel gelezen wordt, en zal hij zelf vooruit gaan lezen (read-ahead cache), zodat de meeste leesopdrachten van het systeem uit cache gehaald kunnen worden. De schrijfopdrachten komen ook weer in cache, dus zeer snel.

Veel opeenvolgende kleine schrijfopdrachten (database logfiles bijv.) profiteren heel sterk van cache. Die schrijfopdrachten worden door de cache controller gecombineerd tot enkele grote schrijfopdrachten mits write back aan staat natuurlijk.

Overigens hebben grote SAN storage boxen tientallen GB's cache.

[theparasol]

Origineel bericht van: grunnsat

Overigens hebben grote SAN storage boxen tientallen GB's cache.

If you pull the wrong disc you propably lose your job...

[grunnsat]

Origineel bericht van: theparasol

If you pull the wrong disc you propably lose your job...

Daarom hebben die disks meestal een lampje om ze te kunnen lokaliseren. Dat lampje kun je zelf via de management software aanzetten, of de disk heeft het lampje al aangezet om aan te geven dat hij hoofdpijn heeft.

[Sjattuh]

Ik las net je opmerking over OS en Hardware Cache en dat men deze niet moet verwarren.

 

Maar OS-en hebben toch helemaal geen cache? Dat is puur iets hardwarematigs?

 

Ik weet dat Windows Virtueel Geheugen heeft, en misschien dat je dit bedoelt, maar dit is toch weer iets puur software matigs waarbij Windows een gedeelte van de HDD reserveert voor wanneer de RAM vol loopt?

 

Of is er (weer) iets wat ik niet weet?

[grunnsat]

Ieder fatsoenlijk OS gebruikt een gedeelte van het interne geheugen als buffer cache tussen de schijven en de applicaties. Het is helemaal afhankelijk van het systeem, het OS en het gebruikte filesysteem en instellingen hoe groot zo'n cache is. Maar ze kunnen tot tientallen GB groot zijn.

 

Databases hebben ook caches, en ook die kunnen tientallen of zelfs meer dan 100GB groot zijn. Veel database administrators hebben geen flauw idee hoe belangrijk zo'n cache is en hebben die cache veel te klein ingesteld. Vuistregel: heb je een slecht presterend systeem met een database, kijk maar eens naar het nog beschikbare fysieke systeem geheugen en de grootte van de database cache. Hoe vaak ik wel niet heb meegemaakt dat niemand begreep waarom het systeem slecht presteerde, en de oplossing niet meer was dan het uitbreiden van de database cache ......