Výsledky 1 až 25 z 47

Téma: Ssd

Threaded View

Předcházející příspěvek Předcházející příspěvek   Další příspěvek Další příspěvek
  1. #37

    Standardní Re: Ssd

    Citace Původně odeslal THX Zobrazit příspěvek
    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.

    Citace Původně odeslal Jezevec Zobrazit příspěvek
    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.
    Naposledy upravil Petrik; 12.05.2009 v 00:24.
    desktop: i5-2500K@3700MHz, MSI P67A-C43-B3, 2x4GB Kingston Value, Sapphire 5850 Xtreme 1GB 850/1100, 2xWD10EALX fake RAID-1, LG W2600HP-BF S-IPS,Razer DiamonBack, Seasonic SS-400ET-F3, Windows 7 x64 SP1 + ubuntu x64
    notebook: IBM T41p, 1.7 Pentium M, 14" 1400x1050, 1.5GB RAM, 40GB 4200r, Ubuntu 9.04
    ultraportable: IBM X41, 12" XGA 1.5GHz Dothan, 2GB RAM, 32GB CF Pretec 233x SSD, Ubuntu 9.10
    repro: Teufel Concept E Magnum PE 5.1

Informace o tématu

Users Browsing this Thread

Toto téma si právě prohlíží 1 uživatelů. (0 registrovaných a 1 anonymních)

Pravidla přispívání

  • Nemůžete zakládat nová témata
  • Nemůžete zasílat odpovědi
  • Nemůžete přikládat přílohy
  • Nemůžete upravovat své příspěvky
  •