Názory k článku
Technologie flash pamětí a způsoby jejich využití

Tak to toho tedy vis opravdu malo... V clanku je to korekt, tvoje uvaha s pocitanim casu je chybna,funguje to trochu jinak.

Je to tak, ty ciselne udaje v clanku jsou spatne, patrne jde o preklep.

Podla clanku zapis trva 300ms, citanie 25ms a najpomalsia operacia (vymazanie bloku) trva len 2ms.

Pokud budu předpokláda, že místo zápisu 300 ms má být 300 µs a místo 25 ms pouhých µs, tak by mi to také připadalo blíž k realitě.

Pokud budu předpokládat, že místo zápisu 300 ms má být 300 µs a místo 25 ms pouhých 25 µs, tak by mi to také připadalo blíž k realitě.

BRW: sorry za překlepy

tady jsou podobné údaje jako v článku, tak nevím: Introduction to Flash Memory (T1A)
Jim Cooke (jcooke@micron.com), Staff Architect and Technologist, Architecture Development Group, Micron Technology, Inc.

Máte skutečně pravdu, v článku mám dva chybné údaje - zápis stránky a čtení stránky, v obou případech má být čas v mikrosekundách, čímž se max. rychlost čtení zvýší z 80kBps na 80MBps. Rychlost mazání bloku je zapsaná správně, 2 ms (+- podle výrobce), načtení dat do registru nebo naopak přečtení dat z registru má taky korektní údaj.

Omlouvám se, jde o přepis, bude opraveno.

kostky ze stanice Lego :-D

Opraveno, diky za upozorneni.

Btw. ta fleska v peru je fakt hodne dobry napad. Proc se to neprodava casteji? Btw. je taky docela super razitko zabudovane v peru, to se prodava, ale zase za nekrestanske penize :(.

Proc se integrace vice funkci porad odehrava jenom na urovni PC a Mobilu?

Jo to pero je dobre, zrovna jsem ho dostal na konferenci spolu s programem, atd. To pero ma 1GB flash disk, pero, a laserove ukazovatko (hned jsem ho rad pouzil pri prezentaci). Velmi sikovny napad od vyrobce a organizatoru konference.

Jestli je dobré? nevím taky jsem ho dostal od Hitachi, ale vydrželo méně než rok. Řeklo si o sformátování zrovna když jsem v něm něco přenášel, jako všechny flašky

Nikde se nemohu dočíst, jak je to s životností. Už jsem vyrozumněl, že SSD disky díky "chytrému" řadiči data ukládají tak, aby co nejvíce využily všechny buňky (a nedošlo k přepisování jedné oblasti).

Kolik ale v praxi tyto SSD disky vydrží? Myslím tím počet přepisů (a také nějaký odhad životnosti na roky).

Někde jsem četl článek, ve kterém autor, který se evidentně vyznal, tvrdil, že po dobu morální životnosti SSD (dejme tomu 5 let) vlastně není šance na to, aby došlo k jeho zničení, právě díky překládání adres bloků. Jde o to, že se těžko udělá takový zátěžový test, který by skutečně stále zapisoval do těch stejných buněk - řadič to nepovolí a zápisy rozloží. Takže jedna z možností je přepisovat celý SSD, ovšem to trvá poměrně dlouho a oněch garantovaných 100 tisíc - 1 milion přepisů se skoro ani nestihne :-)

Problem je, ze obvykle wear-levelling algoritmy nerozkladaji zapisy pres cely disk, ale jen pres jakesi relativne male clustery. Takze pokud budu zapisovat porad dokola par blizkych sektoru na flashce, tak se rovnomerne opotrebuji sektory z toho jednoho clusteru.

No soukrome jsem si tento test delal. Vzal jsem novou 128MB flashku (FAT) a proste jsem ji celou naplnil a zase smazal. A to delal rekurzivne a pocital. No dostal jsem se na pouhych 30000 zapisu. Pokud bych i vymaz bral jako zapis - ale predpokladam, ze se zapisuje opravdu pouze FAT tabulka (zkusenejsi me opravte). Tak je to pouhych 60000!

Podle mě jste ve skutečnosti udělal mnohokrát víc operací výmazu, vše na jednom místě - každá změna v souboru se dřív nebo později promítne 1) do FAT tabulky (prodloužení, zkrácení, realokace clusterů) 2) do místa, kde jsou uloženy základní info o souboru, tedy do "souboru" představujícího adresář.

Jak jste přesně dělal to naplnění a smazání? Přidávání dalších a dalších souborů, zvětšování jednoho souboru? FAT je (nejenom) pro tento typ pamětí prostě to nejhorší řešení :-), možná právě proto se stále používá.

Ještě se malinko doplním, že by skutečný počet zápisů šlo zjistit z logu jádra. To jsem pravda nedělal, ale když jsem třeba na disketu zapisoval více souborů, vždy bylo na konci každého souboru (který se zapisoval v ideálním případě sekvenčně, tj. byl slyšet jen krátký posun hlavy o jednu stopu), tak na konci zápisu každého souboru byl slyšitelný seek hlavy na začátek diskety, tj. na FATku s následným seekem zpátky na místo, kam se zapisoval další soubor nebo jeho část.

Přesný algoritmus, kdy se zapisuje do FAT asi bude záviset na systému - čím delší dobu se čeká, tím větší škoda v případě výpadku proudu a naopak - zápis každé změny znamená často seeky (disky, diskety) či ničení stáje stejných bloků nebo jejich skupin (jak už někdo poznamenal, tak se realokace provádí v menších clusterech, třeba na 1/64 disku).

Dulezita je preci otazka jestli ty soubory byly stejne a stale dokola . Potom podle me se zapis odehraval prave jenom ve FAT ta "datova" cast zustavala stejne tak to prece funguje uz od dosu .

To trošku nechápu. Pokud by byly soubory stejné, tak co by se vlastně změnilo? Přepis souboru beze změny jeho délky - ve FAT se nic nemění, vymazání souboru a jeho nové založení - mění se FAT + mnoho dalších údajů: v tomto případě by se pro každý zapisovaný soubor měnila FAT, takže jeden celý přepis USB by mohl dělat třeba 100x přepis FAT, potom se těm 30 000 zápisům již dá věřit.

btw, jestli je ten USB disk skutečně zničený, dalo by se pls poslat označení paměťového čipu? Třeba by google mohl něco najít, co je to za šmejd :-)

Už jsem ten článek konečně našel - http://www.storagesearch.com/ssdmyths-endurance.html

Zajímavá je hlavně tabulka, kterou najdete v sekci "How long have you got before the disk is trashed?"

Jedná se o článek zaměřený především na SSD, u USB disků s FAT je situace trošku horší (aneb pokud můžete - není zapotřebí USB disk používat na cizích počítačích, přeformátujte na lepší souborový systém :-)

Otázkou je který. NTFS, ext2/3/4, jfs, xfs, reiser je všechno +- stejný princip. A JFFS zase nebude oplývat u 32GB flashek rychlostí. A vyplatí se změnit FS, když si to řadič řídí sám?

Asi by to chtělo třeba vyzkoušet, jak se který souborový systém zachová v případě, že uživatel omylem odpojí USB disk při zápisu. Kolegyně takto přišla o data (na FAT) a to tak, že nezafungovala ani záložní FAT. Těžko říct, který systém by vyhrál, osobně jsem to nezkoušel.

"...A vyplatí se změnit FS, když si to řadič řídí sám?"

FS nema s radicem na flashce nic spolecneho. FS muzes pouzit takovy ktery potporuje tvuj OS, popripade OS na jinych pocitacich ke kterym budes flashku pripojovat. Takze jen pro Linux EXT, pro Linux a Win NTFS/FAT. Jak je na tom Mac s podporou FS nevim.

Ale může mít a to hodně. Stačí, jesli má řadiš implementovaný nějaký kruhovej algoritmus, tedy logické bloky nmapuje na fyzické tak, že je sám otáčí. Potom opakovaný zapis na blok 0 povede k reálnému zápisu na 1,2,3... V tomto případku je pak lhostejno, jaký FS se použije. Pokud je flash natolik pitomá, že slepě plní úkoly od hosta, pak si nezaslouží víc než to křemíkový nebe :)

R.

Primlouvam se za neprekladani zazitych terminu typu 'flash pamet'. Myslim, ze cistonosoplen uz bylo dost :-). Pri urcite koncentraci takovych umelych prekladu by se stal clanek uplne necitelnym.

Ten termin je puvodni (setkal jsem se s nim uz v roce 1995, jeste nez se tyto pameti rozsirily mezi bezne prodejce), rekl bych starsi, nez dnesni 'flash pameti', coz je mimochodem typicky hruzny preklad 'moderniho' jazyka, neco jako Gambrinus liga. Ale uznejte, ze jsem ty nazvy v clanku zminil oba, tak snad by ke zmatkum nemelo dojit.

Nějak se zřejmě pozapomnělo na paměti FRAM (nonvolatilní feroelektrické paměti s vlastnostmi podobnými RAM). Jejich výhodou je prakticky neomezený počet přepisů a uchování dat i bez napájení. Kapacity jsou zatím max. v řádu Mb, ale perspektivně by mohly nahradit paměti FLASH.

Klidně o FRAM něco napíšu (nějak mi není jasné, proč bych o nich nemohl nic napsat), tento typ pamětí je na trhu prozatím necelých deset let, takže se moc nestačil rozšířit, ostatně mu v mnoha oblastech konkurují jiné typy pamětí.

Jo napis, klidne i nejaky muzu poskytnout. Jejich problem je to, ze jsou drahy a to tak, ze se to nevyplati skoro nikde.

Mel jsem projekt, kde na cenu nebylo treba hledet, tak sem si vzal par kousku na testy, ale nakonec z toho seslo, slo se jinou vetvi. Prakticky jejich jedina vyhoda je totiz rychlost pristupu, daji se pouzit jako RAM, ale ta cena to (zatim) zabiji.

Je nanonymni asi tak stejne jako ty nebo ja.

Otázka možná tak trochu mimo mísu a s křížkem po funuse: u nás se bude stavět kaplička, architekt má v plánu do ní pod střechu dát nějaké artefakty doby. Klasická flaška slivovice, nějaké aktuální noviny, atd. a mezi tím nějaké paměťové médium s hromadou dalších věcí. otázka je prostá: jaké paměťové médium použít, aby po padesáti, sto letech(možná i více, až se bude dělat nějaká oprava, popřípadě bourání :]) šlo bez problémů přečíst?

Pokud chcete mít jistotu, tak bych doporučoval toto:

http://www.root.cz/clanky/zaloha-dat-tiskarnou-na-papir/

+ návod ke skenování (idálně v plaintextu včetně zdrojáku C, tento jazyk s námi určitě těch 200 let vydrží a když ne, tak ho v muzeu seženou.

je ale potreba pouzit velmi kvalitni papir opravdu ze dreva, jinak se to po pár desetiletích rozpadne.

dobrý, to znám, ale teď mi ještě teda poraďte jaký mám použít papír a způsob tisku aby to vydrželo aspoň tak dlouho jako na archivačním cd. :) typoval bych to tak na pergamen a husí brk namáčený do krve panen, nebo hliněný destičky a dláto. možná kovový destičky a nechat vyfrézovat na cnčku. problém je že toho je docela spousta a celý se to dá do nějaký odolný schránky, takže by se tam nic nevešlo.

Bod střechou předpokládám letní teploty kolem 50°C. To ani zlaté CD nevydrží 50 let. Možná tak lisované.

Časem mnohokrát prověřené paměťové médium je papír nebo jiný podobný mechanický záznam. Polovodičové paměti, optické a magnetické disky vydrží spolehlivě tak nízké desítky let.

Kamen/palena cihla vydrzi tisicileti, prakticky ozkouseno;) Jinak papir, ale chce to vybrat spravny druh papiru a inkoustu a ne prvni, na ktery se prijde, pripadne zmensit na kvalitni cernobily film, ten by po stabilizaci taky mel nejaky rok vydrzet. Moderni media sice mozna nejakych 100 let vydrzi, u zlacenych placek to aspon tvrdi vyrobce, problem je aby k nim pak sehnali mechaniku...

no kdyby to pak nebylo na čem přečíst, nejspíš by se to hodilo nějakýmu technickýmu museu, oni by si už někoho sehnali, kdo by jim za pár eurodolarů vyrobil mechaniku.

No, pravda, za sto let to bude v idealnim pripade o tom nasypat do nanoassembleru hrst prachu a zadat vhodny program;).

Ale zkusil bych se v nejakem archivu poptat na ty filmy, je to maly, ma to slusnou hustotu a na precteni staci nejake zvetsovaci zarizeni. Pripadne to zkombinovat, nejdulezitejsi na takovehle medium a k tomu par flashek a CDcek s kopiema a velkymi daty, pro pripad nahodou ze prezijou. Coz me jeste napadlo - smahnout to do nejake ROMky by mohlo byt jeste vyrazne odolnejsi.

Ano, maskou programované ROM či PROM vydrží docela dost (třicet, čtyřicet let je odzkoušeno), jen bych pro jistotu u PROM nakonec odstranil pin, na který se připojuje programovací napětí :-)

Díky pane Tišnovský za další přínosný článek ! Je to (bohužel) pomalu to jediné, co se tu ještě dá číst.

Při debatách s kolegy ohledně vhodného _domácího_ zálohování nás napadlo ukládat to na flasky a schovat do trezoru. Je to podle vás vhodné řešení?

Nejde o to to ukládat na 100let (takové řešení kromě analogových formátů - papír, fotografie - neexistuje), ale zajistit trvanlivost alespon 15let. I dnes občas hledáme dokumenty vypálené na CD v roce 1999. Je to fakt problém, páskové mechaniky jsou poměrně velká investice a DVD nevydrží (a kupovat DVD za 200kč, to už je lepší si pořídit pásku).

Jak píšete, flash paměti po čase zapomínají (ztrácí se náboj), jakou mají tedy reálnou trvanlivost?

Obvykle je gatantovana trvanlivost dat 10 nebo 20 let pro urcity pocet zapisu. V praxi to vypada tak, ze zivotnost dat se snizuje s poctem zapisu, ktere byly do dane bunky provedeny (pri zapisu dochazi k degradaci oxidu, ktery izoluje naboj v plovoucim hradlu, takze naboj unika o neco rychleji).

Zde bude zápis jen jeden. Ještě mě napadlo, jak velký blok dat se vlastně stane nečitelným? U disků se čte celý sektor 512B, zde 2048?

otázkou je, jestli to zrovna autor nemyslel, jako že je úplně běžné že řadič provádí relokaci, tedy né vlastní pamět, která je defacto docela hloupá. Protože jen chytáte dotýčného za slovo.

IMHO přesně toto je v článku napsáno :-)

Jak úspěšně zálohovat 100 let? No napadadá mě vyčlenit se vždy jeden den v roce a přenést všechny staré zálohy na nová média, nejlépe v několika kopiích na médiích od různých výrobců a v několika systémech. Takhle to dělat až do smrti, nesmí se zapomenout na správnou výchovu potomků, aby v této činosti pokračovali do skonání světa a rodu.

Pro mně je tězko pochopilených pár faktů kolem Flash pamětí.

Celkem chápu, proč se s historických důvodů používá pro Flash naprosto nevhodná FAT.
Je mě naprosto jasné že je to jeden z důvodů, proč je kryticky nutné použít algoritmus pravidelného „vytěžování“ jednotlivých bloků.
Ale není mě jasné jak takovýto algoritmus funguje (jak pozná volný a obsazený blok). A už vůbec mě není jasné proč výrobci neuvádí který algoritmus je použit a jesli vůbec je použit, když je tento údaj pro způsob použití naprosto zásadní. Asi by téma stačilo na samostatný článek.

Na úrovni OS se dá vytěžování řešit na úrovni souborového systému. Příklad je JFFS a JFFS2. Ale tyto systémy nepracují s bloky stejně jako jsme zvyklí, ale při zápisu zapíší soubor, aktualizace souboru neznamená přepsání původního, ale zápis patche. Filesystém de fakto funguje jako žurnál kdy se při čtení musí na původní obsah aplikovat všechny následné patche. Smazání souboru se neřeší uvolněním bloků ale zapsáním záznamu o smazání. Uvolňování bloků dělá pouze "garbage collector" který vybírá sektor s největším množstvím jinde aktualizovaných nebo zmazaných dat (dirty sector), zapíše zbývající aktuální data jinam do flash a sektor následně uvolní. Tento popis je krutě zjednodušující, přesto je to fascinující námět na článek (neumím to pořádně vyložit). Chápu proč se to dělá takto, právě proto nechápu jak to dělá řadič kvůli vytěžování bloků.

Nevíte to někdo? Alespoň URL.

S těmi souborovými systémy máte pravdu, v podstatě však nic nebrání tomu si USB disk či SSD naformátovat na jakýkoli jiný souborový systém. U SSD to je nejmenší problém (disk se pravděpodobně nebude nikam přenášet), u USB to může být horší, na druhou stranu však při běžném použití USB disk spíš zničíte mechanicky dřív, než se vadné bity začnou projevovat v takovém množství, že to již řadič nezvládne. Ve fotoaparátech a podobných zařízeních je to podobné - počet zápisů do FAT je (zhruba) totožný s počtem "nacvakaných" fotek, což v nejhorším případě dělá cca 500 000 fotek (FAT není jedna stránka, je také rozložena na větší plochu čipu).

Poměrně zajímavé informace (ne přímo o algoritmu realokace ale obecně) lze najít na http://www.storagesearch.com/ssdmyths-endurance.html

...u všech paměťových karet které obsahují i řadič...

Před "které" patří čárka. Jinak díky za článek, je to pro mě jeden z posledních důvodů pro navštěvování tohoto serveru.

Je škoda, že se článek nevěnuje více právě USB flash pamětem. Vyzkoušel jsem jich řadu a samotného by mne zajímalo, čím se vnitřně liší ty rychlé od pomalých. A jak je možné, že časem se mi stalo, že rychlost šla dolů nebo že vyreklamovaná nová flashka už byla horší (změna SLC a MLC během výroby?).

Další zajímavá vlastnost asi vyplývá z pomalého mazání bloku. Například po koupi nové flashky jsem hned testoval zápisem velkého souboru, jak je dobrá a byl jsem příjemně překvapen. Po chvíli (přesněji po zaplnění všech bloků) se zápisy cca o 25% zpomalily. Vysvětluji si to tak, že před prvním zápisem se nic nemuselo mazat, zatímco při všech dalších přepisech už ano. Proč se ale bloky třeba neuvolňují při mazání souborů? Nebo při formátování?

Proč vlastně neřeší ovladač USB disku dostatečně kešování zápisů tak, aby se opravdu do bloku psalo až po "zaplnění" tohoto bloku všemi zápisy? Pak by zápis malých souborů byl stejně rychlý jako jednoho velkého.

> Proč vlastně neřeší ovladač USB disku dostatečně kešování zápisů tak, aby se opravdu do bloku psalo až po "zaplnění" tohoto bloku všemi zápisy?

Protoze by k tomu potreboval dost RAM, zatimco ty radice nejspis maji buffer tak na jeden nebo dva ty velke bloky.

EEROM

JFFS2 je funkčný, no zápis je beštiálne pomalý. Práve preto bol pre 2.6 spáchaný UBIFS.

Documentation/filesystems/ubifs.txt

4 Eraseblocks become worn out after some number of erase cycles -
typically 100K-1G for SLC NAND and NOR flashes, and 1K-10K for MLC
NAND flashes. Blocks do not have the wear-out property.

In a sense, UBIFS is a next generation of JFFS2 file-system, but it is
very different and incompatible to JFFS2. The following are the main
differences.

* JFFS2 works on top of MTD devices, UBIFS depends on UBI and works on
top of UBI volumes.
* JFFS2 does not have on-media index and has to build it while mounting,
which requires full media scan. UBIFS maintains the FS indexing
information on the flash media and does not require full media scan,
so it mounts many times faster than JFFS2.
* JFFS2 is a write-through file-system, while UBIFS supports write-back,
which makes UBIFS much faster on writes.