2009/8/5 Miroslav Lachman <000.f...@quip.cz>: > Dušátko Jan wrote: > [...] >> >> Rad bych varoval s ne zrovna dobrou zkusenosti. Testovali jsme SSD >> pod databazovymi servery. Po dvou tydnech vetsina SSD mela rychlosti >> cteni/zapisu okolo 20MB/s, po mesici na 5MB/s. Vyjimkou byly Intely, >> ktere se docela drzely. Pricemz normalni rychlosti SSD se pohybuji >> okolo 40-60MB/S. Z tohoto duvodu SSD nedoporucuji na intenzivni >> operace nad filesystemem. Pravda, bylo to jenom MySQL, ale zda se, >> ze to stacilo. A pri 96 1TB discich bude limitem ethernet, nikoliv >> rychlost disku, leda by cilem byla co mozna nejnizsi spotreba. >> Pri tomto mnozstvi disku by melo byt bez problemu "utavit" podle >> rychlosti disku tak 4 gigabitove karty.
Přemýšlím o použití SSD disku v domácím serveru a pokusil jsem si nastudovat trochu teorie, protože tyto informace mě mírně znejistěly. > To je docela zajimava informace, jeste nikde jsem necetl o tom, ze by se SSD > s postupem casu zpomalovaly. Kazdopadne i tak se zatim od tech SSD drzim > dal. Hledal jsem čím to může být a našel jsem informaci, která by to mohla vysvětlit: http://pctuning.tyden.cz/hardware/disky-cd-dvd-br/15788-vykon-ssd-disku-proti-klasickym-hdd-v-realnem-provozu?start=3 V kostce to funguje tak, že SSD disk musí zapisovat velké bloky (dnes i jednotky MB). Pokud má do bloku zapsat méně dat, musí řadič blok nejprve celý načíst do keše, do nakešovaného bloku zapsat nová data a celý blok zapsat zpátky na disk (Read-Erase-Write). To je "naivní" implementace, kterou zdá se používají levné MLC SSD disky a která vede k trvale mizernému výkonu pokud se mají na disk zapisovat malé objemy dat do náhodných sektorů (viz odkaz na konci na článek na Anandtech). SanDisk SSD disky se snaží problém řešit tak, že mají navíc jakýsi žurnál (párset MB flash paměti), do které zapisují po blocích data které mají být zapsány na disk a následně ve volných chvílích data z tohoto žurnálu zapisují na správné místo ve svých blocích. To funguje skvěle pokud rychlost zápisů na disk nepřevýší schopnost disku zapisovat data na své místo. Pokud se podaří žurnál zaplnit, zápisy přejdou do standardního REW a rychlost zápisu na disk jde dolů. Jakmile se data podaří zapsat žurnál do cílových bloků, tak se zápisový výkon obnoví. Intel X25-M používá jinou fintu - všechny zápisy, které jsou menší než blok, seskupí dohromady a zapíše do prázdného bloku a zapíše si do tabulky remapování sektorů, v kterém bloku je sektor skutečně uložen (a u bloku s původním umístěním sektoru poznačí, že je v něm volná díra). To funguje skvěle dokud jsou k dispozici volné bloky na disku. Když dojdou, je nucen využívat díry v blocích a zvyšuje se režie zápisu, protože se musí načítat bloky z disku a při jednom zápiu na disk se nezapíše tolik dat najdenou. Dlaší optimalizace ve firmwaru zajišťují defragmentaci, zdá se, že se to děje zejména při zápisu velkého kontinuálního objemu dat. Žádná offline framentace na pozadí v disku neběží. Další nepříznivý vliv na výkon zápisu má i zaplnění disku daty, kdy zbývá málo bloků do kterých je možné zapisované sektory remapovat - možná by mohlo pomoct obětovat část kapacity disku ve prospěch výkonu při zápisu. TRIM příkaz může uvedenému mechanizmu pomoct tím, že filesystém říká disku, které sektory už neobsahují platná data po smazání souborů, a disk je může přidat jako díry do bloků, případně celé bloky označit jako nepoužité, čímž se zvýší dlouhodobá efektivita zápisů na disk. Další články, které se váží k výkonu SSD disků: http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3403 http://selfdocumentingcode.blogspot.com/2009/03/beating-performance-bogeys-in-intel.html http://www.pcper.com/article.php?aid=669&type=expert&pid=1 P. -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
