Názory k článku
Optimalizace práce s SSD disky v Linuxu

Moc pěkný článek, docela jste mě nahlodal. Stačila by mi i docela malá kapacita (třeba 64 GB). Jen si nejsem jistý, jak je to těmi přepisy. Četl jsem jinde, že se to s každou další generací spíš snižuje, než zvyšuje.

Jo, s menší technologií (25 nm) bohužel kromě zvyšování kapacit i klesá životnost, o čemž výrobci raději mlčí(mlží). Něco se zlepšuje s lepšími algoritmy pro wear levelling, něco se zlepšuje tím, že se v disku dá více místa (např. 64 GB disk se prodá jako 40 GB a 24 GB je volné místo jako náhrada za bloky co přestaly fungovat - zvnějšku se to tváří normálně jako 40 GB SSD) ale pro použití kdyb se hodně zapisuje na disk to není ...

Těch "až 5 milionů zápisů" je nesmysl, realita je jinde.
Např. Intel uvádí živnotnost SSD 5 let při přepisu 20 GB denně. U 40GB disku to znamená během 5 let asi 1000 přepsání. Tedy nic moc...

Tady nejaka cisla s dlouhodobejsiho provozu, nicmene jeste s 34nm

http://marc.info/?l=dragonfly-commits&m=130203562024119&w=2

neco malo i zde

http://leaf.dragonflybsd.org/mailarchive/users/2011-04/msg00010.html
http://leaf.dragonflybsd.org/mailarchive/users/2010-05/msg00142.html
http://leaf.dragonflybsd.org/mailarchive/users/2010-12/msg00009.html

ale nejvice toho clovek najde zde

http://leaf.dragonflybsd.org/cgi/web-man?command=swapcache§ion=ANY

vcetne detailu o technologii a jejich problemech, zminky o tech novych 25nm atd. Ne vse sice vyuzitelne na Linuxu, ale asi porad nejlepe sepsane pro praxi

urcite odporucam. ja mam disk dovezeny z usa od septembra 2009. jedna sa o ocz vertex 64GB. bezim na ubuntu, aktualnu instalaciu mam uz asi rok. samotny boot po login trva asi 7 sekund, co je asi polovica toho, co trva POST. po prihlaseni mam hned plochu a procak ako aj disk nic nerobi. mam stary NB toshiba m100-222 - nemam dovod menit.

ked obcas musim nieco spravit na pocitacoch surodencov, co maju windowsy - 2 x XP a 1 x vista, je to hrozne. ja neviem, ako na tom dokazu pracovat. brat po zapnuti NB caka 2 min, kym mu nabehne browser sledujuc LEDku disku. zmoze sa akurat na zafrflanie, ze mu treba preinstalovat system. skutocne obdivujem ich trpezlivost, menej uz obdivujem ich efektivitu prace.

nie som nejako slepo zaujaty, keby to neslo podstatne rychlejsie, tak to zahodim.

Podobná zkušenost z Windows. Boot se zkrátil asi na polovinu, a reakce GUI jsou okamžité. Ještě se vyplatí mít víc RAM - 8GB je dnes skoro zadarmo, více je lépe.

Výhody SSD (i spousty paměti) uznávám, ale překvapuje mě jak často si lidi pochvalují boot time s SSD. Se sleep módem mám po probuzení okamžitě všechno tak jak jsem to zanechal...

Bohužel sleep mode celkem žere baterie notebooku. Rozhodně stroj nevydrží třeba týden spát (resp. ve Windows se nakonec hibernuje). Na desktopu to není problém, ale tam zase chybí důvod sleep mode vůbec používat.

Stroj sice nevydrží týden spát odpojený od napájení, ale kdy taková situace nastane? A když už nastane, tak kvůli takovému jednomu odhibernování (i Linux v takovém případě zahibernuje) se fakt SSD nevyplatí. (Na druhou stranu o dost nižší spotřeba SSD by se už vyplatit mohla.)

Když nahlédneš do specifikací SSD WD SilikonEdge Blue, najdeš tam mj. i následující informaci o životnosti:

64 GB model ... 17,5 GB/den
128 GB model ... 35 GB/den
256 GB model ... 70 GB den

Myslím, že můžeme s klidným svědomím předpokládat, že
1. se tyto hodnoty vztahují k tříleté záruce,
2. ponechali si ještě nějakou rezervu.

http://www.wdc.com/en/products/products.aspx?id=90

Nevěřím, že bys tohle překročil na běžném systémovém disku.

Pro datové úložiště obvykle tak velký výkon nepotřebuješ a oceníš spíš lepší cenu za 1 GB u konvenčních disků.

Ideálem se tedy v současnosti zdá být malý SSD pro systém: IMHO 16 GB bohatě stačí, 32 GB je fajn rezerva, 64 GB už je skoro zbytečných (ale třeba máš vyšší nároky, u mě kompletní systém zabírá asi 4 GB). A k tomu konvenční disk pro /home, případně RAID pro /srv.

Parametrem noatime nic nezkazíš, stejně tak přesměrováním /tmp do ramdisku - to se běžně používá i na konvenčních discích. Samozřejmě ti v případě paranoie nic nebrání přesměrovat do ramdisku i /var/tmp, /var/run, /var/lock, případně i /var/log, nebo dle vlastní libosti další. Ale v běžném nasazení to vzhledem k výše uvedeným objemům zápisu bude zbytečné.

no a neni lepsi ten disk opotrebovat este pred zarukou?
3 roky proste nejsou zivotnost disku se kterou bych se chtel spokojit...

Protože zápisy zdržují.

zdá se, že to skutečně pomohlo. Škoda, že tento návod nebyl před 2 roky, kdy jsem kupoval SSD.

Mám k článku tri pripomienky.

1. /tmp;
Ak nemáme v počítači RAM pamäť na rozdávanie, tak namiesto tmpfs sa može použiť zram. Je to komprimovany(lzo) ramdisk. Rýchlostný efekt bude rádovo taký istý až na ten rozdiel, že si uštríme miesto v RAM. Tak isto je možné tento zram použiť aj na swap. Zram je v novších jadrách, v starších pod starým nazvom compcache (tu sa dá použiť len ako swap, aj inak sa konfiguruje).
Nejaké info o nastavení je tu: https://compcache.googlecode.com/hg/README
Výsledky z používania(com­pcache) tu: http://code.google.com/p/compcache/wiki/Performance

2. Firefox;
Pokiaľ sa používa /tmp tak po reboote sa údaje vymažú :-(

3. Filesystem;
Ak chceme znížiť počet zápisov na disk a zrýchliť aj jeho výkon a trošku ho "nafúknuť", môžeme použiť súborový systém btrfs s voľbou compress=[lzo gzip]. Filesystem použije transparentnú a inteligentnú komprimáciu, nekomprimuje súbory, pri ktorých by bol výsledok zanedbatelný. Lzo komprimácia je možná len od jadra 2.6.37 a nie je kompatibilná so staršími jadrami(starším btrfs).
Benchmark: http://www.phoronix.com/scan.php?page=article&item=btrfs_lzo_2638&num=1

Ešte sa opravím pri bode 3.
- jadro treba pre lzo treba min 2.6.38
- mount voľby su compress=[lzo zlib]

A ešte doplním, že btrfs ma aj voľbu pripojenia: -ssd
ssd - Turn on some of the SSD optimized behaviour within btrfs.

Tady je řeč o komprimovaném swapu, tedy paměti, která šetří místo, ale je příliš náročná pro přímý přístup.

ad bod 2 - Pokiaľ sa používa /tmp tak po reboote sa údaje vymažú :-(
1. jak casto rebootujes?
2. nektere systemy tmp stejne pri bootu mazou

EEPROM se nemusi mazat cela - u teto technologie jde bez smazani prepsat libovolny byte.

Ano, až následná technologie Flash maže po blocích.

Jen poznamka: pokud mate SSD i normalni disky, elevator by bylo lepsi nechat zapnuty, ano?

Elevator sa zapína/vypína pre každý pripojený súborový systém osobitne.

Z clanku to nebylo moc jasny, kdyz to autor zapinal pres kernel option :)

echo deadline > /sys/block/sdc/qu­eue/scheduler

Elevator by se měl pro SATA2 a SAS disky (a možná i další) sám vypnout, pokud ty disky podporují NCQ (SSD disky se tam IMO hlásí). Takže nastavovat ho je potřeba jenom pro SSD do PATA či SATA1.

Na flash/ssd discich je nejhorsi, ze z duvodu rovnomerneho opotrebeni (wear leveling) delaji uvnitr sebe jeste jedno preadresovani bloku. Tohle preadresovani by mohlo umoznit dost efektivni fungovani filesystemu, pokud by jadro melo pristup k informacim, jak na konkretnim disku funguje. Bohuzel to ale z disku nijak nejde vycist.

Nektere flash disky delaji to, ze jeden blok (viditelny z OS) muze byt treba na 12 ruznych fyzickych mistech, ktera se jen cykli. Takze kdyz jsem treba na takovou flash zkousel dat soubor do ktereho se intenzivne zapisovalo, odeslo mi po kratke dobe 12 stejne velkych skupin bloku :-(

Jine flash disky treba maji optimalizaci typu "predpokladejme ze na disku je standardni rozdeleni a filesystem FAT, chovejme se tedy jinak k blokum kde ma byt FAT tabulka(*) a jinak ke zbytku".

Docela dobry popis wear-leveling algoritmu (i s animacemi jak to funguje) byl nedavno na LWN: http://lwn.net/Articles/428584/.

-Yenya

(*) Vim ze "FAT tabulka" je neco jako "CD disk", ale presto si myslim ze na tom miste je ten pojem srozumitelnejsi nez proste "FAT", coz muze byt i oznaceni celeho filesystemu.

Ikdyz tohle je pravda, tak dnes pouze pro ruzne SD karty. Firmware SSD je schopen se s tim vyrovnat mnohem, mnohem! lepe.

Mohli bychom sice sektory jednoduše zvětšit na 512 KB, ale tím bychom neuvěřitelně plýtvali místem, protože každý soubor by pak měl nejméně 512 KB a jeho velikost by se vždy pohybovala v násobcích této hodnoty.

Myslim, ze na linuxovych filesystemech jdou delat bloky do velikosti stranky, takze 4KB.
Pr. pro ext4 :
-b block-size Specify the size of blocks in bytes. Valid block-size values are 1024, 2048 and 4096 bytes per block.

clanok ok az na sekciu "Méně zápisů a vyšší výkon". Tam su uplne bludy a redaktor si dovolil citovat z clanku, ktory je mimo realitu a vypocty uvadzane na tejto stranke su zcestne. Redaktor si tieto informacie bud nijako neoveril alebo si tendencne vybral taky clanok, z ktoreho vychadza, ze SSD disky nemaju problem so zivotnostou. Pritom je to u SSD diskov asi najvecsi problem.

Ktory SSD disk vydrzi 5 milionov zapisov a k tomu aj MLC disk? Dnesne MLC SSD disky (34nm a 25nm) vydrzia zhruba 3000-5000 zapisov. Pri tomto pocte zapisov a urcitom zatazeni disku, disk nevydrzi ani do konca zaruky.

Pri zapisoch ako sa uvadzaju v clanku by MLC disky odisli v priebehu par tyzdnov podla toho kolko nahradneho miesta bude mat disk pre premapovanie vadnych blokov a ako ma dany vyrobca vyladene funkcie ako wear leveling a podobne funkcie na predlzenie zivotnosti.

80MB/s to je zhruba 7TB/den. Pri kapacite disku 64GB by to znamenalo zhruba 70000 prepisov celeho disku ak by sme chceli na disk zapisovat takouto rychlostou. Dnesny MLC SSD disk by to neprezil ani den. SLC disk by par dni vydrzal. To ratam idelany stav, kde dochadza ku kontinualnemu prepisu celeho disku. Velmi zalezi aj ake su to data, ci je ich mozne komprimovat pred zapisom.

Problematika SSD diskov nieje jednoducha tema.
SSD je vyborna vec ale este uplne nedospela a caka ju pechod na iny typ pameti.

Tomu cislu nerozumim - at ohybam kalkulacku jak to jen jde, porad s k necemu podobnemu nemuzu dopocitat. Muzete to prosim nejak rozepsat?

to jlx :

pardon tiez neviem ako som k tomu dosiel, asi ma zmagorilo zaokruhlovanie na sedmicky pre lepsie pocitanie.
Spravne je to zhruba 100 prepisov denne. Tak ten disk by to vydrzal zhruba 2 mesiace, co je stale podstatny rozdiel oproti 51 rokom, co vyratali na tej stranke.

Tak nejak mne napada, kam si SSD disky ukladaji informace o tom kam premapovali jake sektory pri wear levellingu. Predpokladam, ze taky na flash aby prezily vypnuti systemu. No a v tom pripade to bude nejvice prepisovana cast flash pameti, ktera odejde jako prvni a s ni i cely disk. Nebo napada nekoho finta jak to vyresit?

Ta paměť je velice optimalizovaná pomocí logovacích algoritmů (je to vlastně takový cyklický buffer), takže se jejího zničení bát nemusíte.

To je DOBRÁ otázka! :-) Odpověď neznám, ale taky mi to vrtá hlavou. Zkuste mrknout do tohoto datasheetu:
http://www.sst.com/dotAsset/40312
a hledejte třeba "flash file system". Zjistíte, že přesně to sladké tajemství tam nenapsali :-D

Docela rovnoměrný wear leveling s distribuovanými metadaty mají Linuxové filesystémy určené pro holé Flash čipy, jako třeba JFFS2 nebo LogFS.
http://en.wikipedia.org/wiki/JFFS2
http://en.wikipedia.org/wiki/LogFS
Vespod je holá flashka, svrchu se to váže rovnou do vrstvy VFS = nikde z toho nekouká blokové zařízení.
Cenou za rovnoměrnost opotřebení je nižší výkon. Počítám, že něco takhle složitého by asi v SSDčku zapečeno být nemohlo.

Historicky zůstává v Linuxu taky implementace vrstvy NFTL/iNFTL, která je "přivázaná za nohu" k dávným flashdiskům M-Systems DiskOnChip. Vespod byl holý DiskOnChip MTD, svrchu se to tvářilo jako blokové zařízení, na kterém šel vyrobit konvenční "diskový" filesystém (třeba ext2). Podrobnosti neznám - ale je to každopádně lepší, než primitivní wear-leveling takymechanismy zaměřené na FAT FS.

Nízkou rychlost to má jenom při spuštění, než se zrekonstruuje aktuální stav, potom se všechna metadata drží v RAM a na paměť se zapisuje jenom záznam změn. Důkazem je třeba Android, který na mobilech používá právě JFFS2. Domnívám se, že SSD to mají taky tak řešené.

Používám noatime v kombinaci s relatime. Tahle volba updatuje atime jen při modifikaci (zápisové operaci) a minimalizuje problematické chování některých špatně napsaných aplikací, které podle atime zjišťují, zda byl soubor měněn.

ještě k tomu žurnálu: na netbooku mám ext2, tam poškození filestystému při odpojení napájení nehrozí

Opatrně! Není to tak dlouho, co jsem jedné holčině opravoval souborový systém na notebooku. Prostě ho vybila do nuly...

Já žiju v tom, že při 3% se vypne korektně sám. Ale ještě jsem se nedostal tak daleko abych to prakticky vyzkoušel.

Jo, to jsem si myslel taky :-) Ten stoj byla celkem stará šunka, nejspíš to mělo starý akumulátor a shutdown se prostě nestihl.

TRIM a InterLeaving ... to je OXYMORON ... tak bud ty data smaze a pak je to zapis. Nebo tam ty data necha a zapise je jinam a pak se ale nemazou ....

Tedy max si muze disk nekde zapsat, tyhle data uz jsou neplatna, nech je tam ... a pak je nekdy prepise ... v tom pripade by ale nefungovala metoda jak otestovat fce trimu ;-))

Ta metoda nebude fungovat at tak nebo tak. Ne kazdy disk pri trimu data "nuluje", nektere disky vraceji stejna data, jine muzou vracet nejaky garbage, nebo stabilni hodnoty (ale nemusi to byt zrovna nula).

To zda disk data opravdu "nuluje" je mozne zjistit z:
/sys/block/<de­vice>/queue/dis­card_zeroes_da­ta

ale ani tak neni zaruceno ze to opravdu udela. Jednak existuje jeste /sys/block/<de­vice>/queue/dis­card_granulari­ty a jednak SSD disky jsou jeste porad neskutecne kramy, ktere nedelaji to co maji.

A ja asi nemam chut, silu ani cas komentovat vsechny nepravdy a polopravdy v podobnych clancich :)

A taky, pouzivat mount option "discard" mi neprijde jako idealni napad. U vetsini disku co jsem videl je patrny obrovsky ubytek vykonu (viz. http://people.redhat.com/lczerner/discard/ext4_discard.html) zvlaste kdyz to neni uplne nutne (viz. predhozi odkaz) a obzvlastne kdyz jiz mame v jadre FITRIM (ext4,ext3,xfs,btrfs­?) a v util-linux-ng fstrim, ktery je mozne nechat spoustet z cronu ...

Zajimave, to me ani nenapadlo, otestuji na svych discich. Dik

Zajímavé, discard option mám a používám a žádného úbytku výkonu jsem si po několika měsících nevšiml, spíš to bylo ještě malinko lepší.

Tvuj subjektivni pocit je, bez urazky, irelevantni.

Bylo by nějaké vysvětlení? Jinak můžete uživatele s opačnou zkušeností než máte vy rovnou bez urážky střílet...

Sam jste prece psal ze po nekolika mesicich pouzivani jste si ubytku vykonu "nevsiml" a to ja pokladam za subjektivni pocit, ktery je ovsem irelevantni. Pokud mate nejaka cisla tak sem s nimi. Pointa byla v tom, ze to co se vam "zda" nemusi byt tak uplne realita. Urcite jsem to nemyslel jako urazku.

Zdá se, že o věci něco víte :-) Nepatrně mi vrtá hlavou jedna otázka, v souvislosti s "nulováním": točivé disky ve factory clean stavu jsou "popsané samými nulami". Kdežto smazaná flashka je "samé 0xFF", tj. samé binární jedničky. Zápis znamená, že se některé jedničky přepíšou na nulu (zpátky na jedničku už to pak nejde, leda novým smazáním celého erase blocku). Aspoň tahle logika funguje u NOR flashek (BIOS apod.). Nevím jak u NAND (interně je to stejně, ale nevím jak na vnějším rozhraní). Resp. by mě zajímalo, jak se chová ATA disk, jak ukáže smazaný erase block - jestli surové samé jedničky, nebo jestli to letmo invertuje na samé nuly... Na jedné CF kartě, která realokovala nultý erase block, byly vidět samé jedničky.

To je neco co bohuzel nejsem schopen posoudit, nejsem clovek pres hardware :). Kazdopadne standard mluvi jasne, bud po discardu vraci same nuly, nebo pevne definovanou hodnotu, nebo puvodni hodnotu coz ale predstavuje bezpecnostni riziko. Dalsi moznost je vrazeni nejakych garbage hodnot, ale to si nejsem jist zda je standardizovane chovani. To co dela firmware bohuzel nevim a ani vedet nemuzu protoze to vetsinou spada do know-how vyrobcu :)

At tak nebo tak, idealni stav je pokud po trimu vraci same nuly, proto je to taky neco co linux kernel exportuje do user space.

Podle mě si to v této rovině zase tolik neprotiřečí :-)
Když TRIM označí konkrétní erase block jako volný, tak si ho SSDčko může rovnou smazat, nebo cinknout pro pozdější smazání, aby se v konečném důsledku dostal do interního "poolu volných erase blocků", do kterých lze přímo zapisovat bez čekání na smazání - takže následující zápis proběhne svižně (nemusí čekat na mazání, možná nemusí ani přednačítat erase block, pokud je mapování sektorů na erase bloky jemnější). Finta je v tom, udržovat si co největší pool volných předsmazaných erase bloků.

Prakticky, pokud jsem to správně pochopil, je problém v tom *kdy* přesně provést ten výmaz erase bloku, protože mazací operace je každopádně docela časově náročná. SSDčka, která to provádí *hned* v rámci vyřizování příkazu TRIM, typicky zaznamenávají díky příkazu TRIM výrazný úbytek průchodnosti (nad rámec vlivu flushování NCQ fronty). A pokud SSDčko provádí mazání vyTRIMovaných erase bloků "až později když je klid", tak pokud do toho přijde třeba i jenom čtecí transakce na dotyčný kanál (čip?) NAND flash, může to znamenat citelné zdržení - možná je to u čtení dokonce subjektivně znatelnější než u zápisu (write-back cache leccos skryje). To je cena za rychlý zápis nebo "trvale mladé SSDčko".

totalne zly clanok. bol by som rad, keby si autor nabuduce overil o com keca.

SSD disk pozna 2 velkosti blokov:

1. citanie vie adresovat po 4KB ako kazdy iny bezny disk
2. zapis vie adresovat len po 512KB ako bolo spomenute v clanku

Toto prebieha interne, OS o tom nema ani tucha, dokonca aj TRIM funguje len po 512KB blokoch a FS to posiela podla fs blokov (bezne 4KB), takze SSD disk si toto musi prislusne nazbierat a prelozit na internu adresaciu.

Co sa tyka zivotnosti, nove NAND MLC bunky maju zivotnost 3000 zapisov. Sice to je pomerne dost pre bezne pouzivanie, ale trosku intenzivnejsia praca s diskom im drasticky znizujezivotnost. Aj ked pre bezneho pouzivatela to bude stacit na par rokov.

> 1. citanie vie adresovat po 4KB ako kazdy iny bezny disk
> 2. zapis vie adresovat len po 512KB ako bolo spomenute v clanku
>

Na ATA rozhraní, pokud vím, je 512B sektor pro čtení i zápis. Na tom se shodneme. 4 kB sektor v souvislosti s disky se vyskytuje jenom u novějších modelů WD a jedná se o interní formát na plotnách, navenek je pořád 512B.

Pokud si přečtu třeba tohle:
http://www.ccs.neu.edu/home/pjd/papers/hotstorage09.pdf
tak interně to vypadá, že NAND flash vyžaduje čtení či zápis o velikosti "NAND Flash stránky" (vlastně se jedná o řádek), která má podle uvedeného PDF typickou velikost 2 nebo 4 kB. Ovšem *mazat* lze pouze celý erase-block naráz (třeba 512 kB). Osobně bych nepokládal rovnítko mezi zápis a mazání - pokud si disk vede nějaká metadata o alokaci uvnitř erase-blocků, tak by teoreticky nemělo být potřeba mazat při každém zápisu celý dotčený erase block. Teprve když se disk dostane do fáze, kdy nemá jinou možnost než read-modify-erase-write, tak se to rovnítko mezi zápisem a mazáním samo vynoří.

Díky za článek, určitě je tam řada zajímavých nápadů. Jen k té životnosti SSD - mohu se dozvědět zdroj, který uvádí životnost řádově miliomy zápisů? Hledal jsem a nenašel. Dle všechno, co výrobci sporadicky uvádí, vychází na počet zápisů na několik tisíc. Vypadá to, že v článku došlo omylem k přihození tří řádů navíc.

1) erase block size vetsiny SSD disku je 128K, 512K mozna u EFD...
2) mount -o discard,defaults neni moc stastne, fedora potom ignoruje to discard - vetsina FS ale uz dneska SSD zarizeni detekuje a discard zapne sama
3) noatime se uz moc nepouziva, default pro nove filesystemy je relatime a ten se smi pouzivat i s SSD
4) opotrebeni SSD disku bych naprosto zanedbal, zivotnost je vynikajici aniz by clovek data premistoval, navic premistenim do pameti clovek prijde o data pri rebootu (pokud si neporesime synchronizaci v shutdown skriptu...), pokud se da napr. cache firefoxu na disk tak je zase podstatne pomalejsi (kdyz uz mame to SSD... :)

Nejlepsi vec co jsem pri provozovani SSD udelal byl prechod na ext4 a zapnuti laptop mode (resp. zvyseni intervalu pro flush na disk).

Dalsi uzitecny tip - pokud jste provozovali SSD s vypnutym TRIM, tak neni od veci pred instalaci cely disk oTRIMovat rucne. To jsem delal hdparmem pres security erase a trvalo to par minut.

U modernich distribuci by ale normalni uzivatel nemel na nastaveni vubec sahat, s SSD se pocita.

to Jan Schermer:
Vase tvrzeni cituji:"U modernich distribuci by ale normalni uzivatel nemel na nastaveni vubec sahat, s SSD se pocita." by tedy potrebovalo dolozit nejakou oficialni referenci.

Podle vas tedy napr. Ubuntu 10.10 nebo Fedora 14 defaultne podporuji SSD (tj. TRIM, atd.)???

to neni o distribucich ale o verzi kernelu, vfs, fs a default mount options

ext3 i ext4 mely defaultne zapnuty TRIM uz pred rokem, nebudu zkoumat jestli ty patche jsou i ve vsech distribucich, ale u tech desktopovych o tom nepochybuji :)

No teda, trochu plkate...

nejdriv reknete: "U modernich distribuci by ale normalni uzivatel nemel na nastaveni vubec sahat, s SSD se pocita"

pak reknete: "to neni o distribucich ale o verzi kernelu, vfs, fs a default mount options"

a nakonec prohlasite: "ext3 i ext4 mely defaultne zapnuty TRIM uz pred rokem, nebudu zkoumat jestli ty patche jsou i ve vsech distribucich, ale u tech desktopovych o tom nepochybuji :)"

Ale napr. Ubuntu 10.10 nema TRIM defaultne zapnuty, i kdyz ma kernel ktery TRIM podporuje.

Vy jste ten kod asi nikdy nevidel ze ne ? :D

Mate nekdo zkusenost s TRIM u sifrovanych oddilu (dm-crypt, ecryptfs...)? Hodne se o tom napsalo, me by zajimala prakticka zkusenost. Potrebuju sifrovat home folder a bez TRIMu SSD nechci

Nevím, jak je to s podporou, ale TRIM se u šifrovaných médií nedoporučuje, protože to umožňuje odhalit, co jsou data, co metadata a co bordel a pak se daleko lépe dělá kryptoanalýza.

Zdravíčko vespolek,

ten článek mi přijde poněkud nekritický... Příkaz ATA TRIM je z definice (dle standardu) nezařaditelný do NCQ fronty, pročež před každým jeho podáním disku musí bloková vrstva čekat, až se NCQ fronta zcela vyprázdní. Prakticky se tak chová jako tvrdá bariéra. A co hůř, u první generace SSDček (podle toho co našel Google někdy v roce 2009) mohl TRIM trvat *hodně* dlouho - třeba až stovky ms = "SSD si šel dát kafe" (reálně něco mazal a k tomu prováděl jakousi "garbage collection"). Nevím jak u aktuálních modelů SSD a verzí firmwaru.

Svého času jsem někde četl povzdech/shrnutí jakéhosi kernelového vývojáře (už to nedokážu najít) který doslova došel k závěru, že lepší a jednodušší než ATA TRIM je nakonec žádný TRIM nepoužívat, a "pasti read-modify-write" se vyhýbat inteligentnějším slučováním zápisových operací + flagem "přepis na místě". Netuším, jak to nakonec v Linuxu implementovali, jaký je aktuální stav... a jenom doufám, že si ten závěr pamatuju dobře.

Dneska jsem dokázal vygooglit tohle výživné vlákno z LKML (dva různé archivy téhož):
http://lkml.org/lkml/2009/8/16/159
http://thread.gmane.org/gmane.linux.kernel/876737/focus=42383
...a z něj taky volně cituji v prním odstavci.

V článku mi dále chybí zmínka, že není dobré na flashdisk swapovat, točit na něm velký objem logů, mailů apod.

BTW, ten problém s příkazem TRIM ("nejlepší TRIM je žádný TRIM") mi dost připomíná nedávný vývoj okolo implementace bariér v blokové vrstvě - ačkoli se jedná zjevně o nesouvisející problém...
http://lwn.net/Articles/400541/

Ohledně zmíněného zarovnávání oddílů a "block groups" na velikost erase bloku: jak se dá u konkréního SSD tenhle parametr zjistit? Je na to nějaký ATA příkaz / registr? Umí to hdparm nebo třeba smartctl? Nebo je potřeba hledat v dokumentaci od výrobce SSD? Nebo je jediná šance SSD otevřít, zjistit použité Flash čipy, a koukat do *jejich* datasheetů? Jasně, docela rozumný praktický přístup je, nasadit to od oka na nějakou radši vyšší mocninu dvou, a hotovo :-) "ztratit" 512 kB na začátku 40GB SSD, to asi není velký problém...

Ještě mě zaujala jedna věc: v LBA režimu jistě není problém naadresovat ~100 PB, nicméně BIOSová tabulka rozdělení (pro kterou potřebujete hlavy a sektory) funguje jenom do cca 2 TB, a to ještě za předpokladu 255H/63S. Pokud pro BIOS (aby se z disku dalo bootovat) dosadíme 32H*32S, (= cylindr velký 1k sektorů), vychází z toho maximální velikost disku nějakých 64M sektorů = 32 GB? Navíc mám pocit, že BIOS by tu geometrii stejně nevzal (trval by na nějakých *svých* hodnotách CHS/LBA/LARGE). Pak mi přijde rozumnější, pokud SSD beztak nebude bootovatelné, použít ho jako "dangerously dedicated" (nerozdělené). A dál už stačí jenom nalinkovat velikost clusteru nebo "block group" nebo jak se tomu říká ve Vašem filesystému...

Kdyz si clovek precte tento clanek a pak nasledne diskusi k nemu, tak musi zakonite dojit k nazoru, ze bud autor vubec nevi o cem mluvi, nebe se SSD disky chovaji kazdemu uzivateli nejak jinak. protoze se nektere nazoru doslova vylucuji.

Jinymi slovy: Neexistuje jednotny nazor ani na to, jak nastavit resp. optimalizovat a zda vubec SSD disk, alespon na desktopu pro bezne pouziti.

To je teda dost tristni situace... nemate take ten dojem???

Já bych to tak černě neviděl :-) SSDčka jsou obecně výborná pro read-mostly provoz s vysokou náhodností "seek positions". Pokud máte v mixu větší množství zápisů, tak je třeba mít se na pozoru. Taky je co do rychlosti zápisu výrazný rozdíl mezi různými kategoriemi ATA SSD - od levných CF karet (náhodný zápis třeba 10 IOps) přes nějakou střední třídu (solidní noname), po špičkové značkové SSD třeba od Intelu (náhodný zápis 900 IOps) - pro srovnání běžná točivá Barracuda má náhodný zápis nějakých 75-90 IOps.

My se tady už jenom tlučeme čepicema nad nuancemi jak ladit geometrii FS proti SSD (resp. jak přesně formulovat potřebnou trojčlenku), jestli je TRIM k něčemu nebo ne - ale to jsou spíš takové drobnosti na okraj. Základní vlastnosti SSD nikdo nezpochybňuje.

Ahojda, omlouvám se, asi jsem opravdu natvrdlý, ale jak to tedy je v mém případě se zarovnáním?

# fdisk -S 32 -H 32 /dev/sda

Command (m for help): p

Disk /dev/sda: 80.0 GB, 80026361856 bytes
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x5779bbca

Device Boot Start End Blocks Id System
/dev/sda1 63 2008124 1004031 82 Linux swap / Solaris
/dev/sda2 * 2008125 2200904 96390 83 Linux
/dev/sda3 2200905 156296384 77047740 83 Linux

Command (m for help): ^C

Kde jsou v daném případě ty avizované 512KB bloky?

No... řekl jste fdisku na příkazové řádce, jakou geometríí má na disk pohlížet. Ale tabulka rozdělení zůstala v původním stavu, protože jste ji zatím nezměnil/nesma­zal/nevytvořil znovu - a to že první oddíl začíná na sektoru s LBA adresou 63 znamená, že tabulka rozdělení počítá s klasickými 63 sektory na stopu (nultá stopa zůstala prázdná s výjimkou MBR, první oddíl je zarovnaný na začátek stopy č.1). Pan Krčmář měl na mysli, že ten fdisk poštvete na "factory clean" SSD (má v MBR samé nuly, tj. tabulku rozdělení prázdnou) a oddíly teprve následně fdiskem vytvoříte. Pokud přijmeme zarovnání na 512 kB = 1k sektorů = 1 cylindr, tak první oddíl by měl začínat na sektoru č.1024.

áha, děkuji vám velmi za objasnění.

Já se přidám:-)

<b>RE: Ujistěte se ještě, že první oddíl začíná na sektoru dělitelném číslem 512.</b>
Který sektor, nebo spíš které číslo sektoru není dělitelné 512 :-) ?

Źádný SSD disk sice nemám, (tohle je jeden z posledních IDE disků), ale stejně by mě zajímalo, jak to je.


fdisk -lu /dev/hda

Disk /dev/hda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xfa3ffa3f

Device Boot Start End Blocks Id System
/dev/hda1 * 63 208844 104391 fd Linux raid autodetect
/dev/hda2 208845 2184839 987997+ 82 Linux swap / Solaris
/dev/hda3 2184840 60789959 29302560 fd Linux raid autodetect
/dev/hda4 60789960 976768064 457989052+ fd Linux raid autodetect

Dost mě udivuje, že tu ještě nikdo nezmínil GPT fdisk aneb gdisk. S ním jsem si rozparceloval SSD úplně v pohodě, sám se stará o zarovnání a používá moderní GUID Partition Table.

Jinak SSD mám 64 GB, což je u mě systém + /home, prostě vše kromě objemných multimediálních dat a tak se mi to zdá optimální. Mám zapnuto discard a noatime (není důvod to nepoužívat i pro HDD). Systémové logy, IRC logy i cache prohlížeče jsem nechal na SSD, pro nenáročný desktop je to podle mě vyhovující řešení. HDD tímto zůstává úplně potichu pokud z něj zrovna netahám nějaké to video. Po několika měsících jsem nezpozoroval snížení rychlosti čtení či zápisu na disk, ale občas se mi zdá, jako by přístupová doby trochu "lagovala", třeba otevření jednoho malého souboru není okamžité. Ještě to budu muset trochu prozkoumat, myslím si, že dřív to nedělalo.

fajn že jste zmínil konkrétní referenci na GPT :-) Kolik BIOSů z toho dneska umí nabootovat? Chce to EFI resp. UEFI... A pokud z toho BIOS neumí bootovat, tak to bude jako druhý disk, a tedy často nemá cenu to trhat do několika oddílů...

který že to soudruh má vlastně pravdu.
A v rádiu Jerevan ani slovo.

Marx aby to spral :D

Tohle píšu z hlavy, tak doufám, že to dám správně:
Originál, na který reaguji:

> Jeden cylindr tak bude mít 1024 bajtů, a protože fdisk rozděluje
> disky v násobcích 512 cylindrů, budou nám vycházet ideálně velké
> bloky. Poté si vytvořte oddíly tak, jak jste zvyklí.
>
> Ujistěte se ještě, že první oddíl začíná na sektoru dělitelném číslem 512.

Moje verze:

"Jeden cylindr tak bude mít 1024 sektorů (á 512B = 512 kB), a protože linuxový fdisk zarovnává oddíly by default na celé cylindry (= v násobcích 512 kB), budou nám vycházet ideálně velké oddíly zarovnané na cylindr = erase block. (Windowsový fdisk zarovná první oddíl na stopu.)

Ujistěte se ještě, že každý oddíl začíná na sektoru dělitelném číslem 1024."

Výše uvedené počty předpokládají historickou standardní velikost ATA sektoru = 512B, která podle mého dodnes naprosto převažuje.

Nové točivé disky WD mají/nemají sektor o velikosti 4 kB. Interně 4 kB, ale navenek to překládají na 512B, což je prča zejména ve chvíli, kdy na tom vytvoříte BIOS partition table s geometrií 255H/63S, což pak není soudělné se 4kB=8S...

Sektory o "nativní" velikosti 4 kB jsem si zatím vyzkoušel jenom na RAIDech (PCI/SCSI/SAS/FC) - a vespod byly stejně vždycky disky s 512B sektorem. A používal jsem to spíš pro Windowsy, protože různým součástkám v Linuxu 4kB sektor moc pod fousy nešel.

Jinak 4 kB je klasická velikost paměťové stránky v Linuxu - proto taky 4 kB je tuším nejmenší reálná velikost block-layer transakce. Vlastně by to šlo s 4kB sektory na blokovém zařízení hezky dohromady. Ale ATA disky to podle mého zatím reálně neumí - disky WD umí maximálně sdělit operačnímu systému, který o tu informaci případně stojí, že je vhodné zarovnávat na 4 kB - ale velikost sektoru na rozhraní ATA zůstává 512B.

Konečně všeříkající článek !! V podstatě sem měl půl té konfigurace již vygooglenou. Osobně používám již přes rok Kingston SSD V+ 128 Gb a k plné spokojenosti. Podle "palimpsest" mám pořád stejně rychlé čtení jako když jsem ho kupoval. Myslím si, že dnes je již trh s disky jinde než před rokem a vůbec bych neváhal ! Nárust výkonu je enormní !

... za velmi povedený článek. Mě osobně na SSD disky nahlodala už přednáška na minulém LinuxAltu. Žel bohu zatím mě odrazuje poměrně vyšší pořizovací cena (SSD SATA 128GB Kingston přes 4000 kč, HD SATA 500 GB 1100 - 1200 kč) :-( Takže ještě chvíli počkám, věřím, že než se se cena trochu sníží, určitě bude počet maximálních zápisových cyklů mnohem větší... :)

Koncem minuleho roku jsem se zabyval spolu s kolegy SSD disky, nase vysledky a laborovani jsou sepsany zde: http://support.zcu.cz/index.php/Public:Svamberg/SSD
Vse bez zaruky, ale par zajimavosti zvlaste v odkazech stoji za precteni.

Je možné nějak naklonovat stávající root oddíl na nově koupený SSD, aniž bych to musel přeinstalovávat?

1. připojím SSD
2. zarovnám podle článku
   # fdisk -S 32 -H 32 /dev/sda
# mke2fs -t ext4 -E stripe-width=128 /dev/sda1
   Nebo nevím, jestli by to pro mě udělalo grafické udělátko z Mandrivy 2010.2?
3. "nějak" naklonuju stávající root na SSD - prosím poraďte jak?
   (naklonoval by se i MBR?)
4. změním záznam v fstab (resp. překlikám to v diskdrake)
5. rebootnu a mám to - systém nabíhá z SSD, starý root na točivém disku můžu použít na něco jiného

Možná jsem blbej. Ono by asi stačilo to normálně nakopírovat a potom v grafice určit přípojný bod (/) a že se z toho má bootovat. MBR se zapíše sám. Nejsložitější operace teda asi bude to záhadné zarovnávání.

Nevím, co je "normálně" nakopírovat, nejlepší bude cp -a. Jinak asi není problém.

dd if=/dev/sda of=/dev/sdb
kde /dev/sda je stary HDD
a /dev/sdb je novy SSD

Pak mne napada v podstate jen problem, ze posledni diskovy oddil muze mit nejak sejdrem konec, to by se ale myslim melo dat zpravit jednoduse resizem daneho oddilu pomoci napr. gparted

dekuji za vycerpavajici shrnuti :-)

RAID z HDD sice má slušné kontinuální čtení a zápis, ale nijak nepomáhá náhodnému čtení a zápisu. Přitom při interaktivní práci se systémem oceníte nejvíc právě to náhodné čtení. Kliknete na ikonu, a začnou se nahrávat spousty souborů (executable, knihovny, nastavení). HDD je v tu chvíli velmi pomalý, SSD naopak báječně rychlé. Další výhody SSD: mechamická odolnost (oceníte u notebooku), nízká spotřeba, nízká hmotnost. A problém s počtem zápisů? Pokud se takového problému vůbec dočkáte, tak prostě váš disk jednoho dne začne mít bad blocks. Jenže to uvidíte včas, a vždy se to bude týkat jen bloku, který právě zapisujete. Co už je úspěšně zapsané, to pak i přečtete. Naopak když odchází HDD, máte problémy se čtením kdysi úspěšně zapsaných dat.

USB flash disky mi zatím bez problému vydržely roky, a těch přepsání byla dlouhá řada. Jako FS používám FAT32 a NTFS.

Anebo nezačne mít bad blocks, ale disk se vůbec nespustí. U HDD jsem to viděl jednou (shořela elektronika), u SSD vícekrát (důvod neznámý).

Ale no tak. SSD má sice své dětské nemoci, ale takový popis je maximálně tendenční, více k tomu snad ani není co. To RAID pole je sice super, ale na jeho schopnosti v sekvenčním čtení v praxi s*re pes. Pokud nekopíruju denně gigabajty filmů tam a zpět, je mi nějaký RAID z výkonnostního hlediska úplně na nic. Nejčastější operací je náhodné čtení malých bloků dat a to je to, co dnes brzdí jakýkoli počítač s HDD a ať má RAID jaký chce, nepomůže mu to nijak. Zde je SSD za všech okolností mnohonásobně rychlejší, ale to se jaksi taktně úplně zapomnělo zmínit, že? ... A přemýšlet kolikkrát zkompiluju jádro opravdu netřeba, ale dnes má holt každý tendenci SSD v různých článcích furt rozfrcávat a mnohdy s hromadou převzatých bludů odjinud a tak se vesele pletou pojmy s průjmy a vnikají různé za vlasy přitažené dojmy a obavy. Možná by obecně všem neškodilo méně nad tím laborovat a více to normálně používat.

No a ty flashky, to snad ne. 5 přepisů, no to určitě, proč ne hned dva třeba, to by bylo do té demagogie lepší číslo, ne? Mě ještě neodešla ani ta poslední reklamní (jiné jsem snad ani neměl). Karty do mobilu a MP3 to samé. Mám hromady SD karet do foťáku X krát přepisovaných a fungují jako nové (a ještě dlouho budou).

# mke2fs -t ext4 -E stripe-width=128 /dev/sda1

marně jsem se snažil vyčíst podobné nastaveni pro mkfs.btrfs

# mkfs.btrfs -l 512k /dev/sda1 ???

-l, --leafsize size
Specify the leaf size, the least data item in which btrfs stores data. The default value is the page size.

leaf size nastavuje velikost alokačního bloku a nastavením na větší hodnotu, než na stránku, byste místem neskutečně plýtval. btrfs používá hodně odlišné alokační strategie a IMO nepotřebuje nastavovat zarovnávání jako ext4.

Jsem prekvapen, ze tu nikdo nezminil wiper.sh z projektu hdparm:
http://sourceforge.net/projects/hdparm/files/
Jedna se o shellovy skript, ktery z filesystemu zjisti aktualne nealokovane bloky a ty pak vsechny najednou vyTRIMuje. Tento "manualni" pristup sice neni tak elegantni, jako discard, ale zase nema zadne negativni vedlejsi ucinky (zpomaleni). Funguje i na namontovanem fs, ale pro klid duse je nejjednodussi jednou za mesic nabootovat treba do Live CD z flashky, na kterou se prihodi wiper.sh a promaznout vsechny fs na SSD.

Dobrý den,
v článku jsem se dočetl, že disk (teoreticky) vydrží 50 let neustálého zápisu. Avšak v jedné z diskuzí pod produktem na czc.cz jsem se dočetl, že někde zkoušeli dát SSD disk do zatíženého databázového serveru a disk vydržel jen 14 dní. Momentálně řeším problém s databází, kam mi každou vteřinu přichází cca 100 relativně malých záznamů, které se nijak dál nemodifikují, pouze se ukládají a následně podle potřeby čtou. Čtení však za mohutného chroupání stávajícího HDD trvá desítky vteřin. Jaký je Váš názor? Zachrání mě SSD disk jednak rychlostí přístupu k datům a jednak svou výdrží, aby neodešel po 2 měsících provozu? Díky.

mne s povodnym mkfs z clanku nechcel bootovat kernel (3.0.6)
tu som nasiel volbu "stride":
http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux

-E stride=128,stripe-width=128

zopakoval som cely postup a kernel nabootoval...

SSD mám skoro dva roky a už bych si na normální disk nejspíš nezvyk; trvalo mi to víc jak rok než jsem se ke koupi odhodlal -- pořád jsem se přesvědčoval v tom, že to nemá smysl, když ten notebookovej hdd je docela rychlej --, po instalaci jsem se musel trochu za to svoje konzervativní smýšlení stydět. Rychlost naběhnutí rázem spadla z jedné minuty na třicet vteřin, ale i výdrž notebooku se dostala ze čtyř a půl hodiny na dobu šesti hodin -- na stejnou dobu, jako když byl novej. Prostě jsem si chrochtal a jsem spokojen dodnes.
Jen to kryptování. Byl jsem zvyklý mít oddíl kryptovaný. Sice jsem si po koupi SSD říkal, že zas tak moc se nestane, když nebude, ale to jsem asi neměl, protože co čert nechtěl, po třech tejdnech jsem nes disk na reklamaci -- přesněji na výměnu samozřejmě i s daty jako emaily a některými hesly.
Nevíte někdo jestli už neexistuje nějaké rozumné řešení?

SSD disk mam neco pres dva roky, bezi luxusne, ze stareho pocitace udela novej :) ale ma 60 GB a na dalsi virtual uz tam neni moc mista, tak kdyby nekdo chtel, Corsair NOVA, zaruka jeste skoro 3 roky, napiste na jura kysela ryba spital tecka cz

Myslím, že by zde mělo zaznít i jak je to s podporou TRIMu v jednotlivých systémech souborů. Ext4 to umí od jádra 2.6.33 mám dojem, btrfs to taky umí, ale co ostatní? ext3, ext2, vfat, ntfs-3g, ........
Na internetu člověk najde i deset let staré informace, je pak problém dohledat ty aktuální (vím, neumím moc hledat).
Napište kdo to ví, prosím.

Ako je to s nastaveniami ak mi bezi virtualna masina s diskom v subore na ssd? Teda na celom ssd disku je jeden velky subor. Je vhodne pouzit tieto iste parametre aj vo virtualnej masine alebo len v OS, v ktorom ta virtualna masina bezi?

prosim pridat LABEL SSD
Dakujem