ZFS na FreeBSD [WAS: FreeBSD fibre channel multipath a zfs]

[Petr Rehor]

2009/8/5 Miroslav Lachman <000.fbsd at 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.