SSD beställning

Intel 320 target markets: "Datacenter, Corp IT, OEM, Reseller, bVAR, System Integrator",

Intel 330 target markets: "E-Tail and Retail",

Intel 520 target markets: "E-Tail, Retail, Corp IT, OEM, Reseller, bVAR, System Integrator".

Sen är det inte många som bara skriver okomprimerbara 4kB-block med ködjup 32 hela dagarna, så Sweclockers tortyrtest är inte representativt för serveranvändning heller (och gör man det är nog 830 inte rätt ändå, den fick ju kritik för att den bara kör GC när den inte har något att göra).

Men visst ska man veta vad man håller på med, tror dock att många "företagsfiler" går bättre att komprimera än sånt folk har hemma (spel, musik, filmer).

Fast det inträffar ju bara om man skriver över hela disken med slumpmäsisg 4kB okomprimerbar data och sen fortsätter skriva ännu mer okomprimerbar data, det är inget som någonsin kommer inträffa för de flesta (det händer definitivt inte om man har sitt OS på samma disk). Är det ett fall som kommer inträffa så behöver man ändå räkna och mäta på att lösningen kommer hålla, att då bara köra in en SSD och hoppas på det bästa kommer vara en riktigt dålig idé oavsett vilken kontroller SSDn har.

Sen hade det förstås varit bättre att det gick att skriva hela disken med okomprimerbar data utan prestandförluster, men det är inget jag kommer bli påverkad av i min användning.

Intel har inte sagt att de slutar med egna styrkretsar eller ens att de slutar med 320-serien, men 320 kommer inte längre marknadsföras mot konsumenter. Sen så hade de inte så mycket val om de för tillfället vill vara relevanta i prestanda-segmentet. Gamla 510 var alldeles för dyr och hade vissa tveksamheter i prestandan.

Nja, du har missuppfattat, detta har inget med att SSDn slits, wear leveling eller erase cycles att göra. Skriver man komprimerbart data kommer det alltid finnas ledigt utrymme och då är det inget problem. Nästan ingen kommer drabbas av detta problem oavsett hur lång tid det går. Se t.ex.

http://www.anandtech.com/show/5508/intel-ssd-520-review-cherr...

Du påstod om Sweclockers tortyr-test att det "troligen mer simulerar tung användning i en server än ett typiskt "hemanvändarmönster", så tappar 520 hastighet" och att "Fast även när man låtit diskarna vila ett tag så kvarstod ju prestandaproblemen för intel, i och med att de kör sandforce". Men man gör exakt det test som beskrivs i Anandtech-artikeln om du nu läste den. Man tappar prestanda för att man skriver okomprimerbar data över hela disken upprepade gånger under längre tid utan att radera något eller att någon data går att komprimera.

Man tappar inte prestanda på det viset bara genom att använda disken på vanligt sätt. Detta har inget med antal P/E-cykler att göra, och som jag skrev redan i förra svaret, det står väldigt tydligt i Anandtech-artikeln, läs den nu! Men jag får väl kopiera in slutsatsen ändå: "Again, I don't see most end users backing themselves into this corner but it's worth pointing out.".

Man måste alltså "backa in ett hörn" på precis det sättet som beskrivs på Anandtech eller i Sweclockers-artikeln. Det är inte så att om datan går att komprimera 50% kommer samma sak att inträffa efter dubbelt så lång tid utan då kommer det inte inträffa alls.

När väl data har skrivits till ett block så kvittar det om datan är komprimerad eller inte, oavsett kontroler.
Jag har läst artikeln, men blir fortfarande inte klokare av vad du menar med att data som komprimeras innan den skrivs inte sänker prestandan. Att skriva 100MB okomprimerbar data är exakt samma sak som att skriva 200MB data som kan komprimeras till 50%, så vad är det som i så fall gör att komprimerad data inte sliter på disken, annat än det att det i "verkligheten" skrivs mindre data och därför inte sliter lika hårt? Jag får det inte att gå ihop.