Dotaz: SSD disk a linux

[iron-man]

Chci si do pocitace kde pouzivam vyhradne linux distribuci (debian, centos) poridit ssd disk. Co vy na to?

---

---

Odpovědi

[eagle.metawerzum]

Co bych na to… Beru na vědomí.

[debianista]

Když napíšeš beru na vědomí, tak to nemusí znamenat, že to schvaluješ, což může taky znamenat, že to neschvaluješ. Chudák tazatel.

[Michal Kubeček]

Ale přesně tak jsem to myslel: "tazatel" nám oznámil, že si chce pořídit SSD, a zeptal se, co my na to; tak jsem mu odepsal, že to beru na vědomí. Kdyby se zeptal, jestli mu to doporučujeme, nebo se dokonce zeptal na něco konkrétního, odpověděl bych jinak.

[Nereknu]

Nechapu dotaz. Chces poradit jaky SSD nebo jestli linux podporuje SSD?

[jadd]

Jaký SSD - závisí na tom jak naditou máš peněženku a jak velkou kapacitu potřebuješ.

Z hlediska podpory SSD - ano, linux podporuje SSD, pokud tě zajímá podpora TRIM tak ta je už od jádra 2.6.33. Filesystémy které pak TRIM automaticky používají jsou Ext4, Btrfs a XFS. Nicméně je nutné nejprve si to povolit ve fstabu.

[iron-man]

Tak slo my o vase zkusenosti. Hlavne jestli nekdo pouzivate a jakou mate zkusenost? Nekde si lidi stezuji na nizkou zivotnost ssd disku v linuxovych strojich kvuli castym zapisum na disk.

[Michal Kubeček]

Jeden SSD (120 GB Corsair) mám v netbooku místo původního klasického disku a rozdíl je obrovský. Především odpadly otravné prodlevy na roztáčení disku, ale i další operace se výrazně zrychlily (např. uspání na disk a probuzení z něj). Spotřeba se o něco snížila, ale nějak zásadní rozdíl to není, rozdíl hmotnosti je 20 gramů, takže taky nic převratného. Na druhou stranu už to, že se nemusím bát, že při provozu netbookem nedopatřením ťuknu o stůl a odejde disk, je obrovské plus.

Druhý SSD, 60  Corsair SATA-300, používám v pracovním desktopu pro kořenový filesystém, partition, kde je chroot pro lokální buildy z BuildService, a partition, kde mám virtuální stroj (VMware Workstation) pro krátkodobé experimenty. Na rychlosti buildu je to hodně znát, např. kompletní zabalení jádra pro SLES 11 SP1 se zkrátilo z 52 minut na 36 minut. (Ideální by samozřejmě bylo použít tmpfs, ale k tomu by bylo potřeba přejít na DDR-3 paměti, a tudíž vyměnit základní desku a procesor.) I u virtuálního stroje je rozdíl znatelný, hlavně např. na rychlosti instalace systému.

Takže co se týká výkonu, naprostá spokojenost v obou případech. Co se týká výdrže, nemůžu sloužit, jeden mám teprve tři čtvrtě roku, druhý asi půl.

[Michal Kubeček]

Ještě pro úplnost: jako filesystém používám ext4 s option discard.

[Atom321]

Zápisy na disk se dají částečně zredukovat vypnutím ukládání času posledního přístupu k souboru (parametrem noatime).

SSD mám v noteboku půl roku a nemůžu si ho vynachválit. Provozuju to bez TRIMu (mám stabilní=zastaralou distribuci). Místo toho jsem při rozdělování disku nechal 10GB neobsazeno, aby měl řadič prostor pro wear-leveling. Žádné zpomalení zápisu ani jiné potíže nepozoruju.

[JanM]

Místo toho jsem při rozdělování disku nechal 10GB neobsazeno, aby měl řadič prostor pro wear-leveling.

Můžete se k tomu trochu rozepsat?

IMHO, nebyl by efekt stejný, kdybyste těch 10 GB přiřadil některému oddílu a udržoval jeho zaplnění takové, aby bylo alespoň 10 GB volných?

[chrono]

Keďže nepoužíva TRIM, tak by disk nevedel, že v tom oddieli je nejaké volné miesto (pretože disk nerozumie súborovým systémom a aj vymazaný súbor by považoval za uložené údaje).

[Tomáš Bžatek]

SSD maji interne vetsi kapacitu nez je prezentovana logicky navenek, prave pro potreby interniho wear-levelingu. Nechavat 10GB volnych je zkratka blbost.

[Atom321]

NAND flash použitá v SSD neumožňuje přepisovat data. Vždy se musí vymazat a zapsat celý sektor. Mazání trvá dlouho, zápis je relativně rychlý.

Proto disk při přepisu starých dat řadič SSD disku zapíše nová data do nějakého volného (vymazaného) sektoru. Ten pak přemapuje na místo toho původního. Původní sektor označí jako "špinavý/nepoužitý" a zatím ho nemaže, aby nezdržoval další zápis. Ve volných chvílích, kdy se s diskem nepracuje, se pak špinavé sektory postupně mažou a přidávají do rezervy volných.

Problém je, pokud volné sektory dojdou dřív, než je řadič stihne promazat. Pak už není kam zapisovat a musí se mazat hned. To způsobí zpomalení zápisu.

Při smazání souboru operační systém řekne disku příkazem TRIM, které místo už nepoužívá. Disk pak má k dispozici více volných sektorů ke smazání ve volných chvílích. Více volného místa umožňuje delší zápis bez mazání (=bez zpomalení).

Pokud příkaz TRIM nefunguje, disk se o smazání dat nedozví a stále je uchovává. Proto nechávám volných 10GB, na které nebylo nikdy nic zapsané (!) a řadič disku ví, že jsou volné. (Tedy je to stejné, jako kdybych smazal 10GB s funkčním TRIMem.)

[Tomáš Bžatek]

To zni logicky, ale co se stane, az se tech 10GB volnych dat vyuzije? Tzn. podle Tve teorie dejme tomu, ze mas temer plny disk a 10GB nepartitionovaneho mista. Smazes bez TRIMu 20GB dat, misto nej narychlo nahrnes jinych 20GB. Disk by interne vyuzil toho 10GB volneho mista a stare bloky oznacil jako nevyuzite. Jestlize se ale musi pred zapisem mazat (princip Flash NAND), bude to delat radic simultanne k zapisu novych dat do vymazanych bloku? Teoreticky muze, SSD radice maji bezne 8 a vice kanalu, ktere by mohl zamestnavat zvlast. Pokud to ale delat nebude a bude si vytvaret interni frontu I/O pozadavku, vyjde rezervovane misto z hlediska vykonu vnivec, protoze mu najednou dojdou volne vymazane bloky a on bude muset postupne mazat ty oznacene jako nevyuzite.

Teorie je to velice zajimava, ale chtel bych videt nejake cisla.

[Petr Šobáň]

Pak se SSD tak spomalí že je nepoužitelné.

A proto pro některé SSD existuje program co provede trim sw - projde fs a označí řadiči které sektory jsou volné a které má začít mazat jako přípravu pro zápis. (Jestli existuje verze pro linux a linuxové fs nevím, ale asy bych řekl že ne.)

[lertimir]

A i když SSD technologie je zcela rozdílná, tak je zde podobnost s HDD v tom, že při vysokých zaplněních disků se systém zpomaluje k nepoužitelnosti. Nemám pod palcem žádné opravdu velké enterprise systémy, ale na pracovních serverech, které řídím, mám zaplněnost tak mezi 30-50%. A moje zkušenost je taková že od 65-70% jde už výkon citelně dolů a v podstatě každé procento je znát. Je jasné, že u HDD je to tím, že systém při zápisu potřebuje najít volné místo poblíž každé polohy hlaviček a u SSD o zaplnění volných bloků, což je jiné, ale připadá nesmyslné provozovat SSD i HDD poblíž plné zaplněnosti. To si mohu tak ještě dovolit u domácích disků s multimediálním obsahem, kde mnoho lidí má 2TB disky a 5GB volno, ale ne u čehokoliv, kde chci jakýkoliv výkon.

[Šangala]

No nevím - žena má 16GiB disk (DELL Mini 9") déle než 3 roky neustále minimálně z 92% plný (první dva roky tak z 85%), stále aktivně v provozu a nějaké zpomalení nepozoruji (Ubuntu 8.04 - žádný Trim) a to několikrát už byl úplně full.

[Petr Šobáň]

Taky záleží na řadiči a jeho FW.

Vím že modernější disky už nejsou tak náchylné když není trim. (Je rychlejší mazání neprázdných buněk a u domácího PC nemusí být to spomalení znát pokud nezapisuješ naráz hromadu dat..)

[Šangala]

No v tom DELL-u novinka zrovna nebude. Beru to v tomto případě uživatelsky, na svém NTB mám SSD disk, na pracovních stanicíh od DELL-u už jsou taky, a všechno lítá jak z praku, tak jsem zvědavý jestli ty „teorie“ se začnou prakticky projevovat. Osobně si „myslím“, že praktický dopad na běžných PC, i vytížených, se nijak neprojeví, za důležité považuji jen zarovnání partition, či LVM či LUKS, či RAID-u, mluvit začnu jinak, až mě nějaký SSD disk začne zlobit (zatím jen ze čtyř, co mám někde u sebe/pod sebou, ale plánuji další dva až tři)…

[Heron]

tak jsem zvědavý jestli ty „teorie“ se začnou prakticky projevovat

Taky. Ale i kdyby ten disk chcípnul den po záruce, tak udělal skvělou práci, které se s konvenčními hdd dosáhnout nedá.

[Atom321]

Rozdíl je v tom, že prvních 10GB z celkových 20GB zapíše rychle.

Jinak celá tahle úvaha je jen hypotéza. Nahradil jsem nefunkční Trim volným místem. Nic jsem neměřil, nemám s čím to porovnat a nedokážu posoudit, jestli to mělo smysl. Můžu jen říct, že půl roce normálního používání 120GB SSD Intel 320 s volným místem 10GB bez Trimu nepozoruju žádné zpomalení.

[Heron]

Ono to také může být tím, že ten disk samotný má nějaký svůj spare prostor (oněch 8GiB do 128?) a firmware s tím (na rozdíl od volného prostoru v podobě nevyužitého oddílu) může lépe počítat. Jen domněnka.

[hermitek]

SSD nemám dost dlouho na to, abych mohl informovat ohledně životnosti – ale používám TRIM (stačí mít dostatečně nový kernel (aspoň 2.6.33) + discard parametr u diskového oddílu), /tmp spolu s /var/tmp mám připojen do RAM; a u prohlížeče mám vypnutou diskovou cache. Na zbytek systému se zas tak nešahá – a i kdyby, tak při běžném používání by SSD měl vydržet docela dlouho.

[Šangala]

Mám v NTB skoro rok, na kernelu který trim nepodporuje, (doufám, že nekecám Debian Squeeze - distribuční, ale mám nastaveno discard a relatime).
NTB má dual boot s Windows 7, disk rozdělen cca na půl s win, jsem nic nedělal a podle mě jsou blbě zarované (začátek partition).
Na Debianu mám LVM-ko, jednu volume šifrovanou, /tmp je v paměti, mám i swap, ale používání je potlačeno hodnostou swappiness (Linux partition - jako 2. partition, pro LVM, LVM nastavení i LUKS vše zarovnáno správně).
Už nechci pro práci, to jak se to točí dělá to randál, topí to a žere to elektriku, je to zásadní výkonový rozdíl.

Pracovní stanice DELL, co se nu nás nakupují, mají vždy systémový SSD disk (už asi taky rok).

Na DELL mini 9" je SSD disk 16GiB neustále z 90% plný, v provozu snad 10 hodin denně (o víkendu obvykle méně) s Bubuntu 8.04 (řádný TRIM :)), v provozu více než 3 roky, stále OK bez chyby.

Moje rada: „kupovat Intel“.

[iron-man]

Diky panove to je presne co jsem potreboval. Utvrzeni, ze neni zadny problem s SSD disky na linuxu. Pujdu tedy do intelu http://www.czc.cz/intel-ssd-520-120gb-oem/102300/produkt

[Begleiter]

Jak je to s externími boxy pro pevné disky? Musí také podporovat TRIM? Pokud koupím interní SSD podporující TRIM a dám ho do boxu, jehož vnější rozhraní je USB 3.0, jak to bude s podporou TRIM?

[frr]

Záleží na rozhraní toho externího boxu. Třeba eSATA je jenom konektorová redukce - takže pokud tvůj kernel a ovladač HBA umí TRIM, lze ho poslat po SATA/eSATA kabelu.

USB Mass Storage pokud vím neumí TRIM. Ono to neumí ani SMART. Ono to neumí i další věci...

Existují ale USB/SATA převodníky (konkrétní modely čipů Cypress?) které umí režim "transparentní tunel SATA over USB". Což Linux podporuje. Pak funguje SMART, funguje TRIM, a případně další věci, co běží nad ATA/SATA. Nikdy jsem takovou hračku v ruce nedržel, nemohu doporučit konkrétní model kastlíku na našem trhu.

Jiná věc je, nakolik je ten TRIM na SATA vlastně užitečný. Jednak je nefrontovatelný, takže vždycky zarazí/vyprázdní NCQ frontu, druhak v některých implementacích (na straně SSD) dost zdržuje. Četl jsem svého času nějakou debatu v LKML, kde se guru od blokové vrstvy bavili o tom, že nakonec nejlepší způsob jak používat TRIM, je nepoužívat ho vůbec a jenom pozměnit vzorce přístupů k disku tak, aby se hezky přepisovaly celistvé bloky, aby disk neměl moc práce s wear levelingem... Je to tak dva roky zpátky, možná se mezitím změnilo dost k lepšímu. A konkrétně SCSI (SAS) má myslím už i "frontovatelný TRIM" - už asi rok na papíře, netuším jestli už to umí i disky.

[Begleiter]

Děkuju.

[Tomáš Bžatek]

Vidis, nejaky Cypress tu mam a SMART jde cist normalne. Vic jsem ale nezkousel, USB je hodne uzke hrdlo samo o sobe.

[danc]

to jeste nic neni: SSD a linux,

co teprve SSD a LUKS sifrovane partition?

nastesti ani to neni na dostatecne cerstvem jadre a cryptsetupu problem:

How to Activate TRIM on LUKS Encrypted Partitions in Ubuntu & Debian

ovsem muze to mit urcite dopady na bezpecnost, proto neni TRIM na LUKS standardne zapnuty:

TRIM & dm-crypt ... problems?

[lertimir]

A celé je to způsobeno tím, že se v podstatě nikdo nezabývá tím, jaké struktury filesystémů by byly správné a efektivní na SSD discích. Pořád se k nim chovají jako k rychlým HDD a to je nesmysl. Potom výrobci zakrývají hardwarové informace, kdy přesvědčují OS, že SSD disk má 512 bytové sektory a vzhledem k tomu, že filesystémy s nimi pracují blbě (jako s HDD) tak to flikuji v hardwaru tím, že mají TRIM, wear leveling, reportují nižší diskovou kapacitu a podobné obezličky, protože filesystémy se chovají nesmyslně a na druhou stranu filesystémy se nemohou vyvíjet správným směrem, protože od HW nedostanou reálné informace.

Tři roky píšu názor, že používáme SSD podobně, jako bychom používali HDD před 35 lety pomocí operací a struktur vyvinutých pro páskové jednotky. Myslím, že to co by bylo mnohem lépe funkční je.

1. Hlavní a nejdůležitější je, aby SSD skutečně hlásily reálný stav hardwaru. Tedy jednak velikost skutečného sektoru a patrně i informaci pro každý sektor, kolik na něj proběhlo zápisů. Rozlišení by bylo třeba tak, že by na SSD byla propojka, která by rozhodla o chování jako současný zakrývaný režim nebo přesný reálným režim.
2. Pak může být přístup na SSD optimalizován na úrovni celého filesystému, ne jen to flikovat TRIMem a wear levelingem bez porozumění struktur. Filesystém pro SSD by měl zapisovat celý 512 kB blok naráz a pouze jednou a uvnitř toho bloku pracovat se sektory nějaký podobným způsobem jako jsou filesystémy založené na cirkulálním logu jako NILFS, protože SSD má v podstatě nulový seek a dá se s ním v readu pracovat skoro jako s pamětí.
3. A proto abychom mohli zapisovat data i v menších kusech než je 512 kB (to je poměrně moc) tak SSD by mohl mít nějakou malou RAM včetně malého kondenzátoru, který by měl dostatek energie, aby zapsal data z RAM do flash paměti v případě neočekávaného výpadku napájení

Možná to není, žádná super myšlenka a můžeou být mnohé lepší, ale to, že se filesystémy na SSD neřeší mě připadá hodně zarážející.

[pavlix]

Jestli to není tím, že celý systém SSD disků je technologicky zcestný už tím, že se snaží předstírat, že v té pixle je něco, co se používá stejně jako klasický hard disk. Zkus se někdy podívat na filesystémy určené pro ty paměti, co jsou uvnitř SSD disků tedy fungují bez té blokové emulace.

Nehledě na to, a teďka se rovnou přiznám, že vařím z vody, se dá očekávat, že různá SSD se budou projevovat různě.

[lertimir]

Však to také píšu. To předstírání je základ problému, na druhou stranu když předstírat nebudou, nic neprodají, protože pokud by zařízení oznámilo skutečné parametry, není použitelný filesystém, který je bude řídit. Lehce jsem se díval na UBIFS a LogFS, ale to jsou experimentální filesystémy jejich stav je tak na úrovni btrfs před 3 lety. Vidím to špatně dokud se Microsoft nerozhodne, že udělá filesystém pro SSD disky a nebude požadovat, aby výrobci posílali ven reálné údaje. Podle mne nikdo kromě M$ nemá dostatečnou marketingovou vyjednávací sílu, aby na něj výrobci nekašlali.

[Filip Jirsák]

Tu sílu má MS podle mne jenom na desktopu. Myslím, že pokud se ukáže, že technologie SSD je použitelná v serverech a třeba poskytovateli cloudových služeb může ušetřit nějakou tu elektrárnu, může být tlak i z téhle strany. Pak samozřejmě bude záležet na tom, zda se ten komunikační protokol ze serverových SSD přenese i na desktopové.

[chrono]

SSD disky, s porovnateľnou kapacitou ako disky "normálne", budú mať výrazne vyššiu spotrebu, takže kvôli úspore elektrickej energie určite také disky nasadzovať nebudú. :)

[Filip Jirsák]

Kapacita normálních disků je dobrá akorát tak na multimediální obsah, na spoustu obsahu bohatě stačí kapacita současných SSD disků. Odkud se vezme ta výrazně vyšší spotřeba by mne taky zajímalo, zvlášť když to porovnáváte s pohonem otáčení disku, pohonem hlaviček a klimatizací.

[lertimir]

+1. Souhlas. Hlavně u "normálních" disků za posledních 10 let výrazně se posunul poměr mezi přenosovou rychlostí a kapacitou disku. Sekvenční přenos na běžném disku je cca 100 MB/sec což na přenos 2TB disku potřebuje 20 000 vteřin. Navíc strašný seek time způsobí, že paralelní přistup na malé soubory, přenosy skoro zastaví. 400kB/s je absurdní rychlost pro server. Tyhle disky jsou v serveru jen na zálohování.

[pavlix]

Však to také píšu. To předstírání je základ problému, na druhou stranu když předstírat nebudou, nic neprodají, protože pokud by zařízení oznámilo skutečné parametry, není použitelný filesystém, který je bude řídit.

To je nesmysl. Jen by se to neprodalo za tolik peněz. Slyšel jsem ošklivé rčení, že SSD je způsob jak prodat levnou paměť za několikanásobek ceny.

[lertimir]

Já ti nevím. O všem mluvíme, že je moc drahé, ale právě u flash disků si s tím nejsem vůbec jistý.

Jednak nejlevnější flash stojí něco přes 16G->250Kč, 32G->500Kč, takže 128Gb je za 2000Kč v nejlevnějším provedení, se strašnou rychlostí, bez paralelizace, SSD disk který má hw na paralelní přístup k jednotlivým 8Gb die stojí teď cca 2800-3000Kč. Takže 1000Kč je za rychlost, množstí I/O operaci a paralelizaci.

Za druhé současné 25nm MLC NAND paměti se dělají v max kapacitě 8Gb die a tato die zabírá 167mm^2. To je více než dvoujádra Sandy Bridge a 77% procent čtyřjádra Sandy Bridge. Technologický proces je v podstatě stejný. Na 12GB disk je potřeba 16 čipů a spotřebuje se 12krát více plochy než na čtyřjádro Sandy Bridge. Spíše to dává info, jak moc jsou předražené procesory, nebo jinak kolik ceny procesoru je design a kolik je technologie výroby. Zdroje informací 1, 2, 3 a 4

A za další co dělat s reálnou informací. Když by mi disk hlásil že má 512KB sektory tak jak se s tím vyrovnají file systémy? Co udělají file systémy když by dostaly informaci o tom kolikrát sektor byl zapsán a kolik je celkový počet možných zápisů? Podle mne to nezvládnou, protože v jejich designu s tímto nikdo nepočítal. Navíc všechny filesystémy implicitně počítají s fyzikálními vlastnostmi HDD, tedy, že následující sektor je "lepší" než nějaký náhodný, optimalizují charakteristiky přístupu do sekvenčních operací, ale na SSD to nemá smysl, každý přístup je náhodný přístup do paměti a je to jedno kam se adresně obracím. Potřebuji na SSD jiné optimalizace ty v současných filesystémech nejsou.

[kyytaM]

Cca 1/2 roka dozadu som cital clanok o tom, ze SSD je vlastne slepa cesta, ktora len premostuje prechod od klasickych HDD k nejakej novej technologii, ktore su zatial len niekde v laboch IBM, Fujitsu a podobne... SSD da v podstate nema uz velmi kam vyvijat - zmensovanie vyrobneho procesu sice zlacnuje kapacitu, ale zaroven aj znizuje zivostnost, co sa riesi vacsou "skrytou" kapacitou. Paradoxne mnohe ultra lacne SSD maju tak otrasny vykon, ze klasicky disk je oproti tomu zazrak. A mat na tom nezalohovane data je hazard najvysieho stupna. :)

[Filip Jirsák]

Paradoxne mnohe ultra lacne SSD maju tak otrasny vykon, ze klasicky disk je oproti tomu zazrak.

To máte potvrzené testy simulujícími reálnou zátěž, je to váš pocit na základě používání obou technologií, je to jedna paní povídala nebo je to fáma?

[kyytaM]

Ked neverite mne, skuste pozriet napr. tu, alebo tu. Niektore tie starsie lacne SSD hovna maju menej IOPS ako 5400 desktopove disky. A sekvecny zapis na urovni starsieho 5400k notebookoveho disku.

[Michal Kubeček]

1. Oba testy jsou více než tři roky staré. Podle vás se za tu dobu se v nabídce SSD a jejich parametrech nic podstatného nezměnilo?

2. Nejhorší SSD v tom testu má seek time 1 ms. Nevzpomínám si, že bych někdy viděl klasický disk pro běžné domácí použití, který by měl méně než nějakých 6-7 ms, dnešní jsou spíš na 10 ms.

3. Je tam skutečně několik málo modelů, které v přenosové rychlosti dosahují dost slabých hodnot. Když se ale podíváte pozorně, jeden z nich je na rozhraní (P)ATA, další tři na SATA-150. Kolik takových dnes v nabídce obchodů najdete?

Sečteno, podtrženo: vaše tvrzení se zakládá na více než tři roky starém testu tehdejších disků, tedy v podstatě těch prvních SSD, které se vůbec objevily na trhu. Pro toho, kdo dnes zvažuje, zda si pořídit SSD, je takový test asi tak stejně relevantní jako kdybyste tomu, kdo uvažuje, jestli si pořídit koně nebo auto, doporučil test z roku 1900.

[kyytaM]

Co?? Pisal som to, ze ked je nieco flash alebo SSD znamena, ze je to automaticky rychlejsie a lepsie ako SSD. Niekto mi odpisal, ze to nie je pravda. Tak som mu posunul linky, kde je moj prispevok potvrdeny testami. Sam som zazil jedno taketo SSD hovno, ten stroj bol kvoli tomu pomalsi ako keby bol s najlacnejsim notebookovym diskom. Super, ze seek pri nejakom teste je 1 ms, ale IOPS pri desktopovom pouzivani boli horsie ako pri 5400 notebookovom disku a bolo to pri praci aj naozaj citit.

[Michal Kubeček]

Víte, v diskusi o tom, zda si (teď) pořídit SSD, se většina lidí z logiky věci baví o těch SSD, která jsou dnes v nabídce obchodů, ne o těch prvních, které přišly před lety na trh. Stejně tak jako když se bude někdo ptát na procesor do nového počítače, bude mimo mísu mu předhazovat parametry 8088. Nebo zůstaneme-li u disků, vy to také nesrovnáváte s 10MB MFM modely z konce 80. let.

[lertimir]

Rozhodně si nemyslím že SSD je slepá cesta. A nastává i zde situace, která u HDD nastala tak před 10-12 lety. Díky velké poptávce bylo v oboru dostatek peněz na velmi intenzívní výzkum, který vedl k objevům jevů na kvantové úrovni, které následně umožnily aplikovat jinou technologii a zásadně zvýšit hustotu záznamu na plotnách. Nyní se ukazuje, že co se týká disků jsou na obzoru technologie (kvantové magnetooptické jevy a práce na předpřipravených doménách), které by umožnily ještě jednou a na discích změnit principy technologií a už naposled zvětšit kapacitu.

Pro SSD disky současná obrovská poptávka postupně má zásadní zlevnění technologie. Jak jsem psal 120GB SSD disk spotřebuje více než 10 více plochy křemíkové plotny než procesor, tím pádem potřeba vyrábět NAND čipy levně je velmi velká. Do rozvoje flash disků byla hlavní spotřeba na procesory a grafické chipy.

To že blbě udělaný SSD disk může mít špatné parametry je zřejmé. Zápis do jeho paměti je velmi časově náročná záležitost a pokud okolní elektronika, nemá kvalitní techniky tak toto kompenzovat tak zápis je tristní. Používám dva "SSD disky" jeden, v pracovní stanici je OCZ Agility 3 o 120GB paměti, a stanice jede jak z praku. boot do logovacího okna v kdm je za cca 7 vteřin a najeti KDE po loginu asi 6. Prakticky všechny KDE aplikace najíždí do 1-2 vteřin po spuštění. I takový moloch jako gimp nebo digikam či libreoffice najede za 3-4 vteřiny. Je to rychlost, která už mne jinak neomezuje. Aktualizace baličků po stažení v podstatě jen proletí. Disk má slušné řízení a je už té verze, kde SandForce opravily problém pro řadič a nikdy to nespadlo. Druhý je obyčejný levný flash disk o 8GB který mám jako systémový disk pro domácí server. Má v podstatě jen systém a vše kam se píše jako /var nebo /run mimo tento "disk". Na read je v pohodě a v klidu a dostatečně rychlý protože po startu má vše v podstatě v paměti. Při aktualizaci balíčků je nesmírně pomalý a přenosové rychlosti jsou na úrovni stovek kB/s. To je jasný přiklad toho, že design elektroniky nemá žádné optimalizace a pak slabiny se projeví naplno. Pro mne to není podstatné, protože do disku se standardně vůbec nepíše a systém mám zazálohovaný takže když by flash klekla (samozřejmě flash nemá žádné wear leveling) jen systém obnovím na jinou.

[Filip Jirsák]

Zápis do jeho paměti je velmi časově náročná záležitost a pokud okolní elektronika, nemá kvalitní techniky tak toto kompenzovat tak zápis je tristní.

Ovšem lépe, než sebelepší elektronika na disku, by tohle "kompenzoval" právě souborový systém navržený speciálně pro SSD. Něco možná kompenzuje snaha souborových systémů pro rotační disky zapisovat souvislé bloky sektorů (kvůli přesunům hlaviček), takže pokud si elektronika disku počká, může shodou okolností dostat data pro zápis do jednoho fyzického bloku SSD. Ale lepší by samozřejmě bylo ta data takhle cpát disku cíleně.

[lertimir]

Však to píšu celou dobu.

[kyytaM]

Btw. podla vasej logiky je 3 roky stary server alebo desktop na urovni auta alebo kona z roku 1900? ;)

[Michal Kubeček]

Počítač jako celek ne. Ale SSD z konce roku 2008 rozhodně ano. Uvědomte si, že to byly vůbec první modely, které se na trhu objevily.

[Ash]

Možná by sis měl ujasnit, o čem vlastně diskutuješ. Předtím jsi srovnával klasické disky a (tři roky staré) SSD disky. Proč sem tedy teď taháš "server alebo desktop"? SSD není zkratka pro server, a disk není zkratka pro desktop.

SSD disky byly před třemi lety výrazně horší než dnes, to je asi to podstatné, co by sis z této diskuze měl zapamatovat.

[kyytaM]

Skus si precitat toto vlakno od zaciatku a mozno aj zistis, ze si uplne mimo. Ano SSD disky boli pred 3 rokmi horsie ako dnes (kto by to bol povedal??). Bavili sme sa o SSD technologii a to, ze pred 3 rokmi cela cast toho noveho segmentu bola totalne nepouzitelna prave hovori o tom, ze SSD je i dnes velmi mladou technologiou, ktora ma svoje nevyriesene (nevyriesitelne?) problemy. A dodnes su medzi jednotlivymi SSD priepastne rozdiely.

[Filip Jirsák]

Propastné rozdíly ale popírají vaši teorii o nevhodnosti technologie. Propastné rozdíly totiž znamenají, že některé SSD jsou dobré nebo velmi dobré, takže výrobce ty nevyřešitelné problémy asi nějak vyřešil.

[kyytaM]

Vyriesili zvotnost? Ako? :))) A co tie cenove rozdiely? Cize si musim kupit nieco poriadne drahe aby to nebolo dalsie SSD hovno s chybnym firmverom a zlym navrhom (takze vlatne potvrdzujete, ze stale su niektore SSD nedobre), ktore treba po par mesiacoch reklamovat? Alebo co sa to tu vlatne riesi? Nejako sa to tu zacyklilo...jeden o koze, druhy o voze, ale kazdy sa bude do absurdna hadat o nejaku svoju pravdu v prispevku, ktory bol v kontexte od zaciatku mimo misu...

[Ash]

Jak? Však životnost závisí na použité technologii, to je úplně stejné u SSD jako snad u čehokoliv jiného, to udává trh, vždy tu bude lowend i hiend.

Ano, pokud chcete disk s lepšími parametry a delší životností, bude to ten dražší kousek. Mně sobně stačí životnost 3 roky, pak stejně upgraduji, takže pro mne je ten lowend až až :)

Ano, některé SSD jsou horší než jiné (šokující).

Myslím že jen opakujete co už bylo řečeno, a děláte z toho nějaká drama, ale ona to jsou všechno jen zřejmá fakta, ktará už tu byla úplně stejně u procesorů, monitorů, tiskáren, klasických disků, no a teď jsou u SSD disků...

[kyytaM]

Aha, takze ked si kupim lacnejsi procosor, tak mi po 2 rokoch prestane fungovat, lebo je navrhnuty len na nejaky pocet "tickov". Alebo ked si kupim HDD hovno WD Green disk, tak po zapisani XXX dat prestane fungovat... Preto si treba kupovat drahsie (co je drahsie, je lepsie!) :)))

[Ash]

Ano, asi jsi ještě mladý že ti žádný klasický disk neumřel. Levný výrobek používá levné technologie a má tedy většinou i kratší životnost, to je asi většině lidí zřejmé, však to platí skoro u všeho. Tedy další poučení pro tebe. Výrobky s lepší technologií a často i životností jsou logicky dražší, to je dáno jak technologií samotnou, tak trhem. Pokud horší technologie není k dispozici, tak se ta lepší nějak degraduje (zkriplí), aby byl uspokojen i lowendový segment trhu. Tak to prostě funguje, s tím nic nenaděláme ani ty ani já.

[Ash]

Napadá mne jako dobrý příklad úsporná žárovka. Pokud koupíte kvalitní úsporku a požíváte ji v souladu s návodem (má omezený počet rozsvícení a zhasnutí), tak vám vydrží podle poředpokladu. Pokud koupíte "nějakou žárovku" a dáte si ji na chodbu, kde pořád rozsvicíte a zhasínáte, tak vám odejde dřív, jsou to vyhozené peníze, a můžete hlásat jaká to je špatná volba, že do petrolejky co jste tam měl předtím stačilo dolévat petrolej a vydržela vám roky, což z ní logicky činí lepší volbu pro svícení...

[kyytaM]

Ano, analogia usporna ziarovka a SSD je OK, ale CPU urcite nie. :) Ale stale to nic nemeni na fakte, ze usporna ziarovka nie je vzdy lepsie riesenie ako klasicka ziarovka/halogenka/vybojka/LED/ziarivka a na tom, ze usporne ziarovky su velmi kontroverzna technologia, ktora ma mnoho neduhov (tazke kovy, otrasna zivotnost pri vysokej teplote, pomale rozziarenie, maly pocet start cyklov, farba svetla) a tom bolo toto vlakno (teda aspon myslim, uz je to asi aj tak jedno). :D

[Vlk]

Co jsem pochopil z různých článků a diskuzí na netu, tak hlavní omezení flash pamětí jako takových je technologické omezení floating-gate MOSFET tranzistorů, ze kterých se tyto paměti vyrábí. Jde o to, že po určitém množství "zápisu" dochází k opotřebení vrstvy oxidu, která izoluje floating gate, která drží náboj (tzn. zapsanou informaci).

Zápisů by mělo být 10^4 až 10^6 (záleží jestli jde o MLC nebo SLC), záleží na kvalitě s jakou jsou tranzistory vyrobeny. Z toho plyne, že v principu není SSD disk špatný, jen je omezen technologií na které staví a to jsou tranzistory (resp jejich nedokonalost).

Když vezmeme v potaz, že polovodiče se už hezkou řádku let pořád vyrábí z křemíku, který už lehce dosahuje svých limitů, tak by bylo hodně zajímavý vědět, jak moc se budou vlastnosti tranzistorů lišit až(jestli) se přejde na molybdenit nebo grafen. Teoreticky by se měla zvýšit mezní frekvence (stovky GHz až jednotky THz), klesnout spotřeba a možná i zvýšit výdrž.

Podotýkám, že jsem mikroeletroniku studoval jen velmi okrajově pro zajímavost, takže pokud tady mám nějaké nejasnosti, tak budu rád, když mě někdo opraví nebo upřesní, tak budu rád

[Ash]

To, že jsou SSD disky velmi mladá technologie, nevede nutně k závěru, že jsou v současné době nepoužitelné a nemají se kam vyvíjet. To by bylo potřeba nějak doložit, jenže ty si to cucáš z prstu. Pokud jsi výrobce klasických disků tak to chápu, v opačné případě si mohu jen povzdechnout.

[kyytaM]

Dolozil som ti, ze pred 2 rokmi sa masovo predavali SSD, ktore su doslova nepouzitelne. Co este k tomu chces? Prichod vesmirnych ludi? Dnes su v predaji SSD, ktore sa tak diametralne lisia parametrami a vlastnostami medzi sebou, ze stale moze byt kupa "nejakeho SSD" velmi zlou volbou (podla pouzitia). A kde som napisal, ze SSD su nepouzitelne? Stale nerozumiem, co sa vlastne snazis riesit tym, ze tu podsuvas nejake blaboly...alebo si si kupil SSD a tvoje ego neunesie, ze to nieje najdokonalejsia technologia pod slnkom?

[Ash]

K tomu co bylo před dvěma lety nechci nic, koho to zajímá? Kosmodisk se taky dobře prodával, penicilin taky, to málo hovoří o kvalitě výrobku. V současné době jsou v prodeji SSD disky s dobrými parametry. "Nějkaý SSD disk" to je jako koupit "nějaký klasický disk", je vždycky lepší kupovat dobrý a spolehlivý SSD disk, pokud chcete minimalizovat riziko. Však jestli je lepší Seagate (byl, disky šlapaly) nebo WD (nebyl, disky odcházely) se řešilo léta, dneska je to zase jinak. Mému kolegovi odešel SSD hned druhý den (zatrolená mladá technologie :D) dalším šesti kolegům a kamarádům slouží už měsíce k velké spkojenosti, s parametry lepšími než klasický disk. Zajímavé že totéž jsem slyšel o pevném disku, že byl druhý den mrtvý a reklamován, a také o jiných že přežily desítky let.

[pavlix]

Dolozil som ti, ze pred 2 rokmi sa masovo predavali SSD, ktore su doslova nepouzitelne. Co este k tomu chces?

K čemu je prosím taková informace dobrá?

[Ash]

On už to řekl, vyvodil z toho, že "ze pred 3 rokmi cela cast toho noveho segmentu bola totalne nepouzitelna prave hovori o tom, ze SSD je i dnes velmi mladou technologiou, ktora ma svoje nevyriesene (nevyriesitelne?) problemy.". Ale k čemu to je dobré taky nevím :)

[kyytaM]

dalsi co necita - to bola odpoved na otazku jedinca, ktory tvrdil, ze SSD su rychlejsie ako rotacne disky. A btw k comu je tento prispevok dobry "K čemu je prosím taková informace dobrá?"?

[pavlix]

Proč mám pocit, že vůbec nevíš, která bije?

[kyytaM]

OK, tak mi zhrn prosim obsah a informacnu hodnotu tvojich 2 poslednych prispevkov.

[Ash]

Já myslím že by to shrnovat neměl, protože jen řekl že jsi mimoň, a to asi není něco, co by bylo vhodné opakovat, ať už to je jakkoliv pravdivé (nebo nepravdivé). Já bych tedy byl spíš pro to, dohodnout se, jestli jsou SSD disky rychlejší nebo pomajejší než klasické disky. Nemáš čistě náhodou přehled o aktuálním stavu na trhu?

[Michal Kubeček]

Je samozřejmě možné, že v první vlně někdo vzal flashdisk určený pro USB 2.0 a jen vyměnil USB řadič za SATA/PATA, čímž se mu podařilo vyrobit disk, který byl (aspoň co do hrubé propustnosti) pomalejší než rychlé HD. Dokonce je docela dobře možné, že se někdo něco takového snaží prodat i dnes a dokonce je i možné, že mu na to někdo naletí. To ale nic nemění na tom, že když jsem si před rokem pořídil SSD na SATA-300, který patřil spíš k těm levnějším, přenosové rychlosti při čtení i zápisu pohodlně dosahovaly hodnot kolem 250 MB/s, kterých si s jakýmkoli klasickým diskem mohu nechat jen zdát (o přístupové době asi nemá smysl ztrácet řeč). A že stejně - nebo spíš lépe, protože dnes jsou běžné hodnoty dvojnásobné - je na tom drtivá většina dnešní produkce.

[Heron]

+1

Já mám přes dva roky staré SSD (zřejmě tedy z té doby ktore su doslova nepouzitelne), disk má parametry 200/80 MB/s, což společně s minimálními latencemi jej v oblasti 4k bloků činí 40x rychlejším, než klasický pevný disk. Tedy, alespoň z mého pohledu, jsou SSD použitelná a mnohem rychlejší než HDD už minimálně dva roky.

[pavlix]

Podle mě, když kontaktuješ někoho, kdo dobře rozumí filesystémům, tak ti to hravě vyvrátí. Já bohužel na FS machr nejsem, takže se do toho pouštět nebudu. Tím, že rozumí filesystémům, ale nemyslím to, že ví, jak funguje FAT32.

Měl by to být člověk, který má slušný přehled o všech možných na linuxu používaných FS (třeba FAT, EXT2,3,4, XFS, JFS, Btrfs, ale i JFFS2 a ideálně i některé, které já neznám nebo nepoužívám).

Já na tohle bohužel tak úplně nemám.

[frr]

Jste první, kdo zmínil JFFS2. To je totiž přesně takový FS, který umí pracovat s holými flash čipy, včetně dost dobrého wear levelingu. Obecně log-structured FS. Další byl snad UBI FS...

http://en.wikipedia.org/wiki/JFFS2

http://www.linux-mtd.infradead.org/doc/ubifs.html

Pokud to správně chápu, tyhle flashové FS umí "po svém" pracovat s obsazeností, držet si seznam vadných bloků apod. Holé flash čipy takové režijní informace nemají kam uložit (flash čip je jenom surové pole paměťových buněk) - "zapečená SSDčka" si ten seznam vedou taky v nějaké oblasti flashe, kterou si k tomu vyhradí.

Linux umí s "přímo mapovanými" flashkami pracovat dávno, v linuxové terminologii se tomu říká Memory Technology Device - akorát se tenhle způsob práce s flashkami na trhu SSD hardwaru moc neprosadil. Pokud tomu správně rozumím, fungují tak na úrovni hardwaru některá high-endová PCI-e SSDčka (flash sběrnice JEDEC/ONFI apod. je mapovaná přímo na PCI nějakým jednoduchým bridgem), ale v tom případě je translace na 512B sektory provedena closed-source ovladačem. Spousta PCI-e SSDček naopak obsahuje větší počet (s)ATA-flash kontrolérů a k nim větší počet kanálů HBA, případně ještě s dedicated RAIDovým procesorem

Mimochodem větší velikost sektoru pro Linux a jeho FS taky není problém - tohle se dávno vyskytuje na RAIDech, svého času jako metoda jak obejít 2TB bariéru. Fakt je, že je normální v této souvislosti mluvit třeba o 4kB sektorech (což by odpovídalo NAND Flash stránce=řádce, nebo-li minimální transakci typu čtení/zápis na flash čipu), ale těžko třeba o 512 kB - 4 MB (erase blok flashky).

Výše uvedený JFFS2 jsem potkal mnohokrát, ale fakt je, že to bylo tuším vždycky na NOR flashkách - typická velikost v jednotkách MB a používají se na firmware různých ARM/MIPS/MCU (a taky PC BIOS), mají o pár řádů menší kapacitu než SSDčkové NAND flashky. Jestli nějaký linuxový FS umí pracovat konkrétně s NAND flashkami, to netuším...

V linuxu existuje taky softwarová "translační vrstva" pro NAND flashky: umí pracovat s NAND médii, navenek prezentuje blokové zařízení - na kterém můžete mít EXT2/3/4 apod. Jmenuje se NFTL resp. iNFTL. Svého času se používala s flashdisky od M-Systems (řádově jednotky až nízké stovky MB) - než firma M-Systems zkrachovala. Nijak se mi nestýská - hardware co šel zrovna koupit měl vždycky o něco novější revizi firmwaru (vlastně BIOS option ROM), takže to věčně nefugovalo apod. Docela jsem si oddechl, když se rozšířily CompacfFlashky a další ATA Flash formáty, které měly translační vrstvu zapečenou v hardwaru (což je nám dneska přesně trnem v oku).

S MTD je ten problém, že dosavadní implementace nemají jednotné rozhraní vůči OS. Různé embedded krabičky na bázi ARM/MIPS/MCU, pokud loadují Linux nebo nějaký RTOS, mají toto ošetřeno předáváním parametrů z bootloaderu, a/nebo kompilací jádra na míru. Pokud mělo z MTD bootovat PCčko, musela být součástí/doprovodem flashdisku BIOSová option ROMka, která obsahovala implementaci "translační vrstvy" - a pak byly potřeba dedicated ovladače v OS, které translační vrstvu "převzaly" (viz právě M-Systems DiskOnChip). V linuxu se tomu říká "plaftorm-specific device" (nebo prostě "platform device"). V tomto ohledu je rozhraní ATA/SATA/SAS velikým přínosem - právě protože potřebujete ovladač pro HBA a dál se neptáte, jaký disk je na to připojen. Prostě je to další "jednotící mezivrstva". Že je to zrovna v případě flashek "přes koleno", to je smutné - ale zatím myslím nikdo nepřišel se standardizovaným jednotným způsobem, jak připojit flashky "rovnou cestou" na PCI sběrnici, tak aby pro to pak stačil jednotný driver. Napadá mě zařídit pro to PCI device class a jednotné ovládání, něco jako EHCI nebo AHCI, ovšem pro MTD. A pak by se možná musel standardizovat i nějaký jednotný FS, aby z toho šlo bootovat, pokud je takový požadavek... => zrovna tohle je spíš cesta do pekel (programming by committee, lobbing z různých stran apod.)

[lertimir]

Dík za komentář. Hlavní důvod, proč jsem neuváděl JJFS2, ale UBIFS pro práci na SSD je:

The big difference between JFFS2 and UBIFS is that UBIFS stores the index on flash whereas JFFS2 stores the index only in main memory, rebuilding it when the file system is mounted. Potentially that places a limit on the maximum size of a JFFS2 file system, because the mount timeand memory usage grow linearly with the size of the flash. UBIFS was designed specifically toovercome that limitation.

Citace z A Brief Introduction to the Design of UBIFS. Moc si nedokážu představit, jak by v desítkách a stovkách GB současných disků se tohle dělalo. Na několika desitkách MB pro embeded zařízení a případně i systémové disky v mobilech, ano. Tam použití vidím.

A tvrdím a v tom s Vámi zcela souhlasím, že hlavní problém je v chybějící HW standardizaci. Já flash chápu tak, že je to v podstatě pamět, kdysi dávno označovaná jako EEPROM (a BIOS je na ní, a jede z ní) a když se udělá dobře tak na čtení nebude o moc pomalejší než dynamická RAM. Dokázal bych si třeba klidně představit, že by v ní seděla celá část systému, která je read only a byla by přistupná na READ okamžitě na bytové úrovni. už by nebylo třeba nic ze systému loudovat nebo odswapovat, prostě by bylo okamžitě přístupné. Ale to by se museli domluvit na nějakém skutečně pořádném způsobu integrace na sběrnice.

[frr]

Pořádná integrace na sběrnici?

Jasně, mohlo by se to třeba strkat do DIMM slotů SPD EEPROMka by BIOSu řekla, že se jedná o Flash DIMM, jakou má kapacitu atd. Stačilo by vyrábět flashky s RAM-like DDR rozhraním. Trochu problém vidím v tom, že kapacita SSDček je dneska běžně větší, než adresní prostor obsloužitelný řadičem RAM (nebo i větší, než šířka adresní části FSB, nebo jak se tomu u dnešních CPU jader říká).

Jinak sběrnice PCI (a potažmo i PCI-e) standardně nabízí možnost mapovat IOMEM okna = procesor k takto namapovanému adresnímu bloku přistupuje stejnými instrukcemi, jako k RAMce. Zdá se, že teoretické maximum pro základní adresu i velikost okna u dnes běžných 32b BARů je 4 GB, ale našel jsem zmínku i o možnosti definovat 64b BARy.

http://en.wikipedia.org/wiki/PCI_configuration_space

Ostatně "Dual Address Cycle" adresace (64b) byla definována už na PCI 32b. Čili pokud jde o sběrnici PCI, tak by se asi dnešní SSD dalo "namapovat nastojato do adresního prostoru CPU" - v 64b režimu. Čímž se opět dostáváme k reálné šířce adresy ve FSB (nebo jak se to jmenuje u dnešních CPU jader). A taky do toho asi má co mluvit PCI host bridge, který zařizuje mapování mezi adresami sběrnice PCI a adresami hostitelského CPU.

Jasně, sběrnice PCI by byla citelně pomalejší, než přímé rozhraní do paměťového řadiče (zejména u rozdrobených přístupů - PCI má slušnou propustnost zejména v dávkovém režimu).

Prakticky mi nakonec dává smysl nejspíš nějaký co možná nejjednodušší multiplex (stránkování) skrz nějaké menší PCI MMIO okno. Tak funguje tradičně spousta SSDček z kategorie MTD (třeba DiskOnChip takhle fungoval na ISA).

[lertimir]

Jasně, mohlo by se to třeba strkat do DIMM slotů SPD EEPROMka by BIOSu řekla, že se jedná o Flash DIMM, jakou má kapacitu atd. Stačilo by vyrábět flashky s RAM-like DDR rozhraním.

Tak napřímo by to asi nešlo. Protože u takových datových toků jako jsou mezi procesorem a pamětí záleží na detailu. Rychlost paměti velmi záleží na různých wait stavech při časování, a i teď samozřejmě pokud jsou v počítači různě rychlé paměti tak celek jede podle nejpomalejší. A flash paměť by měla jistě jiné parametry, tak by potřebovala svoji sběrnici.

Trochu problém vidím v tom, že kapacita SSDček je dneska běžně větší, než adresní prostor obsloužitelný řadičem RAM (nebo i větší, než šířka adresní části FSB, nebo jak se tomu u dnešních CPU jader říká).

to je jen marketingová záležitost a to, že to trh v současnosti nechce. Jedna z mašinek na nichž pracuji je už 3 roky starý malý server Dell 710 na 2U výšce a i do něj se dá dát 256 GB paměti. Velké servery a superpočítače mají mnoha terabytovou paměť. To že procesory mají omezené řadiče je zcel jistě jen marketing.

Jinak sběrnice PCI (a potažmo i PCI-e) standardně nabízí možnost mapovat IOMEM okna = procesor k takto namapovanému adresnímu bloku přistupuje stejnými instrukcemi, jako k RAMce. Zdá se, že teoretické maximum pro základní adresu i velikost okna u dnes běžných 32b BARů je 4 GB, ale našel jsem zmínku i o možnosti definovat 64b BARy.

Jasně, sběrnice PCI by byla citelně pomalejší, než přímé rozhraní do paměťového řadiče (zejména u rozdrobených přístupů - PCI má slušnou propustnost zejména v dávkovém režimu).

No právě, rychlost je zásadní.

To že tohle není v main streamu mne ani tak nepřekvapuje, ale hodně mě zaráží, že se o tom, jak to udělat dobře a efektivně, nemluví více, že na akademické úrovni nepostavili nějaké systémy, třeba jen jako proof of concept. Ja to aby zjistili jaké takové uspořádání může mít vlastnosti. Jsem přesvědčen, že čipové sady na řadiče paměti jsou a postavit trochu jiný northbridge, který by řídil takovou flash paměť by nemělo být tak složité.

Je jasné, že na něčem podobném pracovat by byla obrovská změna celého konceptu systémů, asi největší od nástupu disků v 70 letech. (třeba by se asi musela změnit celá koncepce alokace paměti. Kromě malloc by bylo něco jako fmalloc, alokovalo by paměť jinde a jinak a zasáhlo by změna, jak jádro tak všechny aplikace.) Právě proto, že jsem kdysi dávno, po vstupu na MFF, ještě pracoval se systémem s magnetickými páskami jako hlavním trvalým úložištěm a ovládal je příkazy

FORWARD
FORWARD n
REWIND

tak se nemohu zbavit pocitu, jako bychom pracovali se SSD disky stejně, jako bychom používali disk jako lineární páskovou jednotku a strašně si libovali, jak moc se ty příkazy FORWARD a REWIND touto novou technologií zrychlily, a jak je to úžasné mít tak rychlou pásku. Přičemž samozřejmě jiná kvalita přístupu dává nové a jiné možnosti organizace dat.

Ale asi tahle diskuse utekla už moc daleko od dotazu.

[frr]

Ještě k tomu přímému připojení na paměťový řadič (do DIMM slotů): pokud jsou technologie RAM a Flash natolik rozdílné, případně vyžadují jiné časování, možná by byla řešením nějaká "sjednocující mezivrstva", která se pružně přizpůsobí obojímu (třeba umí obsloužit každý DIMM s jinými latencemi) - možná by na to stačila technologie FB-DIMM, která vyšla z módy po jedné generaci čipsetů... Údajně umí vyřizovat transakce i *paralelně*, protože je bufferuje...

Taky mě napadlo vyvést pro Flash extra sběrnici z north bridge, nebo pro ni udělat bridge na QPI/HyperTransport... ale zásadní společný problém je počet pinů navíc v pouzdrech čipsetu a/nebo procesoru. To je problém i při rozšiřování adresního prostoru obsloužitelného FSB. Není to tak docela čistě marketingová záležitost.

K tomu 2U DELLu - Xeony 5500 umí obsloužit 144 GB RAM v 9 DIMM slotech na každou CPU patici, při použití 16GB DIMMů... To je divočina...

A máte pravdu, že spousta technologických konvencí jede často "postaru setrvačností" Osobně si nejsem jistý, že by průchodnost a latence Flash pamětí byla bůhvíjaká výhra (ve srovnání s DRAM). Ale fakt je, že koukat na ně skrz SATA kanál tu latenci asi ještě trochu degraduje Nemluvě o nevýhodách "multiplexního přístupu" (Flash není přímo součástí adresního prostoru CPU).

Hehe... přemejšlím, jak by mohla vypadat organizace ukládání executable souborů do Flash paměti, odkud by se daly přímo spouštět. Při aktualizaci softwaru by vznikala fragmentace. Což by se ale dalo ošetřit stránkováním. Třeba kdyby nativní stránkování virtuální paměti CPU mohlo pasovat na stránkování Flash čipů. Což u dnešních procesorů a flashí není zdaleka samozřejmé... Ještě mě napadá, jestli při spouštění executable binárů není potřeba nějaká relokace adres, ale to by se možná dalo ošetřit architekturou OS (přesným schématem mapování user-space adresního prostoru jednotlivým procesům), možná by byla potřeba nějaká spolupráce na úrovni instrukční sady CPU...

[lertimir]

Ještě k tomu přímému připojení na paměťový řadič (do DIMM slotů): pokud jsou technologie RAM a Flash natolik rozdílné, případně vyžadují jiné časování, možná by byla řešením nějaká "sjednocující mezivrstva", která se pružně přizpůsobí obojímu (třeba umí obsloužit každý DIMM s jinými latencemi) - možná by na to stačila technologie FB-DIMM, která vyšla z módy po jedné generaci čipsetů... Údajně umí vyřizovat transakce i *paralelně*, protože je bufferuje...

Moc bych mezivrstvám nevěřil. Na přistupu do paměti se bavíme o rychlostech v řádo 20GB/s tedy 160Gb/s už jen ztráty na tom, že musím instruovat hodiny, aby jinak pracovaly může mít dost časových ztrát.

Taky mě napadlo vyvést pro Flash extra sběrnici z north bridge, nebo pro ni udělat bridge na QPI/HyperTransport... ale zásadní společný problém je počet pinů navíc v pouzdrech čipsetu a/nebo procesoru. To je problém i při rozšiřování adresního prostoru obsloužitelného FSB. Není to tak docela čistě marketingová záležitost.

Ano počet pinu roste, ale jak vidět třeba intelu nedělalo žádný problém přidat piny a vyrábí jeden chip s dvou kanálovým řadičem o 1155 pinech i 4 kanálovým řadičem o 2011 pinech. Takž ano, asi by to prodražilo procesor socket a desku (možná by potřebovala více vrstev), ale myslím že nic zásadního. Mnohem více by se muselo zapracovat na faktické paralelizaci přístupu viz rychlosti rychlost pro malé bloky je pomalá.

K tomu 2U DELLu - Xeony 5500 umí obsloužit 144 GB RAM v 9 DIMM slotech na každou CPU patici, při použití 16GB DIMMů... To je divočina...

Právě, řadič asi není problém, když by byly DIMMy s 128 GB paměti, tak by ho jistě do procesorů vyrobili.

A máte pravdu, že spousta technologických konvencí jede často "postaru setrvačností" Osobně si nejsem jistý, že by průchodnost a latence Flash pamětí byla bůhvíjaká výhra (ve srovnání s DRAM). Ale fakt je, že koukat na ně skrz SATA kanál tu latenci asi ještě trochu degraduje Nemluvě o nevýhodách "multiplexního přístupu" (Flash není přímo součástí adresního prostoru CPU).

Potěšilo mne, že problém s organizací SSD disků zajímá více lidí. Ale zatím moc výsledků není.

Ještě mě napadá, jestli při spouštění executable binárů není potřeba nějaká relokace adres, ale to by se možná dalo ošetřit architekturou OS (přesným schématem mapování user-space adresního prostoru jednotlivým procesům), možná by byla potřeba nějaká spolupráce na úrovni instrukční sady CPU

No relokace asi je vždy, ale to zabezpečuje MMU. Prostě reálná pamět je jedna lineární posloupnost buněk s jednou adresací. A paměť tak, jak ji vidí program nebo virtualizovaný systém je přes MMU a jsou to jiné adresy. Potěšilo mne, že problém s organizací SSD disků

[frr]

Ten link na LWN ohledně vnitřností SSD a NAND Flash už znám - je tam hezky obrázkově vysvětlena dvoupatrová alokace stránek a erase bloků. A řekl bych, že SDHC není zrovna zářným příkladem moderního rychlého SSD (jsou tam nějaké ilustrativní grafy průchodnosti pod různou zátěží) - ale počítám, že jste odkazoval spíš na volnou diskusi pod původním článkem:

1. je tam zmínka o projektu NVMHCI, což je zřejmě nějaký projekt v rámci velikého Intelu, který míří přesně tam, o čem jsme se bavili... = univerzální "host controller interface"
2. taky tam byly zajímavé zmínky, že pracovat se skutečně *holými* NAND Flash čipy není reálný nápad, protože i na úrovni čipů se chová třeba každá generace v rámci jednoho výrobce dost jinak, takže se k nim nelze chovat nějak jednotně, pomocí jednoduchého univerzálního ovladače
3. nakonec tam padl návrh, mít rozhraní "poměrně nízké úrovně, avšak s určitou minimální abstrakcí" - jako třeba "otevři tento segment pro sekvenční zápis", "tenhle segment smaž a přesuň mezi volné", "nahlaš status momentálně otevřených segmentů", "kolikrát byl tento segment smazán?" apod.

Ve výsledku ta debata opravdu nevyznívá zrovna optimisticky - nápady by byly, ale výrobci SSDček se k ničemu takovému nemají

Ohledně relokací adres jsem neměl na mysli mapování stránek pomocí MMU mezi fyzickým adresním prostorem a virtuální pamětí jednotlivých user-space procesů. Spíš jsem se zalekl dynamického linkování (hlavní program vs. sdílené knihovny) apod. - linker/loader musí při startu hlavního programu a natažení knihoven provést nějaké vzájemné "zaháčkování" binárů, které spolu žijí v jediném virtuálním přídělu paměti. Neznám podrobnosti ale napadlo mně, že tohle by se možná přímo v ROMce dělalo těžko.

[necojakolinux]

Pod stromečkem se objevil SSD disk a tak jsem se pustila do přesunu systému na nový SSD disk. Prakticky jsem postupovala podle návodů na internetu. Jen pro ujištění se chci zeptat jestli je třeba ještě něco poladit, abych dosáhla co nejlepší optimalizaci .

Notebook Lenovo B590, místo mechaniky DVD je HDD 500Gb šifrovaný
1. V notebooku mám 8Gb RAM , swap jsem tedy vynechala
2. Rozdělila jsem disk na 3 oddíly /boot , / , /home - vše ext4
3. Distribuce Debian Jessie
4. Nastavila v fstab atributy , noatime a discard u oddílů SSD
5. v fstab nastavila tmpfs do RAM
6. adresář ~/.cache jsem přesunula do /tmp a v .profile nastavila aby se to pořád nemuselo obnovovat

Moje otázka :
Je třeba ještě řešit adresář /var ? Případně ještě nějaké rady ohledně optimalizace?
Děkuji za případné reakce . Alice

[lertimir]

Asi lepsi by bylo zacit nove tema. Obecne na ssd preferuji btrfs, protoze je to jediny fs, ktery o ssd neco vi jinak optimalizuje.