Jaderné noviny – 27. 3. 2014: Velké disky a 32bitové systémy

14. 4. 2014 | Luboš Doležel

Články - Jaderné noviny – 27. 3. 2014: Velké disky a 32bitové systémy  

Aktuální verze jádra: 3.14-rc8. Různé problémy s cachí stránek: Velké disky na 32bitových systémech; Velké stránky v cache stránek; Větší bloky na systémech souborů.

Obsah

• Aktuální verze jádra: 3.14-rc8
• Různé problémy s cachí stránek
  • Velké disky na 32bitových systémech
  • Velké stránky v cache stránek
  • Větší bloky na systémech souborů

Aktuální verze jádra: 3.14-rc8

Aktuální vývojová verze jádra je 3.14-rc8 vydaná 24. března. Linus k ní řekl: Oproti mému běžnému plánu mám den zpoždění, doufal jsem, že to nakonec bude vypadat na verzi 3.14, ale nevyšlo to. Proto tu máme rc8 a vidím to na konečné 3.14 přiští víkend.

Stabilní aktualizace: verze 3.13.7, 3.10.34 a 3.4.84 vyšly 23. března; verze 3.12.15 vyšla 26. března.

Různé problémy s cachí stránek

Cache stránek je na Linuxu pověřena správou cachí bloků dat z persistentních úložných zařízení; jde o zásadní součást jak virtuálního systému souborů, tak subsystémů správy paměti. Cache stránek je klíčem k výkonu systému jako celku. Bohužel už v řadě směrů začíná vykazovat své stáří. První technická debata na Linuxovém sumitu pro úložiště, systémy souborů a správu paměti 2014 se zaměřila na řadu problémů s cachí stránek a ukázala přibližnou cestu k jejich řešení.

Velké disky na 32bitových systémech

Jedním z hrozících problémů, který představil James Bottomley, je, že na 32bitových systémech nemůže cache stránek pracovat s disky většími než 16 TB. Cache stránek používá nativní velikost stránky (4 KB) k adresaci bloků na zařízení; s 32bitovými indexy bloků končí schopnost adresace na 16 TB. James kladl tyto otázky: je třeba tento problém na 32 bitech řešit a pokud ano, tak jak to udělat?

Řada vývojářů to jednoznačně vnímala tak, že tento problém není nutné řešit. Vnímají 32bitové systémy jako systémy, co jsou už na odchodu; kdokoliv, kdo chce používat velká úložná zařízení, by si měl pořídit 64bitový systém. Ve skutečném světě to ale nemusí být tak snadné. 32bitová zařízení tu s námi ještě nějakou dobu budou, hlavně v říši embedded zařízení. Lidé si pořídí 16TB USB disky a budou očekávat, že poběží. Jiní umístí 32bitový procesor do laciného NAS a budou tam chtít dát velké disky. Navíc tu máme výrobce, kteří dávají 32bitové procesory přímo do disků, aby tak doplnili protokoly jako iSCSI.

Dave Chinner poukázal na to, že jádro problému se skrývá v samotné cache stránek. Pokud dělá aplikace přímé I/O (čímž je obcházena cache stránek), pak žádné problémy nejsou. Pokazí se to až jakmile se uživatelský prostor pokusí o bufferované I/O na velkém disku. K tomu dojde při používání systémů souborů, ale i před tím: udev například používá bufferované I/O při mapování disků. A je tu ještě jeden drobný problém: i kdyby bylo možné 16TB systém souborů připojit a používat na 32bitovém systému, tak stále nebude dostatek adresního prostoru pro běh kontroly systému souborů. Tento problém se zdá na těchto systémech být neřešitelným. Jinými slovy, i když opravíme jádro, tak zbytek ekosystému bude zkrátka rozbitý.

Tyto informace více méně vedly ke shodě. Nikdo se nebude snažit o podporu větších systémů souborů na 32bitových systémech. Ale přímé I/O bude na velkých discích fungovat a bude nadále podporováno. Takže situace, které závisí jen na přímém I/O – například v případě iSCSI – budou na 32bitových systémech fungovat. V ostatních případech bude nutné si pořídit 64bitové CPU.

Velké stránky v cache stránek

Dave spolus s Christophem Lameterem pak přešli na další téma: ukládání větších bloků dat v cache stránek. Ukázalo se, že o to usilují z odlišných důvodů, což je vede k odlišným řešením. Může být možné vyřešit oba problémy, ale jedno z řešení bude pravděpodobně hotové dříve než to druhé.

Christoph má obavy z režie operačního systému na všech úrovních; součástí jeho řešení je podpora větších fyzických disků v cache stránek. Větší fyzické stránky by snížily režii správy v jádře a objem práce spojený se sestavováním a úklidem [setup and teardown] při I/O operacích nad těmito stránkami. K velikostem v cachi stránek je možné přiřazovat atribut „řazení“, což umožní uložení odlišně velkých stránek, ale skrývá se tu obvyklý problém: udržení schopnosti doopravdy alokovat větší fyzické stránky poté, co systém už nějakou dobu běží.

Podle Christopha je řešením udržovat si rezervu v podobě velkých stránek jen pro tento účel, ale to je „divné“ a obtížné správně vyladit. Jiným řešením je pak umožnit jádru přesouvat stránky, defragmentovat tedy za běhu. Většina nutné podpory už existuje; subsystém správy paměti má schopnost migrovat stránky a tato schopnost se používá v kódu pro kompakci stránek z účelem defragmentace paměti. Problém je v tom, že ne všechny stránky se dají přesouvat; jde o velkou překážku, jelikož na rozbití jedné velké fyzické stránky stačí jediná nepřesunutelná stránka.

Existuje řada důvodů, proč nemusí být možné přesunout konkrétní stránku, ale jedním z nejzávažnějších příčin je alokace objektů v jádře. Kdyby objekty získané ze slab alokátoru byly přesunutelné, tak by problém zmizel. Christoph má patche, které tuto funkčnost přidají do některých intenzivně používaných cachí (kupříkladu do inode cache), ale ještě nebyly začleněny. Proti tomuto nápadu se objevil odpor; jádro je plné ukazatelů na objekty; žádný objekt nelze přesunout, leda by bylo možné všechny tyto ukazatele změnit bez zanesení race condition. Christoph trval na tom, že většinu obtíží lze zažehnat změnmi v několika důležitých datových strukturách.

I tak to ale nemusí vše zafungovat tak, jak by se Christophovi líbilo. Mel Groman řekl, že i na současných systémech, kde probíhá snaha o oddělení přesunutelných a nepřesunutelných stránek, se ukazuje, že překvapivě hodně „přesunutelné“ paměti zkrátka neexistuje. Stránky tabulky stránek mohou představovat velkou část paměti a nejde je přesunout; patch, který to napravoval, přidával 5-6% režii, a proto nebyl začleněn. Jiné stránky jsou údajně přesunutelné, ale jsou zablokovány pro přímé I/O nebo jinak drženy na místě v paměti; i kdyby tomu bylo věnováno velké úsilí, tak by mohla být migrace stránek obtížná. Prozatím je pro většinu uživatelů hlavním symptomem to, že alokace transparentních velkých stránek selže; to není velký problém. Pokud bychom ale podle Mela došli do fáze, že opravdu závisíme na schopnosti přesouvat stránky, „tak se nám to šeredně vymstí“.

Větší bloky na systémech souborů

Dave se zeptal na odlišnou, ale příbuznou otázku. Zajímala ho lepší podpora systémů souborů s bloky většími než je velikost stránky v systému. Podpora větších fyzicky souvislých stránek v cache stránek by v tomto ohledu mohla pomoci a tento přístup nabízí jisté výhody, hlavně díky tomu, že pro jeho podporu nejsou v kódu systémů souborů nutné téměř žádné změny. To samé se ale nedá říct o subsystému pro správu paměti, kde by to s rozsahem změn bylo závažnější. Než abychom na to hned skočili, bychom podle něj měli zvážit, zda musíme problém opravdu řešit takto.

Jedním z popudů pro větší fyzické stránky byla omezení v zásobníku blokového I/O; maximální velikost jediného I/O požadavku byla po dlouhou dobu příliš nízká na to, abychom z vysokorychlostních úložišť získali maximální výkon. Zvýšení velikosti stránek by tento limit posunulo dále, což by umožnilo přenést více dat se stejným počtem stránek a problém by byl vyřešen. Ale omezení velikosti požadavků už bylo vyřešeno, takže není takový tlak na řešení problému s velikostí stránek. Skutečným problémem je tedy podle něj to, že cache stránek ví o velikosti bloků používaném na každém systému souborů. Končí to tak, že sleduje hodně údajů z úrovně systému souborů, čímž se duplikují údaje uložené na systémech souborů. Tato duplikace vede k problémům s koherencí a občasným ošklivým chybám; je to také zdroj toho omezení, že bloky systému souborů nemohou být větší než systémová velikost stránky.

Nick Piggin se pokusil tento problém vyřešit už před lety svou prací na fsblock. Problém s tímto patchem je ten, že vyžaduje rozsáhlé změny ve všech systémech souborů. I ext2, který byl Nickem upraven na ukázku, potřeboval změn opravdu hodně. Proto Dave hledal jiné řešení. Ve zkratce by byl rád, kdyby cache stránek přestala udržovat mapování mezi stránkami a bloky systému souborů. Vše ostatní je už v systému souborů známo; odstranění tohoto sledování z cache stránek by mohlo umožnit odstranit omezení velikosti bloků.

Tato práce by rovněž umožnila eliminovat používání hlaviček bufferů [buffer heads] pro sledování bloků. Vývojářům systémů souborů se s nimi těžko pracuje; navíc jen s malým užitkem přidávají hodně režie. Mapování stránek na bloky se mnohem lépe řeší na základě informací pro sledování extentů, které už v kódu systému souborů jsou. Cache stránek by se musela starat jen o to, jestli je daná stránka aktuální s ohledem na zapsaný permanentní stav; vše ostatní se může snáze a spolehlivěji řešit jinde.

Christoph se ozval s tím, že chce, aby cache stránek vyšší úrovně snížila režii aplikací, hlavně okolo I/O požadavků; řešení na úrovni systémů souborů popisované Davem podle něj tento problém neřeší. Martin Peterson poukázal na to, že menší granularita I/O může být stejně vynucena hostitelskými adaptéry, ale Christoph řekl, že používá high-end hardware a tímto tedy netrpí. Dave za souhlasu ostatních prohlásil, že tu popisujeme dva odlišné problémy a že ve každém případě je nejprve potřeba vyřešit velké bloky systémů souborů.

Vyskytly se také obavy z interakce mezi formátem binárek ELF, který má v sobě jisté předpoklady o zarovnání, a velkými bloky systému souborů. Vypadá to ale, že v této oblasti žádné problémy nejsou, hlavně jakmile se člověk zbaví 32bitových systémů.

Na konci debaty se zdálo, že panuje shoda, že by Dave měl dále dělat na přesunu povědomí o systému souborů pryč z cache stránek. Podle něj jde o překvapivě malou změnu, ale stále o opravdu hodně práce. Změny budou volitelné; nikdo neočekává, že celá ta spousta starých systémů souborů na Linuxu bude aktualizována, a současně je nutné, aby dál fungovaly. Vyskytly se obavy o to, kolik práce by se dotklo obecného kódu pro systémy souborů; nikdo nechce vidět duplicitní implementace nakopírované do jednotlivých systémů souborů.

Mezitím byl Christoph přizván k tomu, aby pracoval na podpoře větších fyzicky souvislých stránek v cache stránek. Bylo ale rozhodnuto, že se musí jednat o příznak pro alokátor; funkčnost systému nemůže záviset na úspěšnosti alokace. V obou případech bude prvním krokem zaslání kódu k revizi.

Diskuse k tomuto článku

[mmmm]

Možná už se to tu někdy řešilo, ale proč jsou tyto články publikovány s tak velkým zpožděním oproti originálům. Přesto díky.

[anonym]

A) preklad neco trva

B) pristup k aktualnimu LWN je placeny, archiv davaji zdarma

[registrovaný]

Jemonže překlad trval skoro dva týdny od uvolnění v archivu.

Takže si, anonyme, tazateli vůbec nic nevysvětlil.

[2X4B-523P]

je to hlavně pro neanglicky mluvící a líné uživatele... admini, kteří pravidelně aktualizují si čtou změny přímo a zavčas...

[registrovaný]

Ale stejně ty překlady trvají neskutečně dlouho.

[pavlix]

A?

[nnnn]

Hurá, náš malý Pavlix se dnes ve školce naučil písmeno A a otazník !

[R]

Ak sa ti nepaci, mozes robit preklady rychlejsie.

[Saljack]

Myslím, že žádný problém neexistuje. Proč by někdo chtěl používat 32bitový systém s tak velkým diskem?

[R]

Pretoze ma zariadenie s 32-bitovym CPU a potrebuje skopirovat nejake data z 16TB disku, ktore sa mozno coskoro budu predavat s USB rozhranim?

[Jendа]

Protože je embedded 32b SoC šíleně levný a málo žere.

[Milan Roubal]

Kde presne lezi to omezeni? Mam system Synology DS413j, procesor Marvell Kirkwood mv6282 armv5te, coz je podle vseho 32bitovy system a uvazuji o update disku v tomto roce. Jsou tu 3 varianty:

1. 4x 4TB disk - pri RAID5 a ext4 by nemel byt zadny problem
2. 4x 5TB disk - pri RAID5 ma disk 15TB, tedy s ext4 to bude fungovat?
3. 4x 6TB disk - pri RAID5 ma disk 18TB, tedy bude s tim problem? Pokud ano, bude fungovat 2x RAID5, jeden s velikosti 16 TB a druhy 2 TB?

[MalyZelenyHnus]

Problem je v jakemkoliv blokovem zarizeni >16TiB. (Testovano shodou okolnosti na jadre 2.6.31, Marvell Feroceon 6282): 1) zadny problem 2) zadny problem (vsechna blokova zarizeni <16TiB) 3) jo, to je problem. Ext4 ma rozumne nastroje, ktere ti a) zabrani vytvoreni fs, ktery neni mozne adresovat 32 bity, b) pri pouziti 64bit rozsireni ext4 to na 32bitu sice naformatujes, ale nejde primountovat. MDRAID je jeste veselejsi - dovoli ti pole vytvorit i sestavit a tvari se korektne. Ale kdyz jsem tam zapisoval pomoci dd, po chvili se zapisovana data zacala proste ztracet (tj. write() tvrdil ze zapsal, na disky se skrz mdraid vrstvu nic nedostalo).

Dve samostatna pole 16TiB a 2TiB fungovat budou, dokonce muzes udelat na discich dve partysny a do jednoho pole dat prvni partysny, do druheho zbyle. Tusim ze neco podobneho pouziva i QNAP.

[j]

Ja bych dokonce rek, ze lze i varianta dat to vse do jednoho raidu ... a rozdelit to na vic partysen. A dokonce by to pak mozna slo sfouknout tak, ze se to pro system bude jevit jako vic mensich disku, ale navenek jako jeden velkej.

Ale takovou R5tku bych nechtel prepocitavat ani na HW raidu, natoz na SW.

[MalyZelenyHnus]

Samozrejme, jeden velky raid + partysny na nem nepomuze, zase by tam bylo zarizeni >16TB.

Ja jsem navrhoval nejdriv udelat partysny na discich a nad partysnama udelat vice RAIDovych poli. Oproti reseni "dva disky pro jedno pole, dva disky pro druhe" to nezmensi pocet zarizeni v poli, takze se muze pouzit i raid5/6/10, ktere pozaduji vic disku.

Jeste jsem delal pokusy s aufs, ale pro ten stary (2.6.31) kernel to melo nejake bugy. Aufs (a existuje vic podobnych filesystemu) je filesystem, ktery nepracuje nad jednim blokovym zarizenim, ale nad nekolika a rozhazuje mezi nimi soubory podle ruznych nastaveni. Nevytvari teda velke blokove zarizeni, ale presto poskytuje sluzby jednoho souboroveho systemu. Takze komu staci jeden velky filesystem, muze vzit dve nebo vic disku (raidu) <16TB a vytvorit na nem jeden fs takhle. Zkusenosti s provozem ale nemam a moc bych tomu neveril.

[Kvakor]

Ještě je tu možnost použit distribuovaný souborový systém, i když poběží na jediném stroji. Celková velikost klidně může být >16TB, stačí jen aby jednotlivá zařízení byla menší. Nevýhodou by byl poněku nižší výkon, ale pokud se opravdu jedná o něco na způsob NAS, tak to pravděpodobně nebude zas tak velký problém (protože úzké hrdlo bude ve většině případů síť). Možná by dokonce stačilo použít jen "RAID" vlastnosti Btrfs (rozložení přes víc blokových zařízení), ale nejsem si jistý, jak přesně je to řešeno uvnitř.

[Milan Roubal]

Presne tak jsem to myslel, udelat nekolik poli pres 4 disky vzdy nad partition. Prepocitavani RAIDu se nebojim, s tim spatne zkusenosti nemam, spise se bojim e2fsck nad jednim velkym diskem, protoze ta masina na to nema dost pameti.

[Kvakor]

To jde obejít tak, že se buď celý souborový systém (nebo jednolivé oddíly) vyexportuje jako blokové zařízení (NBD nebo iSCSI) a zfscká se ze stroje, který má paměti dost. Jen to bude nejspíš trvat pekelně dlouho ...

[Honz]

Cachí je krásné slovo...

[Gilhad]

se zaměřila na řasu problémů zní taky půvabně :)