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

14. 5. 2012 | Luboš Doležel

Články - Jaderné noviny – 26. 4. 2012: Umísťování souborů na lepší místa na disku  

Aktuální verze jádra: 3.4-rc4. Citáty týdne: Rob Landley, Mat Mackall, Tejun Heo. Google spustil zrcadlo git.kernel.org. Rozhovor s Linusem Torvaldsem. O_HOT a O_COLD.

Obsah

• Aktuální verze jádra: 3.4-rc4
• Citáty týdne: Rob Landley, Mat Mackall, Tejun Heo
• Google spustil zrcadlo git.kernel.org
• Rozhovor s Linusem Torvaldsem
• O_HOT a O_COLD

Aktuální verze jádra: 3.4-rc4

Aktuální verze jádra je 3.4-rc4 vydaná 21. dubna. Linus k tomu řekl: Ale nic z toho nevypadá až tak děsivě. Zdá se, že vydání verze 3.4 se blíží podle plánu, ale křičte, když narazíte na nějaké regrese. Vyskytla se hlášení problémů s grafickým ovladačem Nouveau, ale tyto potíže snad budou brzo vyřešeny.

Stabilní aktualizace: verze 3.0.29, 3.2.16 a 3.3.3 vyšly 22. dubna. S verzí 3.2.16 končí řada 3.2, ale Ben Hutchings dal vědět, že bude tuto řadu namísto Grega Kroah-Hartmana ještě nějakou dobu udržovat.

Aktualizace 3.0.30 a 3.3.4 se aktuálně revidují a jejich vydání lze očekávat 26. dubna nebo později.

Citáty týdne: Rob Landley, Mat Mackall, Tejun Heo

Snad PRVNÍ věci, kterou máte přidat po „hello world“, je parser stromu zařízení, protože tak se dozvíte, kolik máte paměti a kde se nachází.

-- Rob Landley

Proto si myslím, že se teď už firmám dobře daří vyrobit krabičku, na které poběží Linux, s dostatkem RAM, flash pamětí, CPU, základními periferiemi jako oscilátor, USB, I2C/SPI v balení o velikosti 8 mm2 za 5 dolarů. Pravda je taková, že potřebné úsilí na straně vlastníka licence ARM je znatelně menší než kdybyste se snažili srazit spotřebu paměti Linuxu na polovinu. Z toho důvodu jsou dny projektů jako Linux-tiny za námi.

-- Matt Mackall

U některých patchů mě děsí, že to pak vůbec nabootuje.

-- Tejun Heo

Google spustil zrcadlo git.kernel.org

Google oznámil spuštění (readonly) zrcadla git.kernel.org na kernel.googlesource.com. kernel.googlesource.com je poskytováno z několika datových center Googlu v Asii, USA a Evropě, aby byl poskytován rychlý přístup pokud možno odkudkoliv na světě.

Rozhovor s Linusem Torvaldsem

Na TechCrunch vyšel rozhovor s Linusem Torvaldsem. Byli by někteří jaderní vývojáři raději, kdyby je někdo místo nadávek večer uložil do postele? Jsem si jist, že by to docenili. Ale sám se na to necítím.

O_HOT a O_COLD

Ačkoliv jsou úložiště dat považována za zařízení s „náhodným přístupem“, pravdou je, že operace na některých částech zařízení mohou být rychlejší než na jiných. Úložiště s rotujícím médiem mají větší rychlostní rozdíly než flash, u hybridních zařízení to pak může být ještě větší. Vzhledem k existenci rozdílů je přirozené chtít, aby častěji požadovaná data byla na rychlejších místech. Nedávný návrh, aby aplikace měly možnost umístění dat ovlivnit, se setkal s různými reakcemi; problém je zjevně složitější, než by se mohlo zdát.

Nápadem, jehož autorem je Ted Ts'o, je dát aplikacím možnost používat nové příznaky při vytváření souborů. Soubor, u kterého se očekává častý přístup, by byl vytvářen s příznakem O_HOT, a soubor málo používaný by byl zase označen pomocí O_COLD. Očekává se, že soubory s O_HOT, by byly souborovým systémem umístěny na nejrychlejší část zařízení.

Implementace znamená změny v operaci create(); byl přidán nový parametr, který umožní vrstvě VFS předat dále příznaky od aplikace. Tato změna je nejintruzivnější částí patche, protože vyžaduje opravy ve většině souborových systémů – jde celkem o 43 změněných souborů. Jediným souborovým systémem, který tyto příznaky implementuje už od počátku, je ext4. V jeho implementaci jsou soubory s příznakem O_HOT umisťovány do bloků s menším číslem a u souborů označených pomocí O_COLD je to zase naopak – ale jen pokud je souborový systém uložen na disku s rotujícím médiem. Pro použití O_HOT je potřeba právo CAP_RESOURCE.

Spoustě lidí se nápad obecně líbí, ale byly to právě podrobnosti implementace, které vyvolávaly spousty otázek. Co se stane, když je úložné zařízení na poli rotujících zařízení? Proč předpokládat, že soubor je buď celý „hot“, nebo „cold“; některé části mohou být takové a jiné zase makové. Pokud aplikace používá oba typy souborů, způsobí přesouvání mezi těmito typy souborů obecný propad výkonu? Co když se typ souboru bude časem měnit? Měl by tento koncept být napojen na to, jak s daty zachází subsystém správy paměti? A co má „hot“ a „cold“ vůbec znamenat?

Ohledně poslední otázky Ted odpověděl, že i když by bylo možné dát dohromady definici „hot“ a „cold“ v tomto kontextu, není to zrovna něco, co by chtěl udělat:

Druhou možností je nechávat věci nedefinované a přijmout fakt, že aplikace, které to budou využívat, budou asi natolik specializované, aby si byly vědomy toho, jaký systém používají, a aplikacím tedy dávat jen obecné náznaky, což je přístup, který jsem zvolil v návrhu O_HOT/O_COLD.

Jinými slovy je návrh stvořen např. pro potřeby společnosti s velkým internetovým vyhledávačem, která se snaží vytěžit maximum ze svého masivního pole výpočetních clusterů. To je zajisté rozumné použití, ale zaměření na právě takové použití může znesnadnit zobecnění této funkčnosti.

Zobecnění funkčnosti navíc nemusí zrovna pomáhat určování práv k označování souborů na úrovni konkrétních souborových systémů. Tento návrh by mohl vést ke stanovování odlišných pravidel u různých souborových systémů; což Ted očekává. Pravidla na úrovni FS umožní experimentovat, ale přesune to funkci do oblasti, kde bude užitečná jen pro specifické aplikace, kde mají vývojáři naprostou kontrolu nad používaným systémem. Pak by se O_HOT jen tak v aplikacích neobjevovalo, protože vývojáři by nemohli vědět, co by tento příznak mohl přivodit. A to je možná správně, protože jinak bychom se nemohli divit, kdyby nakonec většina souborů byla označena jako „hot“.

Zajímavostí je, že existuje ještě jeden jiný přístup, který zde nebyl diskutován. V roce 2010 byla do mailing listu btrfs zaslána sada patchů ošetřující „teplotu dat“. Tento kód sledoval přístupy k souborům a za běhu rozhodoval, o které bloky je největší zájem. Účelem bylo, aby pak btrfs mohlo migrovat „žhavá“ data na rychlejší místa úložiště, čímž by byl zlepšen celkový výkon. Práce na těchto patchích asi ustala; už nějakou dobu se nové verze neobjevily. Obecně ale dává smysl, že pozorování přístupů bude přesnější spíš než představy různých vývojářů.

Abychom si to shrnuli, tak to vypadá, že ačkoliv koncept odlišného zacházení s často čtenými daty má smysl, ještě nějaký čas potrvá, než se přijde na to, jak o takové zacházení požádat nebo jak jej implementovat. Další věcí je, že jakýkoliv explicitní příznak (jako O_HOT) se rychle stane součástí jaderného ABI, takže bude obtížné jej změnit, jakmile jej lidé začnou používat. Proto asi stojí za to chvíli uvažovat o tom, jak funkčnost navrhnout tak, aby byla dlouhodobě užitečná, i když to bude znamenat, že všelijaké žhavé soubory budou ještě nějakou dobu muset trávit čas na horších místech.

Diskuse k tomuto článku

[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.