Vezérlő

Alapvetően annyi mondható el a flash-alapú SSD-ről, hogy áll egy vezérlőből, NAND chipekből, és a gyorsítótárból (ez valamilyen DDR-típusú DRAM memória általában).

Először a vezérlőre jellemző technológiákról beszélnék.
A vezérlő feladata alapvetően az, hogy koordinálja az SSD-re kiírandó adatokat, hogy azok mégis hol helyezkedjenek el. Ez úgy értendő, hogy a párhuzamos adatfeldolgozás miatt egy egybefüggő fájl írásakor a bitek több különálló NAND chipre kerülhetnek.

A vezérlő további feladata lehet az adatok titkosítása (ez opcionális funkció) és a Garbage Collection. Ezen funkció magyarázatához azonban az SSD-k alapvető működését kell megértenünk. Szilárdtest-meghajtóról csak blokkokat tudunk olvasni, melyek általában 4 kB-os page-ből állnak (átlagban egy blokk 512 kB = 128 * 4 kB). Íráskor előbb be kell olvasnunk az adott blokkot. Beolvasás után bizonyos page-ek felülírható státuszt kapnak (azok, melyeket mi korábban „töröltünk”; ez úgy értendő, hogy a törlés nem történik meg azonnal, hanem ezen ciklus részeként!); azokat, melyekre még szükség van, egy üres blokkba vissza kell írnia a vezérlésnek. Ez az egész folyamat érthetően borzasztóan pazarló, ezért is szükséges a nem használt területek „takarítása”, a Garbage Collection.

Ezen a problémán sokat segíthet a TRIM nevű technológia, melyet a vezérlőnek támogatnia kell. (Valójában nemcsak az SSD-nek, hanem az operációs rendszernek, és az alaplapi drivernek is támogatnia kell!)
A TRIM olyan SATA-utasítás, mely közli a vezérlővel, hogy a kijelölt adat véglegesen törölhető. Ekkor nem lesz szükséges az előbbiekben ismertetett igen nehézkes, és lassú olvasási-törlési-írási műveletre, hanem a TRIM parancsot az eszközünk azonnal végrehajthatja, egyből törölve az adott cellákat. Nyilván, abszolút jogosan merülhet fel az olvasóban a gondolat, hogy valójában a TRIM funkció használata gyakorlatilag csökkenti az SSD élettartamát; ezen állítással pedig nem is nagyon lehet vitatkozni, mert gyakorlatilag ez a technológia hátránya. Viszont sebességben meghálálja a kellemetlenséget.

Az SSD-k elhasználódásáról már ejtettem pár szót. Felmerült a logikus igény arra, hogy az SSD meghajtónk teljes területe egyszerre használódjon el; ami ha belegondolunk még mindig sokkal jobb, mint ha két bekapcsolás között 10% kapacitást veszítünk, majd egy hónap múlva megint 10%-ot, és így tovább… Ennél valóban jobb, ha egyenletesen használódik el az összes cella.
Ezt hivatott megvalósítani a Wear Leveling. A Wear Leveling gyakorlatilag úgy rakosgatja állományainkat a NAND chipek területén, hogy mindenhol ugyanolyan legyen a „kopás” mértéke
Kétféle megoldás létezik a dinamikus és a statikus Wear Leveling.

A dinamikus Wear Leveling esetében a vezérlő, csak a dinamikusan, folyton változó területet gondozza, az operációs rendszer fájljaihoz, vagy az állandó állományainkhoz sosem nyúl. Ez sajnos félmegoldás, hiszen a dinamikusan használt terület hamarabb fog „elkopni”, jókora tárhelycsökkenést okozva.
A statikus Wear Leveling ezzel szemben az egész SSD területét mozgatja, ügyel arra, hogy az összes cella egyszerre öregedjen el. Nyilván mindenki számára világos, hogy a Wear Leveling terhet is ró az előnyei mellett a meghajtónkra, hiszen gyakorlatilag folyamatosan mozgatja rajta az adatokat; csökkentve ezzel a sebességet és az élettartamot. De így legalább egyszerre válik írhatatlanná a teljes lemezünk.

Az Over Provisioning is egy gyakran használt technológia az SSD-k világában. A fizikailag elérhető maximális tárkapacitás egy bizonyos részét (7-28%) lefoglalja a vezérlő a hibás blokkok cseréjére, TRIM parancs futtatására. Bizonyos vezérlőknél ez a beállítás paraméterezhető, ill. ki is kapcsolható. De fontos, hogy ez a tárhelycsökkenés nem keverendő össze a GB és a GiB közötti konverzióval! [LINK]

Fontosnak tartok még néhány szót ejteni SSD-lemez esetében az alignálásról. Egy merevlemez partícionálásakor az MBR-nek szükséges 31,5 kB-nyi helyet hagynunk. (Akit érdekel, hogy pontosan miért, vagy, hogy mi ez; az itt olvashat utána: [LINK]) Mint említettem az SSD legkisebb írható egysége a page (lap), mely 4 kB-os méretű, és mivel 31,5 kB-nál kezdődik a partíciónk, így sok esetben egy 4 kB-os adat kiírása miatt több page-t is igénybe kellene vennie a vezérlőnknek. A megoldás erre az, hogy az MBR méretét 4096-tal (~ 4 kB) oszthatóvá kell tennünk. Akit a gyakorlati megvalósítása érdekel, az itt tud utána olvasni: [LINK]. De vigyázat: alignálás utólag csak az adatok elvesztésével oldható meg!
 

A cikk még nem ért véget, kérlek, lapozz!