Administrace komentářů

Ono hlavně pokud se čte nebo zapisuje trochu sekvenčně (několik strajpů za sebou) tak "jeden pomalejší disk" znamená úzké hrdlo = ostatní disky třeba už dokončily transakci, ale čeká se na toho jednoho opozdilce. Pokud toho má kontrolér ve frontě víc, možná dokáže trochu optimalizovat... (jako že další drobné transakce na toho opozdilce třeba čekat nemusí) - ale tady zase záleží, kolik máte disků a nakolik jsou v poli reálně nezávislé = dáno "architekturou konfigurace" pole, taky by mohl mít vliv alignment fs/strajpy, zápisové bariéry v toku dat, interní pravidla RAIDu pro zajištění integrity zapisovaných dat apod. A samozřejmě záleží, jaký máte mix R/W zátěže, velikost transakcí apod.

Už se tu někdo ptal, jestli ta Vaše věc umí Trim. Věřím tomu, že Trim umí OS, zde patrně vůči RAIDu. Umí ho taky Váš RAID vůči SSD diskům? Rozumím správně, že máte mezi OS a SSD hardwarový RAID? Pokud ano, možná by s TRIMem pomohlo, připojit disky jednotlivě přímo k nějakému serveru (JBOD, expandéry, HBA) a rozjet třeba ZFS přímo nad jednotlivými SSD - ovšem pozor na možná úzká hrdla a zádrhele v oblasti SAS expandéry vs. SATA disky apod. Taky si pamatuju diskusi někde v LKML, že než TRIM první generace (blokuje a flushne frontu), to už je lepší jenom trochu optimalizovat zápis / přístupy k disku...

Připojit disky přímo do ZFS má další důležitou koncepční výhodu: ZFS končí nahoře na vrstvě abstrakce zvané VFS ("jmény souborů") a díky znalosti této relativně vysoké úrovně umí optimalizovat práci s diskovým prostorem (alokace/frontování/caching/trim) až na úroveň jednotlivých disků. Pokud mezi ZFS a disky vložíte RAID, vkládáte tam "černou skříňku", o které nevíte jistě co dělá - resp. co o ní víte (základní mechanismy RAIDu) tak i to málo nebudí zrovna optimismus.

Osobně se v oblasti enterprise storage nepohybuju, ovšem z embedded nasazení ve mně přetrvává obecný pocit, že flashky jsou svině A to v zásadě bez rozdílu. Teď nemluvím jenom o low-endu jako CF, SD, MTD apod. - nejlepší co mi prošlo rukama jsou klasická SATA SSDčka od Intelu a nějaká embedded SLC SSDčka podobné cenové kategorie. Při RW použití se vrací do servisu i ty vyšší modely. A ne, SSDčko Vám na sebe opravdu nevykecá "je mi blbě" skrz SMART. To musíte vypozorovat z reálného chování (což se Vám právě povedlo). Wishful thinking je špatný přístup - správný postup je, naložit tomu sadistickou zátěž se známým charakterem (rozdrobené náhodné zápisy) a koukat, co to reálně udělá.

Vygenerovat v Linuxu dostatečně rozdrobenou paralelní/overlapping zátěž ve směru "čtení z disku", tj. aby se požadavky frontovaly, to znamená použít buď velký počet blokujících vláken, nebo použít asynchronní IO (relativní novinka). Tohle zatím neumím. Relativně jednodušší je napsat generátor rozdrobené zátěže ve směru "zápis na disk". Stačí jediné vlákno, které prostě jede ve smyčce "zapiš a zapomeň". Něco takového mám (pozor bug: havaruje v okně širším než 200 znaků Udávit nové SSDčko drobnými zápisy není vůbec žádná frajeřina, a podle mého to trvá spíš pár minut, než desítky dní.

Doporučuju benchmarkovat především jednotlivé disky, teprve poté případně taky skrz RAID. Pokud se týče testování disků, RAID = mlha. Vedle principielně neinteligentního strajpování apod. některé enterprise RAIDy údajně naschvál škrtí provoz per initiator (per client) apod.

Je fakt, že SSDčka mívají nějaké procento bloků na NAND čipech rezervováno na opravy a obecně "jednodušší dýchání" (aby dvoupatrový algoritmus alokace sektorů na zápisové strány a erase bloky nemusel tolik rozplétat špagety) - a že "lepší" SSDčka mají tohoto rezervovaného místa víc (20%) než low-end flashky (snad jednotky procent). Nicméně pokud si představíte, že máte uživatelský sektor a transakci řekněme 4 kB, zápisová stránka na NAND čipech je podobně velká, a erase blok je třeba 1 MB, tak je jasné, že při dostatečně malé průměrné velikosti transakce Vás rezerva nějakých 20% místa nemůže spasit. V této souvislosti mě napadá snad jen použít na SSDčkách "short stroking" tzn. nechat si tam nějaké volné místo po svém. Ovšem pokud byste chtěl, aby SSDčko "nikdy nevadlo", patrně byste musel na tom SSDčku obsadit tak 1/20 objemu (= 95% kapacity nazmar) a navíc byste musel mít kliku, že to wear leveling algoritmus správně pochopí a náležitě využije.