Ssd

[Petrik]

Ak v OS zapisujes stale na to iste miesto (to je jedno ci FAT, ci NTFS - ty to miesto na disku identifikujes cez LBA), tak v SSD to ide stale na ine miesto - prave koli wear levelingu. SSD ma v pamati tabulku prevodov adresa LBA -> miesto v SSD kde su dane data. Tj. ak zapises 1. krat do FAT, LBA 100 - SSD to da do bloku povedzme 100. Zapises znova do FAT, LBA 100, SSD to da do bloku napr. 480, blok 100 vo vnutri SSD sa uvolni. Tym ze je tam ta spare kapacita, tak stale mozes robit nejaky primitivnejsi, nahodny "round robin". Spomalenie pri zapise u SSD, ale napriklad aj zname "zasekavanie" u Jmicron radicov je sposobene tym, ze ked je "plny" disk (t.j. SSD uz pouzil vsetky volne vnutorne bloky), tak pri zapise musi spravit to, ze najde vhodny volny blok (moze to byt jeden zo spare miesta), ten zmaze (pretoze uz predtym bol pouzity), zapise nove data a updatne si vnutornu tabulku LBA-> real. lokace. Toto vsetko dost trva a preto je tam to spomalenie.
Ak pouzijes trim, tak 1. uz nemusis mazat, 2. mas omnoho jednoduchsiu situaciu pri wear levelingu - mas omnoho vacsie moznosti z ktorych blokov vyberat.

Kedze moderne SSD su viackanalove (rychlost jednotliveho chipu flash nie je az tak vysoka), pri zapise sa snazia ho rozlozit paralelne medzi co najviac chipov. Ak ti vsak po dlhsom pouzivani a zaplneni SSD nastane "nevyhodna" situacia, ze vsetky volne bloky k wear levelingu a zapisu sa nachadzaju iba na dvoch chipoch, alebo jednom - tak potom mas vyrazne spomaleny zapis.

A je prave na logike radica aby toto vedela dobre rozlozit a vsetko vnutorne zorganizovat. Preto je intel taky vykonny, vertex tiez (aj ked, ten je trocha iny). A podobne, preto su take pomale 1. generacie SSD, ktore maju tuto logiku dost obmedzenu.

Souhlasim vpodstate se vsim, co zde pises, ale presto podle me plati, co jsem zde napsal. Totiz ze kdyz zaplnis disk daty (a ty pak i treba smazes, to je jedno) a pote budes zapisovat pouze do velmi maleho poctu bloku porad dokola, tak SSD muze pro WL pouzit jen a pouze spare bloky a dale fyzicke bloky odpovidajici LBA, ktere prepisujes, zadne jine, protoze na nich jsou data (prestoze treba i samazane). Toto je IMHO velky problem a pokud ma disk beznych 2-4% spare bloku, brzy je vsechny opotrebuje a disk pujde do haje. Jinymi slovy, muze znovu pouzit blok se starymi daty pouze a jen tehdy, kdyz do nej probehne nova operace zapisu, jinak na nej sahnout IMHO nemuze. Navic, jak vypliva z popisu nekterych vyrobcu SSD na webu, tito vyrobci pouzivaji spare bloky jen a pouze pro nahradu umrelych bloku, ne pro bezny WL.

Jediny realny reseni probemu je FS navrzeny primo pro SSD a obavam se, ze v pripade M$ si muzem nechat o necem takovym pristich min 10let jen zdat.

OS by totiz narozdil od logiky disku moh udelat to, ze tech 10 pidisouboru posle SSDcku prave jako jeden blok velky jako fyzickej blok SSD = obrovsky narust vykonu + usetreni zivotnosti. SSDcko totiz udela to, ze kazdej pidisoubor zapise do extra bloku (= v horsim pripade blok precist, doplnit nova data a opet zapsat). V horsim pripade (plnej disk) bude tutez operaci 10x opakovat nad jednim blokem. Tohle by castecne mohla obejit cache a radic, jenze OS muze (a na 90% bude) ty pidisoubory posilat tak, ze se stim toho moc nenadela, protoze je to zkratka vsechno optimalizovany pro maximalne sekvencni zapis.

Ad TRIM: IMO spis takova berlicka. Funguje to i bez toho, protoze FS sam se snazi (vetsinou) primarne vyuzivat uz pouzity bloky na "zacatku" disku. To sice u SSD postrada smysl, ale je to zkratka napsano pro HDD (ktery sou na zacatku rychlejsi nez na konci). Tudiz predpokladam (nastrel), ze tak 80% prazdnych bloku o kterych SSD nevi ze prazdne jsou bude velice rychle prepsano.

To o cem mluvis ma nejaky nazev (ted nevim jaky), ale dela to urcite intel X25 a predpokadam ze i ostatni SSD s cache, to je hlavni duvod proc tam je. Navic, o no to jde i bez cache, protoze kdyz uz jednou SSD vymaze blok, ktery obsahuje vice clusteru, muze do techto smazanych clusteru zapisovat i postupne, coz take vetsinou dela, akorat to nedejali naraz, protoze nemaji tu cache. Podle toho, jak ja chapu princip WL, je TRIM zcela a naprosto nezbytny pro jeho rozumnou funkci. Navic, moderni FS zapisuji do cele kapacity disku rovnomerne, aby zabranily fragmentaci (extX, reiserFS a castecne i NTFS).


Ad specializovane FS pro SSD: precetl jsem docela dlouhy clanek od Linuse proc je toto spatne a musim s nim souhlasit. Jen SSD ma nejlepsi informace ohledne stavu bloku a jen on dokaze rozume provadet WL. Navic, existuje velke mnozstvi ruznych parametru NAND flash pameti, lisici se velikosti bloku, clusteru a pod a je nemyslitelne, aby toto vsechno musel FS zohlednovat.

Docela by me zajimalo jak intel vyresil problem vnitrni fragmentace, protoze s nejnovejsim FW se jeho SSD chovaji o poznani lepe a problem s fragmentaci udejane temer zmizel. Jinak co jsem cetl tak intel se od ostatnch SSD lisi predevsim extreme malou velikosti bloku.

[THX]

Souhlasim vpodstate se vsim, co zde pises, ale presto podle me plati, co jsem zde napsal. Totiz ze kdyz zaplnis disk daty (a ty pak i treba smazes, to je jedno) a pote budes zapisovat pouze do velmi maleho poctu bloku porad dokola, tak SSD muze pro WL pouzit jen a pouze spare bloky a dale fyzicke bloky odpovidajici LBA, ktere prepisujes, zadne jine, protoze na nich jsou data (prestoze treba i samazane). Toto je IMHO velky problem a pokud ma disk beznych 2-4% spare bloku, brzy je vsechny opotrebuje a disk pujde do haje. Jinymi slovy, muze znovu pouzit blok se starymi daty pouze a jen tehdy, kdyz do nej probehne nova operace zapisu, jinak na nej sahnout IMHO nemuze. Navic, jak vypliva z popisu nekterych vyrobcu SSD na webu, tito vyrobci pouzivaji spare bloky jen a pouze pro nahradu umrelych bloku, ne pro bezny WL.

to je jedna z horsich variant levelingu, ina varianta snad vie aj presunut data z malo opotrebovanych buniek ktore sa dlho necitali do tych viac opotrebovanych a tak uvolnit tie lepsie pre wear leveling;

to co popisujes ty je nieco velmi podobne ako dynamic wear leveling u corsair usb co si daval odkaz

[Petrik]

Co jsem zatim videl tak vetsina levnejsich SSD a CF a SSD pouziva tento dynamicky WL, protoze je snadny na implementaci a nezpusobuje zpomalovani jako staticky WL (to je ten co presouva data z malo pouzivanych bunek, tedy doufam).

UPDATE: http://www.cdr.cz/a/26986/2 novy FW pro X25 skutecne funguje

UPDATE 2: Provedl jsem prvni jednoducha mereni 8GB a 32GB verze teto flashky: http://www.softcom.cz/search.asp?EXP...SearchType=all
v linuxu se hlasi jako UDMA66 pevny disk, tedy ne jako vymenny, coz nektere delaji a coz dela problemy pri instalaci woken (transcendent 133x napr). hdparm -t ukazuje neco kolem 42MBps, dd pri cteni ukazal dokonce 44MBps, coz jsou velmi slusne, az neuveritelne hodnoty. Dale jsem nekde vygooglil, ze pouzity radic provadi global static WL, coz je dobre, akorat pry miva problemy v nekterych cteckach, coz me ale netrapi. Zatim to tedy vypada na SSD se super pomerem cena/vykon, zkusim jeste zmerit latenci, zmerit zapis a pripadne provest nejake dalsi testy.

UPDATE 3: http://www.anandtech.com/storage/sho...spx?i=3531&p=1 toto je dost zasadni clanek o SSD, doporucuji precist vsem zajemcum o tuto problematiku.

[LM]

Celkem zajimave predstaveni noveho radice pro SSD (SandForce):
OCZ's Vertex 2 Pro Preview: The Fastest MLC SSD We've Ever Tested