Ssd

[Tanya]

Octo - zatial je to vlastnost vsetkych flash pamati, teda skor radicov, ktore su s nimi dodavane, cim mensie bloky dat, tym viac sa ten radic zapoti. Podstatne lepsie su na tom SLC ssd disky oproti MLC ssd diskom, ten intel je tu vynimka vdaka tej cache pamati. Ale ten Intel je drahy ako svina a SLC su oproti nemu este drahsie.
Ale zacina svitat na lepsie casy : http://www.dsl.sk/article.php?article=6859&title=

[sAd]

Tanya: Tak Sandisk se docela snaží. Uvidíme, jestli nezůstane jenom u čísel a skutek utek...

[Emp3r0r]

http://www.fudzilla.com/index.php?op...11365&Itemid=1

Pěkné, jen škoda, že je to info od Fuada, trochu to ubírá na serióznosti...

[Tanya]

intel znizil o nieco ceny, vid http://www.dsl.sk/article.php?article=6998

[LM]

Intel SSD možná nejsou až tak super, jak se může zpočátku zdát aneb wear leveling způsobuje časem výrazný pokles výkonu

[THX]

Nove SSD od OCZ:

http://www.pcper.com/article.php?aid=670

Toto su zatial viac menej engineering samples, co je ale podstatne, ze doslo k odstraneniu starych chyb (zasekavanie pri random zapise), vykon vyrazne stupol a cena klesa...

Kto chce viac (pomerne detailnych) informacii, tak doporucim http://www.ocztechnologyforum.com/fo...play.php?f=186 , je to tam v poslednom case velmi zive...

Inac v tom fore pisu vela dobrych fint ako zvysit (razantne) vykon s uz existujucimi SSD (aj od inych vyrobcov ako OCZ).

[Petrik]

Zkusim sem napsat par postrehu, ktere jsem vygooglil za poslednich par dni, protoze se chystam do meho noveho (jeteho) notebooku ibm X41 dat misto disku 8GB CF 266x Pretec.

1) wear levelling skutecne zpusobuje vnitrni fragmentaci, tak jak to je popsano ve znamem clanku na cdr.cz.

2) wear levelling zatim nemuze fungovat prilis dobre a to z toho duvodu, ze SSD netusi, ktera data jste vymazali a ktera ne, takze pokud se stane, ze do kazdeho bloku neco zapisete (at uz najednou, nebo postupne), tak tim wear levelling vpodstate konci, protoze prestoze jste vy rekli vasemu FS, ze ty a ty data ma vymazat, tak on je samozrejme nevymaze, ale jen zahodi zaznam k nim vedouci nebo tak neco (podle FS). Dulezite je, ze SSD o tom nema (a zatim ani nemuze mit) ani paru, takze musi brat vsechny bloky jako obsazene, cimz nemuze efektivne provadet wear leveling. Mozna to neni uplne presne jak jsem to popsal, ale princip je asi jasny. Toto resi novy ATA TRIM prikaz, kterym v budoucnu (az bude implementovan vyrobci SSD a OS+FS) FS primo rekne SSD, ktere bloky muze uvazovat jako prazdne a pouzit je pro wearlevelling. Jako prvni by jej mel udajne implementovat intel do FW svych X25 SSD, v linuxu by jiz mel udajne byt, anebo se chysta.

3) pouziti SSD v linuxu: jako nejrychlejsi FS pro SSD se zda byt novy ext4, ktery navic umoznuje nepouzivat journal a presto je znatelne rychlejsi a lepsi nez stary ext2 (=ext3 bez journalu). Zasadni je predevsim pouziti noatime u mountu, dale hodne pomuze pouziti noop IO planovace, pripadne vypnuti barrier. Barrier spolu s vypnutim journalu dramaticky zvysuje pravdepodobnost ztratu dat po nahlem vypadku ci rebootu, prvni vsak zvysuje rychlost, druhy predevsim opotrebeni SSD a zaroven snizuje vnitrni fragmentaci. journal se da take umistit na jine medium, pokud je k dispozici. Dulezite by rovnez melo byt zarovnani diskoveho oddilu tak aby odpovidalo velikosti bloku SSD (FS aligning). Dale se doporucuje presunout /tmp /var/log a podobne adresare do tmpfs, tedy do ramdisku. Linux kernel by mel jit donutit k agresivnejsimu cachovani zapisu (ala flashpoint nize), ale k tomu jsem se jeste nedostal. Pokud v linuxu nepotrebujete z SSD bootovat a chcete mit jen jeden diskovy oddil, je mozne udelat FS primo na SSD blockdevice (mkfs.ext4 /dev/sdX - vedeli jste o tom nekdo) bez jakeholi partitionovani, FS pak bude vzdy zarovnany (aligmented).

4) ve windows lze pouzit SW FlashPoint, ktery pro prvni disk v systemu vytvori 32MB writeback cache, ktera dramaticky zrychluje predevsim nahodny zapis u SSD bez cache, ale samozrejme zvysuje ryziko ztraty dat. Dale je mozne vytunit windows skrz registry pro mensi pocet zapisu na disk (ntfs volby a pod).Rovnez se doporucuje udelat cluster aligment.

5) mnoho lidi si stezuje, ze pri pouzivani firefoxu na SSD bez cache dochazi k vytuhavani systemu. To je zpusobene castym ukladanim diskove cache, ta se tedy doporucuje ukladat pouze do RAM.

par zajimavych odkazu:
http://blog.loxal.net/2009/04/tuning...ance-with.html tuning ext4
http://forums.fedoraforum.org/showthread.php?t=215109 generic linux tuning
http://thunk.org/tytso/blog/2009/02/...se-block-size/ filesystem aligning v linuxu
http://thunk.org/tytso/blog/2009/02/...ized-for-ssds/ some notes about ATA TRIM
http://forum.thinkpads.com/viewtopic...hpoint#p506347 vliv cluster aligment a flashpointu na vykon
http://www.thinkwiki.org/wiki/Compact_Flash_boot_drive nejake povidani mimo jine o CF do X40/X41


doufam ze to alespon nekomu pomohlo. Az dorazi flashka a notebook, dam vedet nejake postrehy.

UPDATE: Pro win se doporucuje FAT32 misto NTFS kvuli absenci journalu, na druhou stranu v NTFS lze pouzit kompresi, ktera teoreticky muze byt prinosem.

[THX]

2.) na toto suzi ata prikaz TRIM, ktory prave povie SSD ktore data su zmazane a teda si ich moze SSD zmazat a tak pripravit prazdnu stranku na zapis, ktoru uz nebude musiet ako momentalne mazat testne pred skutocnym zapisom

TRIM podporuje novy win7 a tiez tusim aj linux (i ked nie 100%tne a chce to nejake modifikacie).

Z SSD ktore podporuju trim je OCZ VERTEX (aj ked mozno bude chciet este jedno firmware update) a snad coskoro aj intel SSD. Inac potom by to mohli podporovat (ak budu mat vhodne FW) aj vsetky ostatne SSD s indillinx Barefoot kontrolerom (momentalne je to napr. aj najlepsi SUPERTALENT).

[Petrik]

jj o TRIMu jsem psal, ale nevedel jsem uz to nejaky SSD skutecne ma. Jinak kdyz ho nema nebo ho OS neumi, tak podle me nemuze smazat obsah bunky (mam na mysli tu premapovanou, tedy jinou nez urci FS, tedy pokus o wear levelling) s daty ani tesne pred zapisem, jak pises ty, protoze nevi, zda tam nejsou nahodou nejaka data...takze pokud do vsech bloku alespon jednou probehne zapis, nemuze IMHO bez TRIMu SSD provadet wear levelling vubec, nebo jen velmi spatne (a to by me zajimalo jak). Prinos TRIMu by tedy mel byt hlavne ve zlepseni/umozneni efetivniho wear levellingu tim, ze SSD bude vedet, ktere bunky muze znovu pouzit a ze to bude znamenat zrychleni, je samozrjme take pozitivni (na ukor pomalejsiho mazani zrejme). dik za info

[THX]

Ak chces zapisat do bunky ktora nie je zmazana, musis ju najprv zmazat. Preto je prepad vykonu pri zapise pri pouzitom SSD. Na wear leveling ma SSD vzdy nejaku kapacitu navyse. Napr. 32GB vertex je v skutocnosti tusim 36GB....

Mazanie vo win7 nie je pomalsie, pretoze TRIM sa posiela disku az po case, na pozadi v dobe nizkej diskovej aktivity. (vzhladom na rychlost SSD to mozne znamenat hoci aj 1s po zmazani suboru, kedze disk bude asi idle)

[Petrik]

Jak probiha zapis do do NAND tusim, ale wear levelling funguje IMHO jinak nez si myslis. Zakladni princip je v jakemsi rotovani a preskupovani casteji pouzivanych bloku po CELE kapacite disku, proto problem interni fragmentace nastava jiz relativne brzy. Je mozne, ze nektere SSD maji jeste navic nejake volne misto pri pripadne umrele bloky, ale bez rotovani bloku cele kapacity by to dle meho nazoru stejne nepomohlo. Napr. do FAT tabulky se zapisuje pri jakekoli zmene ve FS, proto se musi jeji fyzicke umisteni casto menit, aby neodchazely bloky na kterych je. Problem je v tom, ze aby mohlo toto rotovani probihat, musi SSD vedet, ze nektere bloky jsou prazdne a ty pouzit. Bez TRIMu to po nejake dobe, kdy se beznym provozem alespon jednou zapise do vsech bunek, neni mozne, protoze prestoze treba vsechno smazes nebo dokonce udelas format disku, SSD o tom z principu nemuze mit ani paru a musi brat vsechny bloky jako obsazene. Takhle ja chapu wear levelling (WL), resp dynamicky WL, protoze jsou 3 ruzne druhy, z toho jeden v soucasnosti udajne provadi pouze intel X25 a je pry nejsofistikovanejsi. zkusim najit nejake odkazy.....

jinak samozrejme souhlas ze TRIM bude znamenat zrychleni SSD, jak moc dramatice je otazka, protoze pokud by kazdy zapis sel do volnych bloku (coz ty zrejme myslis), znamenalo by to pravdepodobne brutalni vnitrni fragmentaci.

[THX]

wear leveling funguje aj pri plnom disku, prave na to je tam navyse trocha tej kapacity, aby sa to "volne miesto" mohlo postupne pri zapisovani presuvat po celom disku. Tak nejak to "rotuje". Pri zapise sa zapise do najmenej pouzivanej stranky vo volnom mieste - a tym padom sa uvolni miesto kde bola povodna stranka (t.j. tam kde v skutocnosti chcel zapisat OS). SSD ma potom v pamati mapu ze kde v skutocnosti su ktore data. Teda ak si OS mysli ze su na zaciatku disku, v skutocnosti mozu byt na konci. Ak stale nevies ako to presne funguje, skus wiki, google atd. - alebo pozri starsie clanky, svethw atd. v casoch ked sa uvadzali SSD sa v clankoch objavovala cast "popis technologie", tam by si to mohol najst dost zrozumitelne a jednoducho popisane.

[Petrik]

Promin, ale to stale IMHO nemuze dobre fungovat. Proved si pomyslne par ruznych zapisu do vice bunek a zjistis, kde je problem (ale take je mozne ze to reseni proste stale nevidim). Bez TRIMu to proste dost dobre nejde (leda by nahradni kapacita byla 100% kapacity disku), ostatne neco podobneho se pise v jednom z tech odkazu, ktere jsem postnul.

http://www.t10.org/ftp/t10/document.08/08-347r1.pdf TRIM jako security problem (mimo jine)
http://lwn.net/Articles/293658/ zde je vysvetlen problem WL pri zaplnenem disku, citace:

If the device fills up with data, that list of free blocks can get quite short, making it difficult to deal with writes and compromising the wear leveling algorithm. This problem is compounded by the fact that the low-level device does not really know which blocks contain useful data. You may have deleted the several hundred pieces of spam backscatter from your mailbox this morning, but the flash mapping layer has no way of knowing that, so it carefully preserves that data while scrambling for free blocks to accommodate today's backscatter. It would be nice if the filesystem layer, which knows when the contents of files are no longer wanted, could communicate this information to the storage layer.

Ano, problem se mirne oddali pouzitim dodatecne kapacity, ale neni to ani zdaleka totez, jako kdyby WL mohl vyuzivat celou kapacitu disku.

[THX]

If the device fills up with data, that list of free blocks can get quite short, making it difficult to deal with writes and compromising the wear leveling algorithm. This problem is compounded by the fact that the low-level device does not really know which blocks contain useful data. You may have deleted the several hundred pieces of spam backscatter from your mailbox this morning, but the flash mapping layer has no way of knowing that, so it carefully preserves that data while scrambling for free blocks to accommodate today's backscatter. It would be nice if the filesystem layer, which knows when the contents of files are no longer wanted, could communicate this information to the storage layer.

Ano, problem se mirne oddali pouzitim dodatecne kapacity, ale neni to ani zdaleka totez, jako kdyby WL mohl vyuzivat celou kapacitu disku.

...If the device fills up with data - k tomu nikdy nedojde. Stale bude na disku nejake volne miesto, prave vdaka tej kapacite navyse. A vzdy ked sa zapise do tohto dalsieho volneho miesta, tak sa uvolni ta stranka kde sa malo povodne zapisat, teda aj ak bude disk 100% plny, tak stale tam bude aspon ta minimalna rezerva volneho miesta aby mohol fungovat wear leveling.

AD. ta TRIM security issues prezentacia: staci ze firmware si pamata bloky, ktore su TRIM-nute a pri ich citani vrati stale blok nul.

[Petrik]

Problem je, ze pro WL jdou pouzit jen ty bloky, do kterych probehne zapis, ale napr. ne ty bloky, ktere ve FS vymazes, ale fakticky do nich nic nezapises. Takze pokud nastane extremni sitace, ze budes stale zapisovat jen do jednoho, dvou nebo obecne maleho mnozstvi bloku (nejake logovani, FAT table, DB a pod) a na ostatni ani nesahnes, prestoze ve FS se jedna o volne misto, SSD je vidi jako obsazena daty a nemuze je pouzit pro WL. Takze bude pro WL pouzivat jen to velmi male mnozstvi bloku, ktere brzy umrou. NAvic pochybuji, ze vetsina SSD (natozpak CF ci SD) ma tak velke procento spare blocku, jako ma ten OCZ.

UPDATE: provedl jsem maly reaserch a obvykla hodnota spare bloku je 2-4%, coz je pomerne malo. Navic, pokud to chapu dobre, tak jsou casto vyuzivane POUZE jako nahrada za bad bloky: http://www.mydigitaldiscount.com/Pro...9BB-1239713760

UPDATE 2: Ted jsem narazil na zajimavy napad jak toto docasne resit bez TRIMu: rozdelit disk na dve partitiony a pouzivat jen jednu ( do druhe nikdy nic nezapsat), aby druhou mohl SSD pouzit pro WL. Sice tim prijdete o cast kapacity, ale zivotnost by mela byt lepsi. Pro levne CF karty mozna dobre reseni.

http://www.sandisk.com/Assets/File/O...rLevelv1.0.pdf Sandisk to dela jeste jinak
http://www.corsairmemory.com/_faq/FA...r_leveling.pdf Corsair to na svych USB dela +- tak jak jsem to zde popsal, tedy alespon doufam, citace:

What is dynamic wear leveling?
This technique only wear-levels over dynamic data areas (see figure 3). For example, an 8GB Flash Voyager stores 3GB of MP3 music files but only 5GB remaining capacity is free for wear leveling.
The dynamic data areas are rotated in the round-robin fashion from a pool of free blocks. Dynamic wear leveling has a shorter life expectancy compared to static wear leveling because only dynamic data areas can be used to rotate data.

Problem nastane, pokud nezbyva zadne volne misto, resp SSD o nem nevi.

[THX]

Problem je, ze pro WL jdou pouzit jen ty bloky, do kterych probehne zapis, ale napr. ne ty bloky, ktere ve FS vymazes, ale fakticky do nich nic nezapises. Takze pokud nastane extremni sitace, ze budes stale zapisovat jen do jednoho, dvou nebo obecne maleho mnozstvi bloku (nejake logovani, FAT table, DB a pod) a na ostatni ani nesahnes, prestoze ve FS se jedna o volne misto, SSD je vidi jako obsazena daty a nemuze je pouzit pro WL. Takze bude pro WL pouzivat jen to velmi male mnozstvi bloku, ktere brzy umrou. NAvic pochybuji, ze vetsina SSD (natozpak CF ci SD) ma tak velke procento spare blocku, jako ma ten OCZ.

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.

[Jezevec]

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.

[THX]

takyto program ktory kombinuje small writes a posiela ich SSD ako jeden velky commit je prave FlashPoint (pouziva 32mb cache), ktory sa instaluje ako driver disku pre win XP. Pomaha to extremne najma na starsich SSD s Jmicron radicom, ktore zvladaju max. 5 random zapisov za sekundu. Pomaha to aj pre random write u normal diskov, ale tam to nema velky zmysel, kedze je write (najma random) rychlejsi ako citanie.

Win7 uz robi to ze sa snazi minimalizovat random zapisy.
Win7 je celkovo SSD friendly - ak detekuje SSD, vypne vsetky diskove optimalizacie, ktore u SSD skodia (defrag na pozadi, indexing, prefetch atd.), osobne si myslim ze sa to tyka napr. aj optimalizacie presuvania suborov na zaciatok disku kde je najrychlejsi. Tiez TRIM je pouzivany len na pozadi, ak je nizka diskova aktivita. SSD ma potom fakt tolko volneho miesta kolko je na disku. T.j. ked sa zapisuje subor (z pohladu OS) na disk do prazdneho miesta, tak aj na SSD to ide do prazdneho miesta, odpadaju problemy s prepisovanim stranky atd. TRIM dokaze celkom efektivne odstranit vnutornu fragmentaciu a dalsie problemy. (inak u intel SSD, aj bezne normal pouzivanie disku dokaze prostrednictvom svojich normal zapisov odstranit vzniknutu vnutornu fragmentaciu ktoru sposobil napr. nejaky random write benchmark)

Inac co sa specializovanych FS tyka- OK riesia problem, ale naco? Problem je uz vyrieseny, 2. generacia SSD ako vertex a intel uz zvladaju akekolvek FS vysokou rychlostou pre vsetky FS.

[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