På baksiden har nye konsepter blitt introdusert for å optimalisere ytelsen, levetiden og påliteligheten til disse nye enhetene også. Et slikt konsept er trimoperasjonen.
Oppsett av en SSD
SSD -er er flammende raske og blir raskere og billigere hvert år. Deres pålitelighet har også forbedret seg ganske mye siden oppstarten. Imidlertid er SSD -er fremdeles ikke så pålitelige som magnetiske medier, og de er heller ikke så holdbare som en harddisk. Faktisk er de underliggende lesemekanismene veldig forskjellige fra det man ser inne i en HDD.
For å forstå problemene en SSD lider av, og hvorfor vi trenger trimdrift for å overvinne disse problemene, la oss se på strukturen til SSD først. Data lagres vanligvis i grupper av 4KB -celler, kalt sider. Sidene blir deretter gruppert i klynger på 128 sider, kalt blokker og hver blokk er 512kb, for de fleste SSD -er.
Du kan lese data fra en side som inneholder litt informasjon, eller du kan skrive data til sider som er rene (uten eksisterende data i dem, bare en serie på 1S). Du kan imidlertid ikke overskrive data på en 4KB -side som allerede er skrevet til, uten å overskrive alle de andre 512KB.
Dette er en konsekvens av det faktum at spenningene som kreves for å snu en 0 til 1 ofte er mye høyere enn motsatt. Overskuddsspenningen kan potensielt vende biter på de tilstøtende celler og korrupte data.
Sletting av ytelsen for nedbrytning av en SSD
Når data sies å være 'slettet' Av OS markerer SSD bare alle de tilsvarende sidene som ugyldige, i stedet for å slette dataene. Dette er ganske likt det som skjer i en HDD også, sektorene er merket som gratis i stedet for å bli fysisk nullet ut. Dette gjør slettingsoperasjonen mye mye raskere.
I tilfelle av HDD -er fungerer dette helt bra. Når nye data må skrives, kan du overskrive de gamle dataene på en frigjort sektor uten problemer eller bekymringer for de omkringliggende sektorene. HDDS kan endre data på plass.
Når det gjelder en SSD, er dette ikke så enkelt. La oss si at du endrer en fil og som tilsvarer en endring av en enkelt 4KB -side. Når du prøver å endre en 4KB -side i en SSD, må hele innholdet i blokken, hele 512KB av den, lese i en hurtigbuffer (hurtigbufferen kan bygges inn i SSD, eller det kan være systemets hovedminne) og Da må blokken slettes, og deretter kan du skrive de nye dataene din Target 4KB -side. Du må også skrive tilbake den gjenværende umodifiserte 508 kb data som du kopierte til cachen din.
Dette resultatene legger til fenomenet skriveforsterkning der hver skriveoperasjon blir forsterket til en lesemodifisering-skriveroperasjon for biter av data som er mye større enn de faktiske dataene som må settes på plass.
Opprinnelig dukker ikke denne forsterkningen opp. SSD -en din klarer seg veldig bra i begynnelsen. Etter hvert, når blokker blir fylt opp, oppnås det uunngåelige punktet der flere og flere skriveoperasjoner begynner å involvere den dyre lesemodifisering-skriver operasjonen. Brukeren begynner å legge merke til at SSD ikke presterer så godt som den opprinnelig gjorde.
SSD -kontrollere prøver også å sørge for at dataene er spredt over hele disken. Slik at alle dør får like nivåer av slitasje. Dette er viktig fordi flash-minneceller har en tendens til å slite ut raskt, og derfor hvis vi kontinuerlig bruker de første få tusenvis av blokker som ignorerer resten av SSD, vil de få blokkene bli utslitte snart. Spre data over flere dies forbedrer også ytelsen din, da du kan lese eller skrive data parallelt.
Imidlertid er skriftene spredt, og øker sjansene for at en blokk har en side. Dette akselererer nedbrytningsprosessen ytterligere.
Trim kommando og frigjøring av blokkene
Trim -kommandoen minimerer ytelsesforringelse ved å trimme de ugyldige sidene med jevne mellomrom. For eksempel trimmer Windows 10 din SSD en gang hver uke. Alle dataene som er blitt merket som slettet av OS blir faktisk renset ut av minnecellene av SSD -kontrolleren når den operasjonen kjøres. Ja, det må fortsatt gå gjennom read-modifisering-skriv-operasjonen, men det skjer bare en gang i uken og kan planlegges i timene når systemet ditt stort sett er ideelt.
Neste gang du vil skrive til en side, er den faktisk tom og klar for en direkte skriveoperasjon!
Den faktiske frekvensen av TRIM -kommandoen avhenger av hva slags system du kjører. Databaser har en tendens til å gjøre mye iOS og vil dermed kreve en hyppigere trimming. Imidlertid, hvis du gjør det for ofte, vil databaseoperasjonene avta for perioden når Trim kjører. Det er jobben til en systemarkitekt å finne riktig plan og frekvens.
Begrensninger
TRIM -kommandoen er veldig nyttig for å utsette ytelsesforringelsen av enheten din. Det hjelper med å opprettholde gjennomsnitt ytelsen til enheten din. Men det er bare i gjennomsnitt.
Anta at hvis du jobber med et tekstdokument og kontinuerlig skriver til filen, redigerer du ting ut og sparer slik at du ikke mister noen fremgang. Sidene som lagrer dokumentets data vil fortsatt trenge å gå gjennom den uutholdelige lesemodifisering-skriversyklusen fordi Trim ikke er en tjeneste som stadig optimaliserer SSD-en din. Selv om den kjørte som en tjeneste, vil ytelseseffekten fortsatt være synlig fordi den er innebygd i selve mekanikken i en SSDs operasjon.
Også å kjøre SSD -trim for ofte kan redusere levetiden til lagringen din. Siden all den sletting og skrivesyklus vil slite ut cellene som gjengir dataene som er lagret i dem, skrivebeskyttet seg.
Konklusjon
Til tross for alle manglene ved en SSD pakker den fortsatt store ytelsesfordeler sammenlignet med en tradisjonell harddisk. Når markedsandelen for disse magiske enhetene vokser, vil mer forsknings- og ingeniørinnsats bli rettet mot å forbedre den underliggende teknologien.
Operativsystemleverandører, SSD -brikkeprodusenter og menneskene som skriver all den komplekse firmware -logikken, kommer sammen for å gi oss denne fantastiske enheten. Trim er bare et av de mange mange lagene med kompleksitet som er pakket der inne.