Vlákno názorů ke zprávičce Intel se chystá prodávat 160 GB SSD disky od Prot - Škoda, že flash disky zaostávají v jedné podstatné...
-
tom (neregistrovaný)To uz davno neplati. Pouziva se specialni algoritmus (ted si nevzpomenu na nazev, ale google...), ktery zapisuje pokazde jinam a existuje nejake mapovani. Zkousel jsem to napriklad u SD karty a bez problemu zvladla 10milionu zapisu na jedno misto bez jedine chyby (zapis a cteni nahodnych dat). Pochybuji, ze by to do SSD nedali taky.
-
anonymníJenomze vetsina users zaplaca disk systemem softem daty (filmy) a hrama. Bezny provoz pak bude probihat na neobsazenem zbytku o par % kapacity, tam uz rozhazovaci algoritmus moc nezmuze.
Nebo je toto osetreno tez ? pochybuju. Algoritmus co by michal s daty na pozadi jeste k normalnimu provozu, by degradoval SSD na naprosteho slimejse. -
Standa (neregistrovaný)Právě toto dnes již řeší všechny flash disky, včetně nejlevnějších USB klíčenek. Bez toho to ani nejde, neboť souborový systém nad klíčenkou by byl nucen řešit správu vadných bloků. Kromě toho, bez těchto obvodů by vytažení klíčenky během zápisu znamenalo ztrátu 64-128kB dat (pro zápis jednoho bajtu bez pomocných obvodů je nutné 64-128kB smazat, a pak opět zapsat oněch 64-128kB se změněným bajtem).
Jediný HW, u kterého na to musíte dávat pozor, je samotný flash čip přímo na sběrnici počítače.
Podívejte se do zdrojáku kernelu na rozdíl mezi mtd zařízením a blokovým zařízením. -
Nepřesouvá. Pouze při zápisu použije jiné místo, než ze kterého je přečetl, a aktualizuje mapovací tabulku. Při čtení se data nehýbou.
Nad pamětí samotnou existuje mapovací tabulka, která říká, kde se v současné době nachází který fyzický blok, což je rychlá a dokonale zvládnutá technologie.
Kdysi jsem četl dokument výrobce čipů, kde to bylo popsané lépe, ale už ho nemohu najít.
V Linuxu podobně funguje jffs2, který při opakovaných zápisech píše pokaždé jinam. -
anonymníAha takze plati ona dosti zavadna skutecnost s % obsazeni pri beznem pouziti. A zaroven neplati rust zivotnosti s rustem kapacity a konstantnim dataflow (viz v postu nize). (Pokud je to tedy pravda co rikate)
Takze muzu otestovat zivotnost flash pameti jednoduse tak za napriklad na 1024MB modul zapisu 1022MB, ty necham byt a budu neustale mazat a zapisovat novy 2MB soubor s nahodnyma daty ve smycce, dokud zarizeni nevyhodi error. To se da otestovat celkem rychle 10000~100000x2MB rychlost zapisu 10~50MB/s. To je test max. na hodinku dve. (Za predpokladu xy) -
Výrobce v článku tvrdil, že při přepisování jednoho a téhož logického místa každých 5 sekund dává jejich algoritmus paměti teoreticky cca 200 let života. Detaily implementace nebyly v článku popsány.
Dovedu si představit implementaci, která používá vždy celou paměť jako cyklický buffer:
1. Přečíst sektory na přepsání (rychlé, čtení lze dělat po bajtech nebo sektorech).
2. Udělat změnu.
3. Přečíst blok který ja na řadě s přepsáním.
4. Vyházet z něj bloky, které jsou v mapovací tabulce označeny jako neplatné.
5. Přidat nové bloky na místo neplatných, ale pokud to lze, jedno místo ponechat neobsazené. (Alternativou je, že pokud zbydou volné bloky po neplatných datech, tak do nich přesunout data odjinud - z čteného bloku, nebo z následujícího bloku cyklického bufferu.)
6. Vymazat blok.
7. Zapsat blok.
Samozřejmě, že takto jednoduchý algoritmus v praxi asi nestačí. Nicméně to už je starost výrobců.
Mám ovšem podezření, že výkyvy rychlosti zápisu u některých flash pamětí, které mám, mohou jít právě na vrub relokačním algoritmům. -
anonymníNo tak to ale popisujete nestandardni pouziti, kdokoliv si poridi SSD tak ho bude vyuzivat jinak - jako klasicky HDD, to co popisujete by vyzadovalo zmenu na urovni OS a stejne by to velice degradovalo vykon (nebo samotného SSD pokud to bude v něm). IMHO
Jak je to uvnitr SSD opravdu netusim ale pomalost v urcitych situacich pri zapisu svalovat na dynamickou relokaci jiz ulozenych dat ehm. tak takto hloupe reseni by urcite nikdo nezavedl. Kdyz uz relokace tak v case kdy se nezapisuje nic zvenku tzn. "ve volnem case" kdy by nebyl brzden zapis dat z venku. (Toto by slo odhalit detailnim sledovanim odberu proudu SSD - pri neukolovani z venku by zacal "sam od sebe" pracovat = odebirat vetsi proud).
Naddto by pomalost zapricena relokaci delanou zaroven pri zapisu z venku byla pozorovatelna porat, zvlaste pri kopirovani velkych souboru, coz se tedy s realitou neshoduje ani nahodou.
Stejne, o cem se bavime. Kazdy vyrobce si to muze poresit jinak a vime my jak to je zrovna v tom kterem vyrobku udelane ? Leda testovat a spekulovat.
"Vyrobce v clanku tvrdil, ze pri prepisovani jednoho a tehož logickeho mista kazdych 5 sekund " a v tom je prave vtip. LOGICKEHO MISTA, ne fyzickeho. Vsadim se ze je to brano pro cyklycke plneni a vyprazdnovani CELE kapacity. Realne pouziti SSD vypada jinak uz z principu. Viz ta %.
Nicmene, sice tvrdim ze by relokace jiz ulozenych dat pri zapisu novych zvenku byla hloupe reseni jenomze jak to je doopravdy?, to kolisani rychlosti zapisu mi vrta hlavou. Bohuzel ho nedovedu determinovat. Vy ano ? -
anonymníOno nemusi byt tak zle. Pokud to takto skutecne je a funguje, znamena to ze poroste zivotnost SSD pri konstantnim data flow geometrickou radou s rustem kapacity. (Tim vice cim bude dataflow vice v nepomeru ku celkove kapacite SSD).
Pokud se bude vymenovat datovy ekvivalent cele kapacity zustane zivotnost konstantni.
Zalezi na tom zda SSD rozhazuje data jen pri zapisu nebo je stehuje i sam ve vlastni rezii mezi blokama bez ucasti z venku (na mene opotrebovane bloky).
