2017. november 20., hétfő

Útvonal

Tesztek » Adattároló rovat

Átfogó elemzés az SSD-k természetéről

Mivel járunk jobban: a CPU cseréjével vagy egy SSD vételével? Már régen volt dolgunk ennyire érdekes összevetéssel.

Az SDD kapacitása és lassulása

Akkor ettől lassul az SSD, és a cellák is használódnak?

Pontosan. Az ilyen szélsőséges eseteknek két komoly hátulütője van, egyrészt az "overhead", az adatok háttérben való folyamatos mozgatása lassít(hat)ja magának az SSD-nek a működését, másrészt a cellák védelméért munkálkodó wear leveling egyúttal tulajdonképpen csökkenti a cellák élettartamát, de erről nem tehet, egyszerűen így működik az algoritmus.

Hirdetés

Tehát igaz az, hogy az SSD-k idővel hajlamosak lelassulni új állapotukhoz képest és ez áll a háttérben? Mit tehetünk?

Igen, ez az egyik ok. Egyetlen dolgot tehetünk: minél több helyet hagyunk szabadon az SSD-n. A fejlesztők kiszámolták, hogy az SSD felhasználható területének 20-25%-át (tehát egy 100 GB-os SSD-t feltételezve kb. 20-25 GB-ot) szabadon hagyva jelentősen kitolhatjuk az SSD élettartamát. Mi ezt inkább úgy mondanánk, hogy ha ennél több adatot tárolunk rajta, akkor jelentősen megrövidítjük az élettartamát... Persze az előbbi jobban hangzik, ami a gyártók szempontjából fontos. A szabad terület megnövelésének kettős hatása van. Egyrészt arányaiban nézve kevesebb az elmozgatnivaló adat, másrészt több szabad terület áll a wear leveling rendelkezésére, tehát a cellák elhasználódásának a kiegyenlítésére ritkábban kerül sor. Minél több adatot tárolunk, annál gyakrabban lesz szükség a cellákon található adatok újrarendezésére.

Ezek a cégek ott vernek át minket, ahol akarnak... Nem tettek semmit annak érdekében, hogy megelőzzék ezt?

A cégek két dolgot tehetnek. Az egyik megoldás valójában nem a gyártók érdeme, ez inkább más okokra vezethető vissza. Mint tudjuk, a merevlemezek gyártói 1024 helyett 1000-es szorzót használnak a winchesterek méretének megállapításánál, tehát pl. egy 1 TB-os merevlemez 1024 x 1024 x 1024 x 1024 byte helyett 1000 x 1000 x 1000 x 1000 byte-ot képes tárolni, ebből következően egy 1 TB-os merevlemez valójában a formázás után csak ~930 GB-osnak mutatkozik az operációs rendszer felé. Az 1024-es értékkel való számolás csak a memóriáknál maradt meg, ez pedig az SSD-kre is kihatással van, hiszen az SSD is memóriákra épül. Egy 40 GB-os SSD valóban 40 GiB-nyi (40 x 1024 x 1024 x 1024 byte) NAND flash területtel rendelkezik, de ebből csak 37,2 GiB-ot (ami 40 GB) lát az operációs rendszer. Az SSD kis tokjában megtaláljuk az 5 darab 8 GiB-os NAND chipet, tehát nem veszett el semmi, csak éppen mi, illetve maga az operációs rendszer nem férhet hozzá ahhoz a maradék 3 GB-hoz. Ezt a területet "spare area"-nak, vagyis tartalékterületnek nevezik, és az SSD vezérlője takarékoskodik vele, az előzőleg részletezett okok fényében már érthető is, hogy miért. Általánosságban igaz, hogy minél nagyobb méretűnek adják el az SSD-t, annál nagyobb ez a tartalékterület, de százalékban mérve 10% körül/alatt marad. Egy itthon kapható 64 GB-os SSD-n 59 GB az általunk felhasználható terület, a maradék 5 GB a tartalékterület, és így tovább. A tartalékterület a wear levelingen kívül az elhasználódott cellák cseréjére is jó. Ez nem egy fizikailag elkülönített terület, egyszerűen a vezérlő így működik.

A másik megoldás az, ha maga a gyártó korlátozza az SSD-n felhasználható terület méretét, ezzel egyrészt meghosszabbítja az SSD életét, másrészt kitolja a teljesítmény degradálódásának időpontját. A tartalékterület mérete egyes újabb SSD-ken elérheti akár az összes NAND-flash közel 30%-át is, ami azt jelenti, hogy egy 64 GiB-nyi NAND-ot tartalmazó SSD-t 50 GB-osként árulnak, miközben formázás után már csak 46,6 GB adatot tárolhatunk rajta. A felhasználó az árlistában egy 50 GB-os SSD-t lát, tehát ezzel ilyenformán nincs baj, csak éppen ezeket az SSD-ket még a többieknél is drágábban adják éppen emiatt, mert több NAND-ot tartalmaznak, mint amit ráírnak a dobozra.

Mindebből az következik, hogy az SSD-k botrányosan magas ár/kapacitás aránya még annál is rosszabb, mint azt hittük?

Ez így igaz, de később még erre is kitérünk, mert szerintünk rossz felfogás uralkodik ezen a téren.

Az SSD belassulásának milyen más okai vannak még?

Egészen pontosan egy van, és az is csak az írást érinti, ráadásul ki is küszöbölhető, ennek megértéséhez azonban némi háttérismeretre van szükség. Amikor letörlünk egy fájlt a merevlemezről, az valójában nem törlődik a winchesterről. Annyi történik, hogy az operációs rendszer azt a "területet" (szektorokat) megjelöli felülírhatóként. Az adatok ott maradnak a HDD-n, de bármikor felülírhatóak. Egy merevlemeznek nem okoz gondot egy adat felülírása, semmiféle hátránya nem származik ebből, azonban az SSD-k működése más. Az SSD csak üres lap(ok)ra (4 kB-os egységek) írhatja fel az új adatokat, az érvénytelen adatokat tartalmazó lapok pedig ottmaradnak a helyükön, amíg szükség nem lesz a szabad területre. Ráadásul létezik mégegy korlátozás, ami további problémát jelent: az SSD csak egy komplett blokk (512 kB, azaz 128 darab 4 kB-os lap) törlésére vagy felülírására képes.

Ez nem hangzik túl jól... Pontosan mi is történik?

Egy új SSD-vel még semmi gond nincs. Rámásolunk egy 4 kB-os fájlt az SSD-re, a vezérlő ezt simán beírja egy üres blokkba vagy egy nem teljesen üres blokkba egy üres lapra, és meg is volnánk. A probléma akkor kezdődik, amikor az új, felírandó adatokat előzőleg törölt lapokat tartalmazó blokkokba kell bemásolnia. Ebben az esetben már nincs lehetőség a szimpla írásra, újraírásra van szükség. Ebben a helyzetben az SSD-nek először ki kell olvasnia a blokk (128 x 4 kB) tartalmát (1-es pont). Ezt betölti a gyorsítótárba (2-es pont), a gyorsítótáron belül kitörlődnek a nem kellő lapok (3-as pont), az új adatok beíródnak a blokkba (4-es pont), majd a cache tartalma felíródik a NAND memóriára (5-ös pont). A lényeg tehát: 4 kB-nyi adat írásához az SSD-nek egy beolvasás/módosítás/kiírás ciklust kell végrehajtania, ráadásul az eredeti adatmennyiség (4 kB) sokszorosával, egészen pontosan 512 kB-ot olvas be, aztán 512 kB-ot ír ki. Mondanunk sem kell, ez jelentősen le tudja lassítani az írási műveleteket, hiszen az eredeti adatmennyiség sokszorosának írására van szükség, és akkor még ott van a wear leveling is, ami tovább súlyosbítja a problémát.

Sokszor 4 kB írásával ez egy valóságos rémálommá válik, igaz? Mit tehetünk ellene?

Sokszor 4 kB írása rendkívül leterheli az SSD-t, amennyiben nem használjuk a TRIM-utasítást. A TRIM szócskáról valószínűleg már majdnem minden SSD iránt érdeklődő hallott. A TRIM elvileg egy konkrét SATA utasítás, ami jelzi a vezérlő felé, hogy az adott adat valóban törölhető. Ha az SSD vezérlője tudja, hogy az adat törölhető, akkor felszabadíthatja a TRIM nélkül csak felülírhatóként megjelölt területeket, ennek következtében pedig az új SSD sebességével folytatódhat az írás. Hiszen mi is történik? Letöröljük egy 4 kB-os lap tartalmát. TRIM nélkül az előzőekben taglalt módon ez valójában nem törlődik, csak felülírhatóvá válik. Ellenben ha az operációs rendszer elküldi a TRIM-parancsot az SSD vezérlőjének, akkor az SSD azonnal tudni fogja, hogy erre az adatra már nincs szükség, és azonnal törlődik a lap tartalma (valós időben), így később, amikor egy 4 kB-os adat írására kerül sor, már nem kell az egész blokk tartalmát beolvasni, a cache-ben módosítani, majd visszaírni, hanem szimplán egy lap beírására korlátozódik a műveletek "sora".

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

Hirdetés

Hirdetés

Copyright © 2000-2017 PROHARDVER Informatikai Kft.