Verwijderd schreef op donderdag 17 februari 2011 @ 16:13:
[...]
Ben je nou gewoon koppig, of snap je het echt niet? Zal ik het proberen in jip-en-janneke taal uit te leggen?
SSDs vertonen corruptie op vele niveau's:
[list]• Verdwenen writes die of in SRAM of in DRAM werden bewaard. Deze writes gaan om bestanden die je recentelijk hebt beschreven. Als de stroom eraf gaat, zijn deze writes verdwenen. Dat is niet erg, voor je HDD geldt hetzelfde. Je filesystem (NTFS) bieden bescherming hiervoor, door in een journal bij te houden wat ze aan het doen waren. Het bestand wat je aan het schrijven was kan verloren gaan, maar je filesystem zou altijd consistent moeten blijven. Geen enkel probleem dus!
Alleen vroeger met Windows 98/ME en FAT filesystem zonder journal was dit een probleem, waardoor er elke keer een disk check moest plaatsvinden om schade te herstellen. NTFS en andere journaling implementaties kunnen veilig disk write-back gebruiken, zolang de disk maar wel de buffer leegschrijft bij een 'flush' commando; de oplossing voor dit probleem om synchrone writes te kunnen doen terwijl de meeste data gewoon asynchroon (snel) wordt geschreven en door de HDD/SSD gebuffered word.
• Bij MLC geheugen moeten beide voltageniveau's opnieuw beschreven worden. Ze kunnen niet beide tegelijk worden geupdate, dus als de stroom uitvalt op het moment dat de onderste laag opnieuw beschreven werd ben je een klein beetje data kwijt in de bovenste laag, die dus mogelijk corrupt kan raken. Nou niet echt een super groot probleem.
• Wat wél een probleem is, is als je problemen krijgt met de HPA mapping table, die het verschil bijhoudt tussen hoe Windows denkt dat bestanden zijn opgeslagen en hoe ze werkelijk zijn opgeslagen (Host->NAND mapping table). Deze tabel wordt in DRAM opgeslagen (ook bij Intel G2) en moet synchroon blijven met de fysieke NAND. Deze tabel wordt regelmatig 'gebackupt' naar NAND, maar niet continu. Als je dus dynamische writes aan het doen bent waarvoor de mapping table wordt aangepast, mag de stroom op dat moment niet uitvallen of je krijgt héle grote problemen. Massale corruptie kan het geval zijn als je mapping table niet meer synchroon is met je NAND. Net als een boek waarbij de inhoudsopgave foutieve paginanummers opgeeft; dat is funest.
Dit gedeelte ben ik met je eens, het hele bestandssysteem kan weggevaagd worden, is op te lossen met een herinstallatie maar natuurlijk niet erg prettig, heb ik hierboven ook al erkend (heb je het wel gelezen?).
• Afhankelijk van de firmware kan een SSD in een baksteen veranderen als er fouten in de HPA mapping table zitten, waardoor de SSD simpelweg niet meer werkt. SSDs kunnen er dus opeens mee ophouden door wegvallen van voltage op net het verkeerde moment.[/list]
[...]
Niet dus.
[...]
Als je SSD 70 graden heet wordt ja. Gelukkig heb je met 75 milliwatt idle verbruik (DIPM) weinig reden om aan te nemen dat de temperatuur hierdoor gigantisch zou stijgen.
Maar als jij deze bescherming voor 1 dollar 50 te duur vindt, dan koop je toch gewoon een van de vele onbeveiligde SSDs? Scheelt je een paar euro en als je corruptie niet erg vindt heb je daar ook geen last van verder. En mocht je SSD 'bricked' raken, dan kun je die altijd nog mooi als sleutelhanger gebruiken.
Je zegt het dus zelf, de oorzaak van het bricken ligt hem dus in de firmware en hoewel een supercap dit kan voorkomen is het niet de juiste oplossing, de firmware moet gewoon goed zijn (je gaat het gevolg aanpakken en niet de oorzaak).
Jammer dat je zo onvolwassen reageert en blijkbaar zelf wat koppig bent, selectief leest of misschien de Engelse taal minder machtig bent, wat niet raar is natuurlijk.
Een stuk uit jouw link:
Loss of data: This can occur due to the implementation of write caching (also called “write back” or “write
behind”) to achieve peak performance. In this case, the host system is informed that a write operation has
completed when in fact it is still in process. If power fails while the controller is “catching up” with the
write operation, the data in the write buffer is not yet hardened and can be lost. When the data is
requested later by the host, the controller can either report the data irrecoverable or (depending on the
controller design) it can deliver a previous “stale” version of those sectors to the host. In the latter case,
this translates to silent data corruption, since the host system is not informed that the data delivered is
incorrect.
Dit is de write cache en wordt zo specifiek benoemt.
Natuurlijk verwelkom ik een supercap, maar het is allemaal wat genuanceerder dan jij beweert en de kosten van het goed implementeren is zeker wel van belang (en hoger dan die 1,50 waar heb je de informatie vandaan dat dat de kosten zijn om een supercap te implementeren?). Gezien de SSD niet buiten de computer hangt (sommige computers dus erg warm worden en deze warmte overbrengen naar de SSD) en niet iedere capacitor 100% zeker blijft werken moet het circuit voor de supercap zeker wel goed over nagedacht worden.
Vergeet niet dat capacitors op hun beurt weer erg gevoelig zijn voor problemen. Ik denk gewoon dat de supercap leuk is, maar nutteloos is al het niet goed geimplemeteerd is. Wanneer dat wel zo is en de ontwikkelingskosten plus productie kosten laag zijn, dan wordt dit ook echt wel geimplementeerd.
i7 12700K,GB WindForce RTX4090,32GB KF436C16RB1K2/32,Gigabyte Z690 UD DDR4,Corsair RM1000x,WD Black SN850 2TB,Phanteks Eclipse P360A,Quest 3 VR Headset,Corsair iCUE H100i RGB Pro XT 240mm