Jaderné noviny – 26. 4. 2012: Umísťování souborů na lepší místa na disku (diskuse)

[aaaaaaaaaaaa]

S tym hot a cold to asi nebude take jednoduche (uz pri navrhu). Keby mal niekto kombinovany disk (SSD+HDD), tak by to malo vyznam. Ale na samotnom rotacnom disku? Ak by neoznacil pomocou O_HOT vsetky subory, tak by podla mna viac trvali seeky (hot je na inom mieste ako cold). Toto moze byt docela problem - napriklad ak vyvojar ladi aplikaciu na hybride alebo ssd. On to pekne vyprofiluje, aby to bolo rychle, ale bezny uzivatel potom bude len pocuvat zvuk seekovania.

[PEPP]

Za predpokladu ze budou soubory oznacene spravne, pak ke COLD souborum bude pristupovano radove mene casto nez k HOT souborum, tudiz seeku mezi HOT a COLD oblastmi bude radove mene, nez v HOT oblasti. Amortizovane pak budou vsechny seeky levnejsi.

Ovsem musi byt slnen predpoklad, ze budou sobory oznacene spravne.

[tomo_tn]

Este by ma pomerne zaujimalo o kolko si clovek moze takto pomoct... Nikdy som nemeral o kolko su rychlejsie sektory na vonkajsej strane disku od vnutornej - na cdrom to bolo poznat pomerne dost, hlavne pri citani suboru co zaberal cele CD bolo vidiet narast, ak si dobre pamatam tak aj 20% (pri osemrychlostnej CDROM).

Popravde si ale neviem predstavit nejaky velky narast pri pouziti SW RAID, ale boh vie.

Podla mna je spravna cesta zmensovanie objemu dat ktory mam z disku nacitat, tak je aspon zarucena uspora.

[Stanislav Brabec]

Kdysi dávno jsem si toho všiml, a změřil si to. Pokud si dobře pamatuji, sekvenční čtení uprostřed disku bylo zhruba 2× pomalejší než na kraji.

U CD/DVD záleží na strategii zápisu nebo čtení (CAV nebo CLV), schopnosti mechaniky dosáhnout vysokých otáček a měnit je, a schopnosti elektroniky měnit rychlost toku dat a výkon laseru, ale z principu jsou rozdíly při CAV více než dvojnásobné.

[j]

Novy mechaniky(uz peknejch par patku) pouzivaj konstatni ("maximalni") otacky a snizujou je jen kdyz je nakej problem. Cteni konstatni rychlosti pouzivaly historicky kousky (tak max do 8x CD). Pro zapis plati prakticky totez.

Rozdil muze byt pomerne markantni u specifickych aplikaci, ale v pripade HDD se uplatni jen v pripade, ze nedochazi k seeku - coz je trebas u DB nedosazitelny stav.

Zajimavejsi je to v kombinaci s SSD, tim ze to "umi" se chlubi trebas EMC, ale na druhou stranu sem narazil na par blogu lidi kteri meli tu cest osobne a moc nadseny z toho nebyli. Jejich popis situace +- odpovidal me zkusenosti z testu hybridu - ani ryba ani rak, misto spojeni vyhod to spojuje nevyhody obou technologii - jednoduse jako user nemuzete nijak rozhodovat o tom, co bude na rychlem ulozisti a musite doufat, ze to ta hromada srotu nejak casem pochopi.

[Mti.]

Pokud vim, tak fatka v dosu pri zakladani souboru lepila soubory jeden za druhym, takze kdyz se pak "druhy" musel zvetsit, dochazelo k fragmentaci. U linuxovych fs se argumentovavalo tim, ze umyslne alokuje soubory ruzne po disku, aby kolem nich bylo dost mista... to uz neplati?

[Zopper]

Ale jo... a ten příznak by řekl "tohle zkus nacpat někam k začátku disku", nebo "tohle dej někam na konec".

[Luboš Doležel (Doli)]

Já bych tuhle funkci čekal před X lety. Ale v době, kdy se na trh tlačí SSD, je to docela pozdě.

[Atom321]

Na trh se také tlačí velkokapacitní "zelené" disky s malými otáčkami. Tam to může být zajímavé.

[Semo]

V clanku su zmienene aj hybridne disky a tam su rozdiely v ulozeni daleko vyraznejsie nez kedy boli na rotacnym magnetickych mediach hocijakeho typu.

[Luboš Doležel (Doli)]

Hybridní disk je mezistupeň mezi klasickým diskem a SSD. Takže opět něco IMO odsouzeného k zániku.

[Sten]

SSD se sice tlačí, ale na server bych to s jejich „spolehlivostí“ rozhodně nedával.

[Mti.]

ale ano, ale taky minimalne v raid1, tak jak klasiku ... ale leda kdybych na to mel.

[j]

Mno jelikoz pomaly (7k) sata disk do serveru stoji 6k (1TB), 15k 150tka cca 15k (bez dane oboje), tak bych rek, ze uzivatel serveru rozhodne cena SSDcka nepali, protoze ho prijde nasobne levnejs, nez odpovidajici pole na HDD.

Ber v potaz, ze nejvykonejsi HDD ma 180-200 IO/s, pro takovou strednefiremni databazicku pak potrebujes aspon 1500 - 2000 IO/s => plna police 15k disku. Variantne si koupis 2/4 SSDcka a to pole nepotrebujes vubec, protoze to se ti vejde primo do serveru.

[Milan Jurik]

Vy možná ne, ale IBM nebo Oracle ano.

[Milan Jurik]

Tohle není určené pro váš laptop, tam to nemá pořádný význam. Ale takový server, s pár desítkami HDD a pár SSD a přesto celé jeden filesystém bez obezliček typu volume manageru. A nebo právě takový Google a jeho cluster filesystém.

[Max]

Tak právě naopak, u serverů je to snad těžko použitelná fce, ne? Pořádný server má pořádný řadič, nebo externí pole, které se stará o vše, systém neovlivní, kam se data zapíšou.
Zdar Max

[j]

A co myslis, ze bezi v tom poli??? Nj, cece, tucnak jak vysitej. Akorat to samo bezi na ponekud specifickym HW.

[Max]

Tučňák na tom poli možná poběží, ale spíš bych věřil, že jen kvůli managementu, tedy ne kvůli tomu, aby se staral o zápis.
Zdar Max

[Milan Jurik]

O JBODu jste neslyšel? A co myslíte tím "pořádným řadičem"? HW RAID? Jednak to rozhodně neurčuje, že se jedná o "pořádný řadič" a navíc, co vám brání mít dva řadiče, jeden pro HDD a druhý pro SSD. To samé v podobě dvou externích polí, každé s jinými vlastnostmi.

Dnes se takové systémy užívají tak, jak znáte ony "slavné" hybridní disky. SSD slouží jako "dočasné" uložiště na cestě mezi pamětí a HDD. Tohle umožní jiný přístup.

[Max]

Slyšel. Řadič disky spojí a systém opět neovlivní, kam data zapíše, jelikož neví, kde končí jeden disk a kde začíná disk druhý.
HW řadiče začínají někde u 9kkč a podporují BBWC, takže takto vnímám slušný HW řadič.

Jinak jaksi nechápu, kam se dostanu, když budu mít SSD disk a třeba SAS na oddělených řadičích.
Tak jako tak je budu muset mít v nějakém poli, abych docílil nějaké slušné spolehlivosti a jsme zase tam, kde předtím.
Zdar Max

[Semo]

Dal som si hladat co znamena BBWC, pretoze som to nepoznal. Okrem ineho to naslo "Big-Boobed White Chick". Je to spravne?

[Max]

Cítím se být zneuctěn a podveden, jelikož to, co na mně vybaflo, otřáslou mou dětskou psychikou :).
Zdar Max
PS:ne

[aaaaaaaaaaaaaaa]

To je asi Googlovskym custom vyhladavanim, ktory vyhodnocuje vase navstevy. Mne to nic take nenajde :-/.

[David Jaša]

Pokud tam máte účet, dá se to v nastavení vypnout (možná jen "vypnout"...). Určitě v anglické lokalizaci.

[Michal Vyskočil]

Mě google našel nějaký storage od HP - teď, kdo z nás je na tom vlastně hůř

BTW: BBWC

[Milan Jurik]

Sorry, ale to, co popisujete, je obvyklé chování HW RAIDu, a vámi užitá zkratka je jen vtipné označení toho, že řadič má baterku pro cache, kterou užívá pro zpracování rozházení dat po více discích, aby nedošlo k nevratnému poškození struktury dat, když už lže ovladači, že data úspěšně zapsal.

HW RAID je problematická záležitost. Dost tragicky se ladí výkon pro speciální aplikace, management bída a BIOS řadičů je ubohost a bugovatost sama (například LSI nebo Cpq SA). Naopak pro interní řadiče je směr se HW RAIDu zbavit a nechat chytristiku opět na operačním systému/filesystému (ZFS, btrfs, ReFS). Proto i tyto drahé řadiče se více a více užívají v non-RAID módu, k nim se připojují ještě JBODy, a využívá se u nich jen toho, že mají větší průtok dat než levnější bratránci.

A kam se dostanete s tím, že budete mít oddělené SSD a SAS na různých vámi doporučených přechytračených řadičích? Tam, kam chytrý výkonný filesystém potřebuje být - SSD pro rychloobrátková data, případně dočasná cache, SAS pro většinu dat. A nemusí to být jen filesystém, ale třeba i OracleDB s jeho vlastním správou zařízení. A opět, není to nutné, operační systém chce vidět všechny targety a znát jejich vlastnosti.

A nekonečné vzývání externích polí ohledně "výkonu" dnes opravdu nechápu. Ano, mají smysl, ale rozhodně ne kvůli výkonnosti (pokud tedy nejste uzavřen v prostředí Windows Serveru). Není rok 2005, ale 2012, a ta externí pole (obvykle FC) nejsou v HW podobě moc vzdálená tomu, co dnes dáte i do velkých serverů, včetně těch řadičů. Výhodou je spíše centralizace a virtualizace storage, samozřejmě.

A ne, nekecám. Stačí si projít nabídku high-end systémů a to jak serverů, tak nakonec i externí storage, které tyhle kombinace užívají. IBM, Oracle, NetApp, EMC. A právě někdy v podobě hybridů SSD/SAS/FCA.

[Max]

Ano BBWC je jen označení baterie, ale to, že podporuje baterii znamená, že má i nějakou cache, která by bez baterie byla stejně na nic (v dnešní době stejně většinou nejde aktivovat cache, pokud není baterie připojená a nabitá).
Co vím, tak "bios" u řadičů se moc nepoužívá, protože nic neumí, od toho jsou management nástroje od výrobce.

Přetáhnout přes oba typy disků jeden FS a nechat systém, aby rozhodoval, do jaké části umístit jaká data, mi stále nepřijde jako dobrý, ale jako zbytečný nápad. Nemá cenu do něj investovat v době, kdy dochází k přechodu a navíc lze řešit a řeší se jinak (fyzickým oddělením, připojením do jiných adresářů apod.).

Jinak sám uvádíte, proč je zbytečné přenechávat zápis na systému/fs. Budoucnost je virtualizace, kterou se teď všichni ubírají a tam je umístění dat na disku opravdu putna, to nelze nijak uhlídat. Hypervisor nepozná, co nám běží ve VPS.
Jinak jisté výhody může hw řadič přinést i v některých oblastech jako jednoduchost nastavení a jednoduchost přenositelnosti v rámci dvou stejných/podobných řadičů.

Význam ASM u Oracle není jen o fyzickém uložení dat, ale hlavně o tom, že se oracle vyhne různým limitům FS a může si ukládání lépe optimalizovat(v rámci sw, není třeba tunit žádný FS apod.) a hlavně také kvůli možnosti více nodů, kdy více oracle serverů může najednou přistupovat k jedné databázi.

Teoreticky lze s ASM nad fyzickými disky dosáhnout většího výkonu, než v případě využití HW Pole. Otázkou ovšem je, jak velký bude rozdíl a zda tato jediná výhoda se vyrovná x nevýhodám jako např. to, že velké pole nemusí sloužit jednomu systému, ale třeba více, viz např. zmíněná virtualizace (nes se virtualizuje všechno, co jde). Jedno velké pole poskytující virtuální storage pro tři systémy dokáže lépe vychytávat špičky (a to i v případě, kdy s virtualizací jde člověk o -10% s výkonem), než kdyby bylo pole rozděleno na tři díly pro tři systémy.
Taktéž by mě zajímal, jaký bude výkonnostní rozdíl mezi hw polem a ASM vs. fyzické disky a ASM (obzvláště v případě, kdy nebudeme mít 80% volného místa, ale trochu přitvrdíme).
Zdar Max

[Milan Jurik]

Ten BIOS na těch řadičích není kvůli managementu, ale právě pro řízení toku dat, tj. třeba u RAIDu k řešení záležitostí s implementací RAIDu. Tohle se neřeší žádnými ASICy. Trošku o tom něco vím a to jak u LSI, tak i u toho Cpqary...

K tomu, že nemá cenu, aby filesystém měl přehled o tom, kam co cpe, tak když už tu hážete zkratky, zkuste si vyhledat například L2ARC.

A k té virtualizaci storage, co myslíte, že je dnes storage? Snad nevěříte tomu, že je to hromada ASICu nadrátovaná k diskům. To neplatí ani v případě SANu, kde ano, FS má smůlu. Ale i tam lze mít různě rychle dostupné targety - stroj, který má lokálně několik extrémních SSD a zbytek dostupný přes FC. Při nutnosti vysoký průtoků naprosto normální řešení.

V případě NASu se pak naopak filesystém a operační systém NASu chce setsakra vědět, kam co ukládá. Viz třeba Oracle.

Tu poznámku o jednoduchosti nastavení a přenositelnosti díky HW řadiči bych radši vynechal, to považuji za čistý marketing, neodpovídající realitě. Nebo jsem nepochopil, kde tu jednoduchost spatřujete.

A než budete dál pokračovat, prosím, aspoň si nastudujte třeba to, jak vypadají Exadata (když už znáte ASM) a jakou roli v tom hrají SSD.

[Max]

S biosem u řadiče jsem myslel, že narážíte na management rozhraní řadiče. To jsme se asi nepochopili.

Díval jsem se na L2ARC a je to možnost, jak třeba SSD disk využít jako cache pro diskové operace, kdy to dáme jasně systému najevo. Není přes něj tedy natažený celý FS.

Jednoduchost u HW pole spatřuji v tom, že se rychle nastaví, když vytahám disky a dám je do jiného serveru (s kompatibilním řadičem), tak se hned v pohodě složí tak, jak má. Když odejde disk, tak ho vymění úplně každý a není co řešit (žádné nastavování apod.). Jednoduchost tedy spatřuji v běžných úkonech.

Vzhledem k článku není ani jasná definice toho, jak přesně se má navrhnutá fce chovat, je tedy možné, že oba, nebo jen já, špatně danné fce chápu :).
Každopádně díky pokec :)
Zdar Max

[Milan Jurik]

Pro jednoduchost na tom ZFS, O_COLD by ZFS (nebo brtníkfs) mohlo užít tak, že taková data do L2ARC nepůjdou. Naopak O_HOT nebude z L2ARC tolik vytlačován. Právě pro možné různé implementace lze tyhle příznaky užít různě. V podstatě nic vám nebrání užít SSD a SAS v jednom poolu, jen to nemá dnes jasný přínos, pokud filesystém nemá možnost vědět, která data budou často žádána.

Problém s jednoduchostí HW RAID je, že tak za 8 let už kompatibilní řadič klidně neseženete (jaká je třeba budoucnost LSI?). Výměnu disku řešíte v obou případech stejně, v nějakém konfiguračním nástroji vadný disk odhodíte, nový přidáte. Plná automatika, reagující jen na HW událost vložení nového disku do stejné "pozice" není úplně slast.

A složení diskového pole v kvalitním filesystému (ne tradičních volume managerech) je automatika. Právě z takových důvodů software volume managery jsou přežitek, zbytečná mezivrstva, jen pro filesystémy se starým designem.

[pavlix]

Jednoduchost u HW pole spatřuji v tom, že se rychle nastaví, když vytahám disky a dám je do jiného serveru (s kompatibilním řadičem), tak se hned v pohodě složí tak, jak má.

To bych osobně považoval spíše za komplikaci.

[Max]

Když máš jednotný prostředí, tak je ti to šumák a takovou věc hlídat nemusíš.
Zdar Max

[pavlix]

Když máš jednotný prostředí, tak je ti to šumák a takovou věc hlídat nemusíš.

Pokud se nejedná o triviální případ jednotného prostředí :D.