Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 195 reacties
Submitter: ikt

Na meer dan 2,4 petabytes aan schrijfopdrachten is de Samsung 840 Pro-ssd overleden in de langdurige staminatest van Tech Report. Nummer twee is de Kingston Hyper X 3K-ssd. Deze wist tot aan zijn overlijden 2,1PB aan data weg te schrijven.

De technologie-website onderwierp een aantal ssd's aan een duurtest, waarbij continu data met behulp van Anvil's Storage Utilities naar de drives werd weggeschreven. De geteste drives waren de Corsair Neutron GTX 240GB, Intel 335 Series 240GB, Kingston HyperX 3K 240GB, Samsung 840 Series 250GB, en Samsung 840 Pro 256GB.

De Samsung 840 Pro is volgens Tech Report de meest betrouwbare ssd omdat de solid state drive geen onherstelbare fouten produceerde tot aan het moment dat het opslagapparaat niet meer functioneerde. Ook het aantal toegewezen reallocated sectors, waarbij 'reserve flash' wordt ingezet om uitgeputte geheugencellen te vervangen, verliep volgens een voorspeld patroon. Volgens de statistieken van Tech Report begon de 840 Pro na 600TB aan schrijfacties de eerste reserves aan te wenden. Nadat de ssd na 2,4PB aan writes de geest gaf, waren er 7000 reservesectoren gebruikt die samen goed waren voor 10,7GB.

Op de tweede plaats in de marathontest eindigde de Kingston Hyper X 3K-ssd. De ssd werd pas onbenaderbaar na 2,1PB aan writes. De solid state drive meldde na 1PB aan writes echter wel enkele onherstelbare fouten, terwijl ook het aantal program errors toenam. De Hyper X 3K bleek echter na een stroomstoring onbenaderbaar, al stelt Tech Report dat niet zeker is dat de onderbreking de hoofdoorzaak is van het overlijden van de ssd.

De Intel 335 Series hield het na 750TB voor gezien en de Samsung 840 haalde het tot 900TB, hoewel al veel eerder problemen verschenen, waaronder onherstelbare. De Neutron GTX van Corsair behaalde 1,2PB aan writes voor de drive de geest gaf.

Volgens Tech Report bewijst zijn staminatest, die 18 maanden duurde, dat de solid state drives aanzienlijk meer schrijfacties kunnen verwerken dan de gemiddelde consument ooit zal produceren. Wel geeft de techsite toe dat door de beperkte hoeveelheid ssd's die er zijn getest er geen definitieve conclusies over de levensduur van de geteste drivetypes zijn te geven. Verder wordt nog het advies gegeven om data veilig te stellen zodra de eerste foutmeldingen verschijnen, bijvoorbeeld afkomstig van het smart-mechanisme, omdat ssd's plots kunnen overlijden.

Geteste ssd's

Moderatie-faq Wijzig weergave

Reacties (195)

Toch iets om over na te denken waar je welke SSD voor inzet, zeker als het lang mee moet gaan. De pro is in dat geval zijn extra geld wel waard.
Ligt eraan. Dit is net zoveel informatie als dat een auto 500 wasbeurten overleeft. In eerste instantie denk je wat weinig, maar als je je auto elke 2 weken wast, dan gaat deze ruim 19 jaar mee.

Ik vind niet dat je als consument op deze info iets moet baseren zonder dit in de juiste context te plaatsen.

Hier kun je het volgende lezen:
It's generally accepted that the average consumer writes an average of 5 to 10 GB per day to an SSD.
Dat betekent met 750TB (de slechtst scorende), dat je als gemiddelde consument 75.000 dagen met je SSD door kan brengen, zo'n 200 jaar. Zelfs al gebruik je je SSD tien keer zo intensief in vergelijking met de gemiddelde gebruiker: >20 jaar levensduur.

Helaas is dit voor mij een langepenisspec. Leuk om mee te patsen, maar de échte Tweaker weet wel beter, die gaat alleen voor het dikste spul ;)

[Reactie gewijzigd door Nas T op 13 maart 2015 12:18]

Over de levens duur maak ik me al jaren niet neer druk, betrouwbaarheid is al minstens 3 jaar geen probleem meer met MLC SSDs.

Wel moeten SSDs eens in de zoveel tijd iig aan gezet worden, om zijn cellen te kunnen verversen, als de firmware dat ondersteund, want NAND cellen verliezen hun spanning/waarde over tijd.

Vooral de nieuwe TLC heeft hier een probleem mee, die geven duidelijk meer problemen wat betreft betrouwbaarheid, in eerste instantie leken die ook betrouwbaar, maar de problemen doen zich juist voor als de SSD te weinig gebruikt wordt, daar er een flink verschil zit tussen de 4 cell waardes van MLC, en de 8 waardes die nodig zijn voor TLC om te werken.

De toleranties zijn gewoon te klein om betrouwbaar te zijn over de langere tijd, daar een NAND cell over tijd een gedeelte van zijn lading verliest, en net als elke andere condensator of batterij, lek stroom is gewoon een probleem, en de fout marges bij TLC zijn blijkbaar te klein om betrouwbaar te zijn, als een SSD een langere tijd niet gebruikt wordt!

Zelf heb ik een backup van mijn SSDs, en mijn 840 EVOs in RAID0, die ik voornamelijk gebruik voor mijn games, en ongeveer 1x per maand doe ik een format, om al mijn data te verversen, en zet ik de backup terug, maar het is belachelijk dat dat nodig is om een SSD snel en betrouwbaar te houden. |:(

Edit:
Aangezien vele hier niet bekend zijn met de problemen van de TLC SSDs, met namen vooral van de Samsung de 840 EVO, kan men hier meer over vinden, meet meer diepgaande discussies:
nieuws: Samsung onderzoekt opnieuw prestatieproblemen 840 EVO-ssd's

[Reactie gewijzigd door player-x op 13 maart 2015 17:49]

Elke maand de zaak formatteren??? Heb je dataverlies als je dit
Niet doet? Ik gebruik mijn SSD al 4.5 jaar en nog nooit een format nodig gehad.
Elke maand de zaak formatteren???
Eigenlijk is een keer per 3 maanden genoeg, maar heb een maandelijkse event op gezet dat een kleine batch script start.
  • pause
  • format D: /q
  • xcopy F:\ D:\ /s /f /g /h /i /x /s /r /v
  • shutdown /l
Heb je dataverlies als je dit niet doet?
Nee maar na 3 maanden wel merkbare snelheidsverlies, welke de laatste update nog steeds niet heeft gefixt.
Ik gebruik mijn SSD al 4.5 jaar en nog nooit een format nodig gehad.
Met een normale SLC of MLC NAND SSD, is dat ook geen probleem, het is een probleem waar de 840 EVO's last van hebben.

Maar ik vermoed dat andere TLC drives ook problemen zullen hebben over langere tijd, iig als ze een tijd niet gebruikt worden, is de kans op data verlies een heel stuk groter dan bij MLC type SSDs.
Het formateren is niet eens nodig. De schijf leeghalen en de data opnieuw schrijven is voldoende. Eigenlijk een soort defragmentatie.
Is fragmentatie niet enorm slecht voor SSD's? Zie ook niet echt de nood aan fragmentatie aangezien dit vooral bedoeld is voor de fysieke beperkingen bij optische schijven als de koppen teveel moeten verspringen van blok naar blok?
Sequential reads zijn het sterkste punt van een SSD. Defragmentatie heeft dus een negatief effect.
Een SSD heeft vooral voordelen als opstart en programma-schijf. Voor de pagefile is een SSD minder geschikt. Daar wordt over het algemeen veel in geschreven en meestal minder uit gelezen. Al die schrijfacties bekorten ook de levensduur.
Voor het werken aan grote bestanden is een SSD vaak een uitkomst. Ik werk vooral aan databases en dan is de snelheidswinst maar klein. Daarvoor heb ik toch liever een snelle harddisk en veel intern ram-geheugen.
Wat ik mis in het artikel is hoe traditionele hdd het doen. Hoe veel data kan bijvoorbeeld een 256gb western digital voor zijn kiezen krijgen voordat deze de geest geeft. Pas dan kun je een goede vergelijking maken of een ssd echt nadelige gevolgen heeft tegen over een gewone hdd
Mijn uneducated guess is totdat de aandrijving van de koppen of schijven ophoudt. Maar de disks zelf gaan niet kapot.
Een quick format is een heel stuk sneller dan alle files deleten, daarnaast zorgt het ook voor extra onnodige schrijfacties, een format is gewoon het snelste.
Blij dat ik dan voor de iets goedkopere MX100 ben gegaan jaartje geleden!
Nee de reden is dat meneer player-x z'n SSD's in RAID0 zet. Waarom je dit zou doen snap ik niet helemaal. Wel heb ik 1x Secure Erase gebruikt om de SSD volledig te schrappen om zo z'n snelheid te behouden. Maar 1x per 6 maanden mag ook wel.(Heb mijn SSD nu bijna 1 jaar)

[Reactie gewijzigd door BJ_Berg op 13 maart 2015 17:04]

R0 heeft totaal geen invloed op het probleem dat het TLC geheugen heeft van de 840 EVO.
Waarom je dit zou doen snap ik niet helemaal.
Omdat ik gewoon een grote disk wil hebben, daar 1TB voor mij niet voldoende is voor mijn games en programma's, dat is al voldoende reden, ik zelf heb een speciale reden om goed gebruik te maken van de hogere sequentiële doorvoer.

En waarom zou ik een Secure Erase of volledige format doen?
Gewoon quick format is voldoende, alle cellen worden dan gezien als ongebruikt, en zet gewoon verse data terug op de SSD.

En nee 1x per 6 maanden is niet genoeg, ik en andere begin al problemen te krijgen na 3 maanden, met gewoon 1x per maand alle dat verversen is dat probleem opgelost, daar voor de rest er bar weinig op de SSD weg geschreven wordt.
Zelfde hier, ik heb z'n vreselijk onbetrouwbare OCZ Agility 3 120GB, ik gebruik hem al meer al drie jaar ongeveer als boot en page schijf, geen enkel probleem mee... wel één keer geformateerd, maar dat was voor een schone OS installatie.
Het is de Vertex 2 die onbetrouwbaar is, mijne gaf de geest net na 2 jaar, nu samsung 840
Heb in 2 jaar tijd 3 vertex 2's versleten... de resultaten kunnen wisselen. Maar bij de meeste gebruikers gingen de vertex 2 drives tussen de 1,5 en 2,5 jaar stuk. Maar betrouwbaarheid was niet het enige issue.

Prestatie dips waren een ander probleem. De drives stelden garbage collection uit tijdens belasting. Alleen tijdens een langere periode van belasting ging de drive toch op een bepaald moment garbagecollection doen en zakte de prestatie's in tot ver onder die van de traagste HD ooit. (denk aan 3-5MB/s aan lezen/schrijven)
Dat is appels en peren, de OCZ Agility 3 is een MLC SSD, en het was niet het gebruikte NAND geheugen dat voor probleem van de OCZ SSDs zorgde.

Het was juist de firmware die voor problemen zorgde, een heel ander probleem dus.
De toleranties zijn gewoon te klein om betrouwbaar te zijn over de langere tijd, daar een NAND cell over tijd een gedeelte van zijn lading verliest, en net als elke andere condensator of batterij ...
Onzin verhaal. Een flash cel is geen condensator of batterij. De lading van een flash cel zit in een isolator.

Daar heb je meteen de oorzaak van de beperkte write-cycles te pakken: je beschadigt de isolator door de lading met fors geweld (15 volt !) de isolator in te schieten.
Onzin verhaal. Een flash cel is geen condensator of batterij. De lading van een flash cel zit in een isolator.
Nee jij hebt het fout, een flash cel werkt wel degelijk op de zelfde manier als een condensator, want net als een condensator, verliest hij ook zijn waarde door middel van lekstroom door de isolator, en juist met de steeds kleinere cellen is dat een probleem daar die in verhouding een grotere lekkage hebben dan dan grotere cellen.

Om het goed te laten zien heb ik hier de verschillen tussen de verschillende types NAND uitgeschreven.

SLC
Bij een lading van minder dan 50% heb je een 0
Bij een lading van meer dan 50% heb je een 1

MLC
Bij een lading van tussen de 0% en 25% heb je een 00
Bij een lading van tussen de 25% en 50% heb je een 01
Bij een lading van tussen de 50% en 75% heb je een 10
Bij een lading van tussen de 75% en 100% heb je een 11

TLC
Bij een lading van tussen de 0% en 12.5% heb je een 000
Bij een lading van tussen de 12.5% en 25% heb je een 001
Bij een lading van tussen de 25% en 37.5% heb je een 010
Bij een lading van tussen de 37.5% en 50% heb je een 011
Bij een lading van tussen de 50% en 62.5% heb je een 100
Bij een lading van tussen de 62.5% en 75% heb je een 101
Bij een lading van tussen de 75% en 87.5% heb je een 110
Bij een lading van tussen de 87.5% en 100% heb je een 111

Zo als je kan zien loopt de nauwkeurigheid waar mee gelezen moet worden kwadratisch op, en worden de fout marges elke keer een twee keer kleiner, en worden de problemen van lekstroom steeds veel groter.

Bij de 840 EVO, had Samsung het probleem iig nog niet onder controle, en is zijn gewoon ze te vroeg met hun product op de markt gekomen.

Hier een goede video uitleg, en hier een geschreven uitleg van HOWSTUFFWORKS
De lekstromen van flash zijn in de orde-grootte van 10-20A. Fracties van atto-amperes dus. Dat betekent dat de lektijd in eeuwen wordt gemeten (letterlijk: het eerste document wat ik vond had een lektijd van 13 eeuwen).

Een DRAM condensator loopt leeg in een seconde, ter vergelijking. Dat is een compleet ander fysisch proces.
Blijkbaar is dat wat het moet zijn in theorie, in de praktijk blijkt het dat de cellen wel degelijk lekken!

Lees het stukje in het volgende artikel op Anantech: Explaining the Bug

Cell lekkage is dus wel degelijk het onderliggende probleem.
Nee, dat plaatje is geen lekkage over tijd. Dat plaatje laat beschadiging over tijd zien, als gevolg van writes (zoals ik ongeveer 10 posts hierboven al postte).

En ja, TLC is kwetsbaarder voor elke vorm van verstoring zoals je terecht aantoont. Dat was mijn punt ook nooit.
Precies, flash is geen DRAM.

En het herschrijven van alle data zorgt alleen maar voor een verkorte levensduur. Als je niet schrijft naar een NAND cell dan gaat die 'eeuwig' mee. Of in ieder geval een jaar of dertig.
Correct de cell gaat jaren eeuwig mee, maar dat geld niet voor de lading die in de cell zelf zit, en als die veranderd, dan klopt de data niet meer, dan heb je of een error of een omgevallen bitje, en als dat gebeurd van wegen lekstroom, dan gebeurd het zeer waarschijnlijk met meerdere bitjes.
[...]

Onzin verhaal. Een flash cel is geen condensator of batterij. De lading van een flash cel zit in een isolator.

Daar heb je meteen de oorzaak van de beperkte write-cycles te pakken: je beschadigt de isolator door de lading met fors geweld (15 volt !) de isolator in te schieten.
Het is niet geheel onzin. Vooral de 840 EVO's van Samsung hebben een probleem waarbij het voltage in sommige cells dusdanig laag wordt dat de ssd ongewoon veel ecc moet toepassen. Dat resulteerde in oververhitting van de chip die daarvoor verantwoordelijk is, en prestatieproblemen (omdat de chip werd teruggefloten door een beveiligingsmechanisme tegen doorbranden).
Waarom formateren? Ik heb een 830 welke nu al 3 jaar zonder problemen draait, gezondheid dik boven de 96%. Dus die gaat nog wel even mee en nog nooit problemen gehad met dat ding. Wat ik wel doe is af en toe een read-pass te doen over de hele disk. Maar dat is misschien 1 keer per half jaar.

[Reactie gewijzigd door Wim-Bart op 13 maart 2015 15:46]

Zelfs al gebruik je je SSD tien keer zo intensief in vergelijking met de gemiddelde gebruiker: >20 jaar levensduur.
En zelfs als door onverwachte malheur en wild gebruik de levensduur 10 jaar is, is dat prima.
De ongefundeerde angst bij de gebruiker zou op voorhand weggenomen moeten worden.
''Ja, maar hij is zo duur, ik ben er zuinig op''.

Gebruiken, die SSD !!
Daarnaast de ssd die je nu hebt kost over 5 jaar nog maar een fractie, c.q je krijgt waarschijnlijk 4x meer capaciteit.

Wat jammer is aan deze test is dat men van hetzelfde merk meerdere exemplaren moet testen. In hardware zitten altijd toleranties en door maar 1 examplaar te testen haal je die toleranties er niet uit.

de winnaar kan bijv net een heel goed exemplaar geweest zijn terwijl de verliezer een slecht exemplaar kon zijn.
Je vergeet dat al deze drives bestaan uit vele individuele flash chips. Het zijn geen USB sticks. Je hebt dus al meerdere exemplaren van de chips getest. Om de 840 Pro uit het artikel als voorbeeld te nemen, die had 7000 bad sectors verspreid over de verschillende chips, dat kan dus best 875 bad sectors gemiddeld over 8 chips zijn geweest.
Normaal mag je aannemen die die individuele chips uit dezelfde batch komen. Chips uit een andere fabrieken of 4 maanden eerder of later geproduceerd kunnen natuurlijk iets anders zijn
Klopt, maar neem een probleem zoals een stofje (gangbare oorzaak van problemen, vandaar dat ze in cleanroom werken). Dat stofje veroorzaakt een probleem op de ene chip en niet op de volgende.

En ja, een jaar later heb je een goede kans dat aanloopproblemen in een fabriek opgelost zijn. Daar heb je weinig aan voor je suggestie om meer dan 1 exemplaar in zo'n test mee te nemen. Alel exemplaren wil je tegelijk testen.
Goed punt. Ik had bij mijn eerste ssd (Intel 320, 120GB voor ruim 200 euro) ook erg het idee dat ik er erg zuinig mee moest zijn maar tegenwoordig zijn ze zo betaalbaar dat ik mijn huidige ssd niet anders behandel dan ik met een normale harde schijf zou doen.
Dikste spul is leuk maar in mijn mediacentre en mediaserver gaan echt gewoon de goedkoopste 30 gb drives die ik kan vinden als bootdrive.
Workstation, gaming pc en mijn professionele server mogen uiteraard wel weer hoogwaardig spul verwachten want daar is er nut voor.
En dat is ook terecht voor die toepassingen, want daarin worden nauwelijks schrijfacties uitgevoerd op de bootdrive. Op gaming-rigs mag inderdaad beter spul, maar ook daar geldt voor mij wel beter een goede prijs/prestatie dan het summum van specs.
Het is veel belangrijker om te kijken naar hoe de schijven falen.

Een schijf die het gemiddeld 50,000 dagen uithoudt zou wel eens na 500 dagen kunnen falen, en dan heb je liever een die bewezen heeft (na gemiddeld 50,000 dagen) clean te falen na enkele SMART-warnings en voorspellende dromen dan een die (na gemiddeld 50,000 dagen) zonder waarschuwing instort tot een zwart gat.

Edit: dit is spam?

[Reactie gewijzigd door Enai op 13 maart 2015 12:40]

Toch valt het me op dat die schatting erg laag ligt. Ik heb zelf in iets meer dan een jaar 20 TB write IO (volgens de SMART data) en dat wordt alleen maar gegenereerd door de cache van de applicaties die ik gebruik.

Op me Surface Pro 1 heb ik 6.46 TB weggeschreven in anderhalf jaar, terwijl ik die maar een paar uur in de week gebruik.
Ik heb m'n SSD laatst gedefragmenteerd. Een 2,5 jaar oude windows 7 installatie begon toch wat langzaam te worden, zelfs na opschonen. Wat calculaties gedaan dat een disk optimizer ongeveer een uur bezig was op maximale schrijfsnelheid zou hij een keer 100 gb aan schrijfacties kosten. De ingebouwde benchmark van defraggler gaf een flinke verbetering: +20 %. 100 GB op een gehaalde 750 TB.
En daarbij zit al te kijken naar z'n vervanger - 128 GB is toch wel wat krap.
Een ssd zou je ook helemaal niet moeten defragmenteren, dat is een actie voor mechanische hardeschijven, waar het nog nut heeft om data sequentieel op te slaan omdat dit daarna sneller uit te lezen is met de beperkte aantal koppen.

Een ssd heeft geen leeskoppen en kan via de controller uit elke flash package net zo snel de data halen. Het enige wat defragmenteren voor ssd's doet is veel onnodige writes produceren die in principe nergens goed voor zijn.
Als het werkelijk waar is wat je zegt dan zou een random 4k read net zo snel moeten zijn als de sequentiele read. Ik heb nog geen één SSD gezien waarbij dat het geval is; altijd scoort de random 4k read veel lager dan de sequentiele read.

[Reactie gewijzigd door SpiceWorm op 13 maart 2015 17:57]

Ssd defrag.. Is not done, als je iig waarde hecht aan de resterende levensduur van je ssd..
Heb je m'n post gelezen? Of heb je na de woorden SSD en defrag deze comment gezet?

De SSD is sneller nadat hij gedefragmenteerd is, mijn pc werkt sneller.
De SSD is na defragmenteren sneller omdat de sequential read hoger is dan de random read. Hoe meer je data gefragmenteerd is, hoe meer je snelheid zal zijn als de random read. Na defragmenteren zal het gros van de data worden ingelezen als sequential read.

Als je het artikel had gelezen had je geweten dat 2x je SSD volledig beschrijven (worst-case defrag) niets uitmaakt voor je levensduur. De slechts-scorende SSD had een omgerekende levensduur van 200 jaar bij gemiddeld gebruik. Een volledige defrag zou maximaal één maand van de levensduur afhalen.
Volgens mij.. heb je wat ideeen, maar of ze in de praktijk helemaal opgaan heeft mij nog niet overtuigd. Ik heb nml nog geen enkele test online gelezen die beweert of onderschrijft dat het defragmenteren van een SSD performance verbeterend zou zijn. Sterker nog; de meeste defrag programma's hebben niet eens een optie om de SSD te defragmenteren. Dus je moet al erg veel moeite doen om sowieso een defrag te kunnen doen van een SSD.

Ik heb wel gelezen dat een secure erase en opnieuw installeren helpt. Net als het goed allignen van een SSD helpt.
Ik heb een benchmark voor én na gedaan. Dat is meer dan wat jij getest hebt!
Dat iets niet op internet te vinden is betekent niet dat het niet waar is. En je kan met elk programma gewoon een SSD defragmenteren. Ze geven alleen vaak een waarschuwing.
Ik heb ook met mijn auto geen botstest gedaan tegen een betonnen muur. Dit omdat dit ook veelvuldig getest is, en ik er dus vanuit ga dat het niet nodig is.
Maar als het voor jou werkt, prima. Alhoewel ik mij afvraag of er geen andere factoren zijn die de testresultaten op een of andere manier beinvloeden. Aangezien jij vooralsnog de enige bent die tot positieve testresultaten komt met ssd defragmentatie naar mijn weten. ;)
Ik file share veel en heb liever een gewone 1TB HDD voor al mijn anime en games.
ik heb ook alles op een NAS staan, met een taak om nog eens automatisch te backupppen

Maar als werkschijf wil ik toch liever een SSD.
Een HDD zorgt voor een enorme IO-bottleneck, zelfs voor internet
Ik ben een beetje een leek op dit gebied, maar kan/mag ik dit samenvatten als:
Als consument kan je het beste puur naar de prijs kijken?
Bedankt voor de uitleg. Was inderdaad moeilijk om een beeldvorming te krijgen.
denk aan een ZFS cache, dan weet ik wel welke SSD's ik nu dus links moet laten liggen.
Waarom? Sample size = 1. Dit zegt niet zoveel over de levensduur van grotere aantallen schijven.
Dat kan je niet zo makkelijk stellen. Je moet ook naar de gebruikte technologie kijken en wat de oorzaken en voorspelbaarheid van falen zijn.
De SSDs hebben intern al foutcorrectie en redundantie. Dat wordt gebruikt, dus daarmee is je sample size al een stuk groter.

Tuurlijk, meer is altijd beter, maar je kan dit resultaat niet gelijk waardeloos noemen.

[Reactie gewijzigd door Durandal op 13 maart 2015 12:29]

Het is nog steeds maar een exemplaar. Leg daarnaast het gegeven dat de oem fabrikanten nog wel eens van memory willen wisselen (en soms zelfs onder hetzelfde typenummer naar een kleinere featuresize gaan), dan heeft zo'n onderzoek weinig bewijskracht.
Daarmee heeft downtime wel gelijk, maar onafhankelijke data over betrouwbaarheid van ssd's is zo schaars dat ik deze cijfers toch mee zou laten wegen.
Sample size = 1? Als je statistiek wil toepassen, dan moet je natuurlijk wel je sample grootte goed meten. Dit zijn allemaal multi-chip devices, en er is gemeten totdat het gemiddelde aantal fouten per chip c.q. het totaal aantal fouten de redundancy-grens overschreed.
Je demonstreert nu waarom Churchill al over "lies, damned lies, and statistics" sprak. Ga je bij het testen van een harddisk ook beweren dat de sample size voldoende is als er miljoenen sectoren getest worden?
gezien ik van de genoemde SSD's (behalve de melding van samsung zelf) weinig gehoort heb over bit-rot etc. Als je hier OCZ vertex noemt kan bijna iedereen dat fiasco nog wel heugen. Vaak meerdere ssd's die binnen een paar maandjes normaal gebruik de geest gaven of veel fouten gaven.
Nee, hieraan kan je geen conclusies trekken omdat er maar 1 SSD per merk is getest.
Wel geeft de techsite toe dat door de beperkte hoeveelheid ssd's die er zijn getest er geen definitieve conclusies over de levensduur van de geteste drivetypes zijn te geven.
Kan iemand misschien de math doen hoe veel jaar je als gemiddelde consument doet met zo'n SSD?
Corrigeer me alsjeblieft als ik het fout heb, maar ik kom bij 2,4PB uit op het volgende uit:

(Overzicht hieronder houdt geen rekening met het vroegtijdig falen van de schijf. Tevens wordt er geen rekening gehouden met de grootte van de schijf. Dit is puur informatief bedoeld en verschilt per SSD en grootte en omstandigheden waarin deze gebruikt wordt)

300 MB per dag: 21917 jaar
500 MB per dag: 13150 jaar
1 GB per dag: 6575 jaar
2 GB per dag: 3287 jaar
5 GB per dag: 1315 jaar
10 GB per dag: 657 jaar
20 GB per dag: 328 jaar
50 GB per dag: 131 jaar
100 GB per dag: 65 jaar
200 GB per dag: 32 jaar
500 GB per dag: 13 jaar

Zoals je kan zien is er zelfs bij hevig gebruik, meer dan tijd zat om die schijf voor minstens 10 jaar te gebruiken.

[Reactie gewijzigd door IMJP op 13 maart 2015 14:00]

500 GB per dag: 13 jaar
Die Samsung waren 250GB schijfjes. Wat je hier zegt is elke dag 2 keer volledig beschrijven en dan 13 jaar lang. Lijkt niet echt realistisch :)

Ze zeggen dat een heftige gebruiker zo'n 10 GB per dag schrijft, dus dan 657 jaar. Niet genoeg voor Methusalem want die werd 969 jaar maar wel voor een gewone gebruiker.

Overigens vermoed ik dat de schijf ook wel eerder dan 657 jaar stuk zal gaan maar dan door materiaal veroudering (kapot gaan van tinnen soldeer verbindingen, uitelkaar vallen van plastic onderdelen, weg corroderen van koper baantjes en zo). Niet door falende geheugen cellen.

Een roterende disk is denk ik nog veel sneller stuk, daar zouden ze deze test ook eens voor moeten doen.
[...]

Een roterende disk is denk ik nog veel sneller stuk, daar zouden ze deze test ook eens voor moeten doen.
De meeste HDD's hebben een MTBF van 1.000.000 uur. Bij volcontinue gebruik is dat ongeveer 114 jaar.

Komt dus niet echt in de buurt van een SSD qua betrouwbaarheid. Wat ook weer niet zo raar is, ivm de bewegende delen etc.
[...]


De meeste HDD's hebben een MTBF van 1.000.000 uur. Bij volcontinue gebruik is dat ongeveer 114 jaar.
Zo werkt MTBF dus niet.
Dit betekent dat als je 1.000.000 disken in bedrijf hebt, dat er gemiddeld eentje per uur stuk gaat; dus elke 1.000.000 bedrijfsuren gaat er gemiddeld een disk stuk. Dat kan dus ook al na een paar uur zijn. Over individuele disken is zo'n MTBF hooguit een indicatie maar geen garantie.

[Reactie gewijzigd door wurtel op 13 maart 2015 13:03]

nou volgens mij geld het gewoon per disk, en het is een gemiddelde tijd tussen storingen per disk. Dus ja hij zou na een uurtje al een failure kunnen hebben. maar het is geen garantie dat als je er 1000000 hebt dat er per uur 1tje stuk gaat.
in een gemiddeld geval gaan 1000000 dus ook 1000000 uur mee en zal er volgens een bepaalde normal verdeling ervoor en erna disks een failure hebben.
En MTBF is dus best een goede indicatie voor de robuustheid van een disk echter het is geen garantie
Nou da's dan ook toevallig, dat al die verschillende disks, met verschillende componenten in een verschillende kast bij verschillend gebruik allemaal dezelfde MTBF hebben. Ben benieuwd hoe dat komt..

Het is een bekend gegeven dat die MTBF bij HDDs eigenlijk nergens op gebaseerd is. Het is een wilde gok. Natte vingerwerk en een mooi getal dat die fabrikanten mooi uit komt en omdat ze allemaal dezelfde gebruiken kraait er geen haan naar.

Je kan dit natuurlijk nooit testen, en ook niet als je zaken als opwarming e.d. toe past.

Wat je wel kan doen is naar bedrijven met veel disks kijken, zoals Google en Backblaze en dan ga je zien dat een HDD het gemiddeld maar een paar jaar vol houdt; ongeveer 110 jaar korter dan die 114 jaar.
[q]Wat je hier zegt is elke dag 2 keer volledig beschrijven en dan 13 jaar lang. Lijkt niet echt realistisch[q]

Dat hangt erg van de toepassing af. Als je de schijfjes inzet als database logs voor een database waar intensief geschreven wordt dan is 500GB/dag of meer best haalbaar. Ook bij inzet als ZIL (ZFS Intent Log) op een storage box waar intensief geschreven wordt is dit haalbaar.

Als je server/storage 5 jaar mee moet dan kom orde van grootte in dezelfde richting, bij 1000GB/dag heb je nog een levensduur van 6,5 jaar, en minder als je een slecht exemplaar treft.
Dat hangt erg van de toepassing af. Als je de schijfjes inzet als database logs voor een database waar intensief geschreven wordt dan is 500GB/dag of meer best haalbaar.
Maar toch niet op een 250GB schijf? Je kan wel een array van 250GB schijven hebben, maar als je je database log telkens zo veel laat schrijven per dag op die ene schijf dan heb je dus accuut een probleem als je log backup er een halve dag uit ligt want dan is je schijf vol.

Ben wel benieuwd wat voor toepassing dag in, dag uit, 500 GB aan log data produceerd, dat is best wel heel erg veel. Zeker als dat ook nog 24/7 zo door gaat en door gaat. Grote cloud diensten als Google, Azure en Amazon misschien maar ik denk zelfs dat die vooral schrijven maar die data niet meteen dezelfde dag weer wissen en opnieuw schrijven.
Groot datawarehouse, transactie/boekings systemen. 500GB/dag aan mutaties is niet uitzonderlijk meer dezer dagen. Google, Azure en Amazon verweken daar een aanzienlijk veelvoud van.

Met 500MB/s kun je 500GB in 16 minuten en 40 seconden schrijven in theorie. Dus je hoeft geen 24/7 datastroom te hebben om 500GB/dag te halen. Als je 1,2% van de throughput van de schijf gebruikt gemiddeld dan ben je er al.

Het probleem met de log backups zie ik niet zo. Na een checkpoint kan de log ruimte weer hergebruikt worden. In elk geval bij een Oracle database, voor SQL Server en DB2 zou ik dat na moeten zoeken.
Groot datawarehouse, transactie/boekings systemen. 500GB/dag aan mutaties is niet uitzonderlijk meer dezer dagen. Google, Azure en Amazon verweken daar een aanzienlijk veelvoud van.
Het is normaal de bedoeling dat je data opslaat in een datawarehouse. 500GB/dag aan mutaties is niet uitzonderlijk maar wel als het binnen dezelde 250GB gebeurd. Want het gaat niet over 500GB in het algemeen maar 500GB wegschrijven op een enkele 250GB SSD, dat is 2x per dag volledig beschrijven. Dus niets bewaren, puur als tijdelijke opslag.
Met 500MB/s kun je 500GB in 16 minuten en 40 seconden schrijven in theorie. Dus je hoeft geen 24/7 datastroom te hebben om 500GB/dag te halen. Als je 1,2% van de throughput van de schijf gebruikt gemiddeld dan ben je er al.
Ik heb het niet nagerekend, maar ga er even van uit dat het klopt. Dan nogmaals, het gaat over 1 enkele schijf. Dat lijkt alleen van toepassing als je dat schijfje gebruikt als tussentijdse cache. Bij een dergelijk system zou ik de data lekker in het geheugen houden en daarna meteen wegschrijven naar de eindbestemming in plaats van eerst op een SSD schrijven en het er vervolgens bijna meteen weer afhalen en wissen. Klinkt als een hoop tijdverspliing.
Het probleem met de log backups zie ik niet zo. Na een checkpoint kan de log ruimte weer hergebruikt worden. In elk geval bij een Oracle database, voor SQL Server en DB2 zou ik dat na moeten zoeken.
Die is lekker! Ja, de log kun je hergebruiken maar een roll forward samen met de laatste full backup kun je dan vergeten want daar heb je alle log informatie sinds de vorige full backup voor nodig. Leuk voor een systeem met simple recovery, maar niet bij full recovery (tenminste wil het zinvol zijn).

Wil je bij een crash de data zo veel mogelijk herstellen dan heb je de laatste full backup nodig + alle transactie data sinds die backup. De log overschijven is dus geen goed idee als de data je lief is.

Ik zie best systemen met veel data, maar zie nog steeds niet zo'n systeem een enkele SSD zo bruut mishandelen. Dat hebben ze gedaan bij deze test en daarmee koste het nog 1 1/2 jaar tijd. Bij systemen met zo veel data is dat verspreid over veel en veel meer storage. En een partoon van met dat volumen constant schrijven en wissen van en schijf zie ik al helemaal niet. Dan zouden mechanische schijven al helemaal onbruikbaar zijn.
Het is normaal de bedoeling dat je data opslaat in een datawarehouse. 500GB/dag aan mutaties is niet uitzonderlijk maar wel als het binnen dezelde 250GB gebeurd. Want het gaat niet over 500GB in het algemeen maar 500GB wegschrijven op een enkele 250GB SSD, dat is 2x per dag volledig beschrijven. Dus niets bewaren, puur als tijdelijke opslag.
Dat is, bij een Oracle database, precies wat de redo logs doen. Tijdelijke opslag. Bij een data warehouse van vele TB kunnen de redo logs best tweemaal per dag overschreven worden en zelfs wel vaker. Die terabytes zet je dan op gewone schijven, de logs op SSD.
Bij een dergelijk system zou ik de data lekker in het geheugen houden en daarna meteen wegschrijven naar de eindbestemming in plaats van eerst op een SSD schrijven en het er vervolgens bijna meteen weer afhalen en wissen.
Voor Oracle redo logs of een ZFS intent log is dit helemaal geen tijdverspilling. De functie van deze logs is namelijk dat je de gegevens nog hebt als de stroom er af gaat. Dat lukt niet met intern geheugen. Om toch snel te zijn schrijf je ze zolang naar SSD.
Wil je bij een crash de data zo veel mogelijk herstellen dan heb je de laatste full backup nodig + alle transactie data sinds die backup. De log overschijven is dus geen goed idee als de data je lief is.
Bij een Oracle database werkt dat anders. De redo logs zijn echt alleen nodig totdat ze gecheckpoint zijn. Als je point in time recovery wil doen dan worden de redo logs afgesplitst naar archive logs, die staan doorgaans op een ander medium. Je full backup samen met archive logs gebruik je voor recovery. Redo logs gebruik je bijvoorbeeld bij een instance failure, maar niet voor volledige recovery.

Je hebt vast gelijk voor zover het SQL Server betreft, maar ik had het, zoals ik aangaf, over Oracle.
Dat hangt erg van de toepassing af. Als je de schijfjes inzet als database logs voor een database waar intensief geschreven wordt dan is 500GB/dag of meer best haalbaar. Ook bij inzet als ZIL (ZFS Intent Log) op een storage box waar intensief geschreven wordt is dit haalbaar.

Als je server/storage 5 jaar mee moet dan kom orde van grootte in dezelfde richting, bij 1000GB/dag heb je nog een levensduur van 6,5 jaar, en minder als je een slecht exemplaar treft.
Dat is natuurlijk wel een kromme redenatie, dit zijn consumentenschijven. Sowieso ben je niet handig bezig als je in een server setup geen raid gebruikt, zelfs met SSD's :)
Die 840 Pro is toch net als Intel's SSDs geen consumenten schijf? Wel populair, want redelijk geprijsd.
Ja wel, de 843T is de MLC enterprise versie van de Pro.
Artikel met een disclaimer voorzien :) Helaas heb ik niet de technische know-how om hier diep op in te kunnen gaan.
Mijn ervaring is dat een SSD na een jaar of 2/3 er al mee op kan houden.
Stroomonderbrekingen zijn ze erg gevoelig voor.
In dat geval kun je je geld beter investeren in een simpele UPS. Heb zelf ook een simpele APC thuis staan, omdat in het verleden bij en korte storing ook 2 disks de geest gaven. Voor zo'n 100 euro heb je een heel behoorlijk ding wat één PC zo'n 20 minuten up houdt.
Probleem bij mij is dat ik veel bezig ben met overclocking en dergelijke en als de PC dan crashed of handmatig uitschakeld heb je zo weinig aan een UPS
Mjah, het is niet alleen plotseling stroom onderbrekingen. Ook gewoon uit staan kan er voor zorgen dat de huishouding-taken er niet op tijd bij zijn voordat de gegevens uit de flash cellen zijn gelekt. Voor verse flash chips garanderen ze een jaar op de plank, maar dat gaat achteruit bij gebruik. Tijdens de werking zal de schijf automatisch z'n opslag testen (zeg maar 'scrubben') en wanneer er herstelbare leesfouten optreden deze verplaatsen naar een andere lokatie.

[Reactie gewijzigd door Henk Poley op 13 maart 2015 13:19]

Natuurlijk kan hij er ook al na 2-3 jaar mee ophouden, net als een HDD het al na een week kan begeven (vaak genoeg meegemaakt). Dan heb je het echter wel over de uitzonderingen (je hebt altijd maandagochtend-exemplaren), niet over de regel.

In de regel zal een SSD aanzienlijk langer meegaan dan 2-3 jaar, bij normaal gebruik althans.
Heel erg veel jaar gok ik zo, vermoedelijk meer jaar dan dat de gemiddelde consument met zijn gehele PC doet.

Het is niet voor niets dat Samsung tegenwoordig 5 jaar garantie op zijn SSD's geeft, dat geeft aan dat die bij gemiddeld gebruik dus minstens 5+ jaar mee zou moeten kunnen gaan.
Mijn OCZ Vertex (2009) heeft nog 92% Health en die word gebruikt voor Opslag van Game Mods.
Dat is niet af te leiden uit deze test, je kan hooguit beredeneren dat je SSD niet aan de hoeveelheid schrijfactief ten onder zal gaan.
In het bron artikel staat dat 100TB per jaar erg veel is. Dus tussen de 7-10 jaar zou wel moeten lukken bij zwaar desktop gebruik.
Je weet maar nooit wat zonder dat je het weet geschreven wordt op je C schijf. Als je kijkt hoeveel cache Google Chrome weet weg te schrijven op mijn C schijf.... Ik probeer het verder gewoon zoveel mogelijk te beperken en hopen dat mijn SSD het zo lang mogelijk volhoud.

Maar ach, tegen de tijd dat ie op is zal 250GB SSD niet meer voldoende zijn en ik al lang een nieuwe hebben gekocht. :P
chrome zal geen terrabytes produceren, hoogstens enkele 10 tallen gigabytes in de levensduur van je pc..... Dingen als wisselbestand bij een ramm tekort zal veel harder lopen.
Ik heb ook mijn pagefile verhuisd naar mijn snelle hdd om het aantal schrijfacties te verminderen..dat is volgens mij ook redelijk common practice.
Deze blog op MSDN beweert anders het tegendeel:

Should the pagefile be placed on SSDs?
Yes. Most pagefile operations are small random reads or larger sequential writes, both of which are types of operations that SSDs handle well.
In looking at telemetry data from thousands of traces and focusing on pagefile reads and writes, we find that
  • Pagefile.sys reads outnumber pagefile.sys writes by about 40 to 1,
  • Pagefile.sys read sizes are typically quite small, with 67% less than or equal to 4 KB, and 88% less than 16 KB.
  • Pagefile.sys writes are relatively large, with 62% greater than or equal to 128 KB and 45% being exactly 1 MB in size.
In fact, given typical pagefile reference patterns and the favorable performance characteristics SSDs have on those patterns, there are few files better than the pagefile to place on an SSD.

[Reactie gewijzigd door misterbennie op 13 maart 2015 12:53]

Thanks, goede bron! Dan lijkt het erop dat ik mogelijk toch beter af ben door het daar te plaatsen.
Gezien de resultaten van de hierboven uitgevoerde test zal een SSD er niet kapot van gaan (niet binnen 200 jaar), dus waarom niet.

Je wilt de data uit je paging file zo snel mogelijk in je geheugen hebben.
En hoe snel je HDD ook is, die kan nooit tegen een SSD op.
Dat zie ik nu ook in inderdaad, het was bij mij ook deels uit ruimtebesparende overwegingen. Ik heb maar een 64Gb ssd. Dus na ntfs format, windows en primaire / secundaire programma's hou je weinig ruimte over voor iets anders. Heb bijvoorbeeld ook hibernate uitstaan, bespaard ook weer de gelijke grootte van je RAM op je schijf.
De downloads van Windows update ook eens verwijderd?
Onlangs nog iemand mee geholpen, z'n ssd zat vol en *poof* opeens weer 8+GB ruimte. :P
(C:\Windows\SoftwareDistribution\Download -> alles in die folder mag weg)
Een veiligere methode onder Windows 7 met KB 2852386 is volgens mij:

Windows Explorer -> C: -> Rechtermuistoets -> Eigenschappen -> Knop 'Schijfopruiming' -> (even wachten op berekening... pizza! ...) -> Windows Update opschonen -> aanvinken -> OK knop

Meer info: http://www.infoworld.com/...ace-on-your-c--drive.html
Wat op sommige pc's wel een uur kan duren :+ (Been there, done that)

Overigens: Als je de windows update service uitzet en die SoftwareDistribution map zelf verwijdert en weer de service aanzet dan maakt hij al de nodig files weer aan. Handig bij het fixen van vreemde Windows update problemen.
Even gekeken uit nieuwsgierigheid, na drie jaar gebruik slechts 132MB groot, zet niet echt veel zoden aan de dijk.
Geen idee waarom, maar bij sommigen wordt dit eens opgeruimd en bij anderen niet. (of heb je zelf al eens ccleaner etc gebruikt?)

[Reactie gewijzigd door SmokingCrop op 13 maart 2015 18:20]

Ik verwijder die 1x in de zoveel tijd met CCleaner, maar zeker een goede tip inderdaad.
Kan je dat ding niet ergens anders laten plaatsen?
Leuke statistiek maar onvolledige sector writes resulteren op een SSD in een read-erase-write cycle (soms read-erase-erase0or1-write afhankelijk van het type flash en implementatie) voor de gehele sector en niet alleen het onderdeel dat veranderd. Ik weet dat er caching gebruikt word maar dat lost het vele lees/schrijf probleem met kleine hoeveelheden data niet in zijn geheel op.

Ofwel voor iedere sector van 4K die beschreven word (voor 67% van de gevallen <= 4K) dan krijg je al snel veel (re)writes op 4k sectoren voor minder dan 4k aan data. Dit is altijd nadelig tov. de write cycle count omdat bij een write naar dezelfde sector op de rest van de data hij opnieuw een volledige write doet op alles.

Bij de "pro" schijven met behoorlijke backup gedeeltes en dito capabele reallocation/wear leveling algoritmes zou ik me er niet druk om maken, maar bij de goedkoper varianten vrees ik dat het je schrijf niet ten goede komt.
Het 67% cijfer wat jij quote is voor 4kB reads, niet 4kB writes ! Dat zou ook niet kunnen, want 45% van de writes zijn exact 1 MB, dus dan blijft er maar 55% over voor alle andere writes.

Uit het feit dat 62% van de writes meer dan 128 kB zijn, kunnen we zelfs afleiden dat 4 kB writes niet eens boven de 38% komen en waarschijnlijk ver daaronder.
Het blijven relatief veel writes op beperkte bestanden, met extra wear indien kleine writes plaatsvinden. Als er bezuinigd is op de wearleveling algoritmes dan is het nog steeds een groot risico. Bovendien is de failure op een cluster meestal ook een failure op een grotere groep clusters dus wordt een gedeelte van de chip 'onklaar' gemaakt.

Desalniettemin verwacht ik dat in de toekomst (lees enkele jaren) alle SSDs de testen zoals in het artikel beschreven met vlag en wimpel halen en daarna is het helemaal geen probleem meer.
Je quote nu uit een artikel van ruim 5 jaar oud (2009). Volgens mij zijn een aantal stellingen inmiddels achterhaald.
Zou best kunnen, maar de stellingen zijn nu nog verder doorgeslagen richting SSD.

Feit blijft dat je je page file het beste op je SSD kunt zetten en dat die daar niet kapot van zal gaan.
damn, ik las te snel, excuus- ik dacht dat je een artikel noemde dat juist tegen plaatsen op ssd was. Ik trek mijn reactie bij deze terug 8)7
Maar het is wel weer 8 GB (of meer/minder) ruimte op een (vaak) al krappe SSD :P Dat is volgens mij de grootste reden dat mensen de pagefile op een andere disk zetten.

[Reactie gewijzigd door garriej op 13 maart 2015 13:46]

Je moet een SSD dan ook vooral gebruiken voor taken waar die goed in is. En een daarvan is de snelheid bij random access. Een andere is sequentiële writes/reads.

Zet je operating system en paging erop (hibernate zou ook kunnen omdat je weer sneller uit de slaapstand kunt komen) en zet de rest op een normale HDD.
Edit - reactie bij verkeerde tekst geplaatst.
De pagefile niet op je ssd plaatsen komt uit de tijd dat ssd opslagruimte behoorlijk wat kostte.
Want een 16 gigabyte pagefile op je duur betaalde schijfje van 40 of 60 gigabyte was natuurlijk geen optie:) (dat was t wel maar dat deed ik liever niet)

[Reactie gewijzigd door biebelebons op 13 maart 2015 13:58]

En zelfs dan zal het niks zijn in vergelijking met de stresstest die ze hiermee gedaan hebben. Uitval van SSD's door veel te schrijven zul je je pas na 5-10 jaar aan intensief gebruik zorgen over moeten maken.
Ach dat is allemaal erg weinig. Gebruik gewoon iets als CrystalDiskInfo om te zien hoeveel GB/TB je al geschreven hebt. Ik zit na bijna 3 jaar op 18TB met m'n Samsung 830 256GB..
En dat is dan voornamelijk door de vele tests en aanmaken van besturingssystemen op virtuele machines en dergelijke..

Je moet al serieus je best doen, om als consument ooit aan die waardes te geraken. Meer kans dat er iets anders misloopt.

[Reactie gewijzigd door SmokingCrop op 13 maart 2015 13:30]

Ik heb net ook even gekeken met CrystalDiskInfo.

Toevallig heb ik een Samsung 840Pro 256GB. Precies dezelfde SSD als in de test. Ik heb de mijne 2 jaar geleden gekocht. Voornamelijk omdat ik een stille machine wil. Windows, Users en games op de SSD. Films, muziek, backup en andere troep op de HDD. Pagefile heb ik op de SSD, maar minimaal. Hybernation staat uit.

Na twee jaar, dagelijks gebruik:

Total Host Writes: 2.76 TB.
Power on Count: 858
Power on Hours 9254 hours.

De Samsung 840Pro 256GB uit de test hield er na 2.4 PetaBytes mee op. Ik zit op ongeveer 1 duizendste daar van. Dus de verwachte levensduur van mijn SSD is ongeveer 2000 jaar !

Hier kun je CrystalDiskInfo downloaden:
http://crystalmark.info/download/index-e.html
Ik heb zelf ook de Samsung 830 256 GB en ik zit op 21.48TB. De ssd heb ik ook ongeveer 3 jaar geleden aangeschaft. Werkt nog perfect. Hoop dat de prijzen van SSD dalen, zodat 2TB SSD betaalbaar worden.
Zou je je computer niet gewoon uit laten staan? Weet je zeker dat 'ie zo lang mogelijk mee gaat.

Als een programma veel disk I/O doet, is het JUIST verstandig dat naar je SSD te doen, dat gaat ten minste lekker snel.
Samsung heeft daar een mooi tooltje voor, Magician. Ik lette in het begin extreem op wat ik er allemaal op zette, maar tegenwoordig boeit het me niet zo veel meer.
Beetje jammer dat deze tests zo lang duren. 18 maanden na release zijn er wel weer nieuwe SSD's beschikbaar. :P
Die SSD's hebben gewoon 18 maanden non-stop zitten schijven, dag in dag uit. Het duurde gewoon zo lang tot de laatste ermee op hield.
Ja dat snapt hij ook wel, neemt niet weg dat het dus jammer is dat je niet van de SSD's van vandaag de dag kan zien wat de resultaten zijn...

Hoewel je er stiekem van uit mag gaan dat die de oude overtreffen :)
Stiekem wel, maar toch ook weer niet. Kijk bij Samsung naar het verschil tussen de evo en de pro of de overgang naar 3D. Echt wezenlijk andere technieken waarbij ook de lange termijn effecten anders kunnen uitpakken.
Hoewel je er stiekem van uit mag gaan dat die de oude overtreffen :)
Nee, dat mag je juist niet.

In Den Beginne wist men niet hoe lang dit soort dingen het in de praktijk uit houden. Nu bekend is dat ze het veel langer uit houden dan ze gebruikt zullen worden kunnen fabrikanten rustig op bepaalde onderdelen gaan besparen.
Je kunt er dus van uit gaan dat moderne SSDs korter mee zullen gaan dan hun oudere collegae. Waarschijnlijk wel betrouwbaarder maar minder lang. Tenslotte hoeven ze helemaal geen 200 jaar mee te gaan.
Aan de andere kant is dat ook weer positief.
De kans is groot dat je je SSD al vervangt omdat hij hopeloos verouderd is, voordat hij overlijdt.

Zelfs de slechtste schijf kon 2500 keer volledig volgeschreven worden.
Beetje jammer dat deze tests zo lang duren. 18 maanden na release zijn er wel weer nieuwe SSD's beschikbaar. :P
Daarom doen ze vaak dit soort tests bij 'extremere condities'.
18 maanden op kamertemperatuur komt dan bijvoorbeeld overeen met 3 maanden op 80 graden.

Vooral als je kijkt naar slijtpatronen bij mechanische onderdelen kan het zinnig zijn. Helaas is sommige elektronica weinig gevoelig voor de temperatuur als deze constant is. Dan schiet je er weinig mee op.
Ik vind het niet zo erg hoor, mooie bevestiging dat ik een goede aankoop gedaan heb :)
Ik vind de conclusie een beetje kort door de bocht er zijn maar 4 ssd's getest. De conclusie dat er 1 het meest betrouwbaar is doordat deze de meeste writes aan kan is ook incompleet. Er spelen veel meer factoren mee voor de betrouwbaarheid van een ssd.
Zie dit uitmuntende artikel hierover van een mede tweaker.
CiPHER's Storageblog: SSD betrouwbaarheid
Dit artikel gaat niet over betrouwbaarheid, dit artikel gaat over na hoeveel writes een SSD de geest geeft. Dat is maar 1 aspect van betrouwbaarheid. En CiPHERs artikel is gewoon wat info van her en der bij mekaar gebracht. Niets zelf getest.
Er staat in dit artikel van tweakers:
"De Samsung 840 Pro is volgens Tech Report de meest betrouwbare ssd"

Ik begrijp van Teejoow dat TR gelukkig de juiste kanttekeningen plaatst bij dit onderzoek.
Dat doet verder niet af aan mijn commentaar op dit artikel van tweakers.

Ik zou het artikel van Cipher niet afdoen als maar wat bij elkaar geraapte info. Maar daar kunnen we uiteraard een meningsverschil over hebben.

[Reactie gewijzigd door kaaas op 13 maart 2015 14:26]

Ik lees ook nergens in het artikel van TR dat ze zeggen dat die 840 pro het meest betrouwbaar is. Ze geven zelf ook eerlijk toe dat je niks zinnigs kan zeggen over een individuele drive. Je kan net dat ene exemplaar hebben wat het veel langer volhoudt dan zijn soortgenoten.

Sterker; over de Samsungs zeggen ze nog dat die drives geen SMART waarschuwingen gaven voordat ze de pijp uit gingen, wat wel een beetje eng is.

Kortom, de conclusie in dit artikel is een andere dan die van TR.
Dank hiervoor ik heb het artikel van TR niet gelezen gelukkig plaatsen die dus wel de juiste kanttekeningen.
Ik vind de conclusie een beetje kort door de bocht er zijn maar 4 ssd's getest. De conclusie dat er 1 het meest betrouwbaar is doordat deze de meeste writes aan kan is ook incompleet. Er spelen veel meer factoren mee voor de betrouwbaarheid van een ssd.
Zie dit uitmuntende artikel hierover van een mede tweaker.
CiPHER's Storageblog: SSD betrouwbaarheid
Er zijn er 6 getest. Maar twee de 840 pro en HyperX worden separaat besproken omdat deze de andere 4 disk gewoonweg te boven gingen.
Wat vinden jullie van de failure mode van de Intel 335 SSD:
The drive's media wear indicator ran out shortly after 700TB, signaling that the NAND's write tolerance had been exceeded. Intel doesn't have confidence in the drive at that point, so the 335 Series is designed to shift into read-only mode and then to brick itself when the power is cycled.
Als ik het goed begrijp is het dus vitaal dat intel 335 SSD eigenaars alerts zetten op SMART attribuut 177 (Wear leveling count). Want je hebt maar 1 kans om je data te evacueren wanneer deze waarde 0 bereikt. Je mag niet rebooten !!! :(
Mjah snap ook niet echt waarom hij eerst in read-only mode schiet en vervolgens na een reboot gelijk gebricked is. Blijf dan gewoon ook na een reboot in read-only mode zou ik zo zeggen.
Vreemde keuze.
Inderdaad, en het zou wel is het veld kunnen openen voor mogelijke afpersing:
Je moet dan mogelijk dienst doen op Intel's SSD's "Recovery" Services. }>
De enterprise versie blijft gewoon beschikbaar in read only mode, ook nadat je de stroom afzet.

Vermoeden: misschien gaat Intel ervan uit dat iedereen backups heeft. Het feit dat ze de schijf uitschakelen voordat er fouten optreden, laat vermoeden dat Intel liever heeft dat je een backup terugplaatst dan dat er datacorruptie optreedt die je kopie op een nieuwe schijf of je inderhaast gemaakte backup naar de bliksem helpt. Maar een enterprise weet beter wat ze aan het doen zijn op dat vlak, en aan een bedrijf kun je niet vertellen dat je met opzet hun gegevens ontoegankelijk hebt gemaakt indien er iets is misgelopen met de meest recente backup. Dat kan het verschil verklaren.

Of misschien is het gewoon productdifferentiatie.

[Reactie gewijzigd door Enai op 13 maart 2015 13:38]

Gave test! Ben eigenlijk wel benieuwd naar tests waar ze constant de stroom laten wegvallen om te zien hoeveel klappen ze daarvan kunnen verduren.. in mijn geval begint de crucial m4 steeds meer kuren te vertonen. Althans het lijkt daardoor te komen bij een gebrek aan andere problemen.
want bij jou systeem valt constant de stroom weg ? Dan zou ik niet zo snel naar de SSD kijken maar eerst het hele wegvallen oplossen...
De meeste computers staan op plekken waar mensen het niet zo nauw nemen met voorzorgs maatregelen voor een langdurige levensduur van je computer.

De PC bot uitdrukken want "geen zin om te wachten" gebeurt vaak en daar moet een SSD ook goed tegen kunnen. Als de SSD's al kans op kuren hebben na 1 random power-off..... geen goed nieuws.
Ja. Moeten ze ook bij auto's doen, want mensen stappen al rijdend uit de auto voordat deze is geparkeerd omdat ze geen zin in wachten hebben. Dus moeten de auto's ook een crash staminatest ondergaan.
Gebeurt ook regelmatig dat mensen dat doen. Maar is niet vergelijkbaar.
Ik heb een paar huisgenoten die denken dat het niet uitmaakt als er water in een stekkerdoos valt.. -》kortsluiting.. :p
tsjah dat kan inderdaad een keer gebeuren, waarna je het natuurlijk oplost zodat het niet meer voorkomt... Of je huisgenoten erop attenderen, of de stekkerdoos verplaatsen of hier een plastic tasje om doen...
Een test om te kijken hoe vaak een ssd zo'n klap kan krijgen komt simpelweg niet overeen met een "doorganse" levenscyclus van zo'n ding...
Ik heb mijn PC op klik aan/klik uit, regelmatig dat ik hem vergeet netjes uit te zetten, dus voor mij is het toevallig wel interessant, en zeggen dat ik dan maar beter op moet letten maakt geen verschil, ik ben me er van bewust (dat het slecht is) en toch gebeurd het 1 keer per week...

Teller staat op 200 keer heb de schijf nu ongeveer 2 jaar...
En dat doen ze constant? Rare jongens, die huisgenoten (of meisjes?).
Of mensen die beschonken thuis komen en daardoor slordig zijn of meiden die thee drinken en die lekt/schiet uit. Ik heb 15 huisgenoten waarvan een aanzienelijk deel behoorlijk onhandig is (vind ik).

Ik denk dat het elke maand wel 1 keer voorkomt.
XD lol ik denk dat ik mijn 840 pro dan maar op prestaties ga zetten... Echt bizar. :) ik denk indd dat je als normal persoon dit nooit haalt voordat je al 10 keer een nieuwe Computer heb gekocht ...
Het is zelf al moeilijk om die officiële minimum van 75 à 150TB te halen voor je alweer 10+ jaar verder zit ;)
Ik zit nu op 10 TB :) dus zo moeilijk is het niet...
na hoeveel tijd? ;)
Dan eens vermenigvuldigen en dan zie je dat de minimum van 75-150TB best lang duurt.
Tegen dan zijn sata 600 ssd's al weer zo oud als IDE's van vandaag.
Zal allemaal via PCIe gaan lopen ^^

[Reactie gewijzigd door SmokingCrop op 13 maart 2015 15:41]

Zouden ze hier ook de snelheids test op losgelaten. Dit omdat samsung voor een tweede keer een bericht heeft los gelaten over oude data?
Dat gaat over de 840 ;) dit is de 840 PRO. Das een ander product die niet geraakt wordt door die bug.
Ik ben benieuwd hoeveel heads-up je krijgt met SSD. Met USB-sticks heb ik geen goede ervaring: het ene moment doet ie het nog, het andere moment volledig rot.

Met de oude harddisks/floppy disks had je van die programma's zoals spinrite. Niet alleen gaven die aan dat er problemen in op komst waren, maar konden nog de levensduur goed rekken.

Je zou maar aan het werk zijn en floep, einde oefening.
Bij USB flash schijfjes schijnt het vaak 't USB klok-kristal te zijn, dat kan vervangen worden: http://infar.be/index.php...H-drive-drive-repair.html

Spinrite is trouwens onzin. Tenzij je het over heel erg vroeger hebt, toen we nog echt konden low-level formatteren (nog voor SATA, ATA, SCSI & IDE). Spinrite kon daar het spoor dat de schijf opzoekt herschrijven naar een sneller/optimale route, die werd vaak buiten de schijf van te voren beschreven, en klopte dan niet altijd met de afmetingen van de schijf. Praten we over eind jaren 80.

[Reactie gewijzigd door Henk Poley op 13 maart 2015 13:40]

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True