Jaderné noviny – 24. 8. 2017: Další dva přístupy k zápisu do perzistentní paměti

2. 10. 2017 | Redakce | Jaderné noviny | 2817×

Stav vydání jádra. Citát týdne: Vincent Bernat. Další dva přístupy k zápisu do perzistentní paměti.

Stav vývoje jádra

Současné vývojové jádro bylo 4.13-rc6 vydané 20. srpna. „Vše zatím míří k vydání podle plánu, což by znamenalo, že rc7 vyjde příští víkend a finální 4.13 týden poté. Tedy samozřejmě pokud se něco nestane.“

Stabilní aktualizace: v posledním týdnu žádné nevyšly. Verze 4.12.9, 4.9.45, 4.4.84 a 3.16.67 byly v době psaní tohoto článku v procesu revidování, vyšly 24. srpna.

Citát týdne

Ve srovnání s IPv4 nevyvolává IPv6 v Linuxu až takový zájem, zvláště pokud jde o optimalizace. Doufejme, že se věci s jeho přijetím a nasazením „ve větším měřítku“ změní.

—Vincent Bernat profiluje hledání cest IPv6 v jádře (díky Bartu Knubbenovi)

Další dva přístupy k zápisu do perzistentní paměti

Two more approaches to persistent-memory writes. Jonathan Corbet. 23. srpna 2017

Pole perzistentní paměti, která si snad jednoho dne budeme moci pořídit, jsou příslibem velkoobjemových, vysokorychlostních úložišť adresovatelných po bajtech. Jaderná komunita na úplné podpoře této technologie pracuje již několik let, stále je tu však jeden problém postrádající řešení: umožnit přímý zápis do perzistentní paměti, kterou spravuje souborový systém. Žádné z navržených řešení se zatím nedostalo do hlavního repozitáře, ale to dosud vývojáře neodradilo. Nyní se zvažují dvě nové sady patchů věnované této problematice.

Obvykle se souborové systémy starají o všechny vstupní/výstupní operace nad příslušným úložištěm, aby zajistily, že struktura souborového systému je vždy konzistentní. Dokonce i když je soubor na tradičním úložném zařízení namapován do virtuálního adresního prostoru procesu, spravuje souborový systém zpětný zápis (writeback) modifikovaných stránek z cache stránek do perzistentní paměti. Přímo mapovaná perzistentní paměť obchází souborový systém, což ale vede k řadě potenciálních problémů, zahrnujících nekonzistentní metadata nebo poškození a ztrátu dat, pokud souborový systém přesune právě upravovaný soubor. Řešení tohoto problému vyžaduje dovolit souborovému systému jen tolik, aby nedošlo ke zmatkům, ale zároveň byl zachován výkon umožněný přímým přístupem k úložišti.

Dosud navržená řešení zahrnují zvláštní příznak „vím, co dělám“ a nedávno přidané nové systémové volání daxctl(), které slouží ke zmrazení metadat souboru, aby data samotná mohla být bezpečné modifikována přímo na místě. Žádné z těchto řešení se ale neprokázalo jako plně uspokojivé, takže vývojářům nezbylo než zasednout zpátky ke klávesnicím a přijít s novým přístupem.

Synchronní výpadky stránek

Jedním z nových kandidátů je sada patchů synchronních výpadků stránek od Jana Káry. Následuje ve stopách některých předchozích pokusů tím, že zajišťuje provedení zápisu všech potřebných metadat souborového systému, než je procesu dovoleno modifikovat přímo mapovaná data. Systémovému volání mmap() přibyl nový příznak MAP_SYNC, který požaduje synchronní chování, což znamená zejména:

Záruka poskytovaná tímto příznakem je: Když je blok namapován do příslušné tabulky stránek tak, že je do něj možné zapisovat, je zaručeno, že bude i po selhání viditelný v souboru na příslušném offsetu.

Jinými slovy, souborový systém blok v tichosti nepřemístí a zajistí, že metadata souboru jsou v konzistentním stavu, takže příslušné bloky budou po selhání přítomny. Toho se dosáhne tak, že se zajistí provedení všech potřebných zápisů metadat předtím, než je procesu dovoleno zapsat do stránky související s těmito metadaty.

Když je oblast perzistentní paměti namapována s použitím MAP_SYNC, kód správy paměti zkontroluje, zda probíhá zápis metadat příslušného souboru. Nedojde ale k nárazovému provedení zápisů, nýbrž příslušné stránky jsou místo toho namapovány pouze pro čtení se zvláštním příznakem, takže jakmile se do některé z nich proces pokusí provést zápis, dojde k vynucenému výpadku stránky. Obsluha výpadku pak synchronně zapíše příslušná dirty metadata, změní oprávnění stránky, aby byl povolen zápis, a skončí. Za takového stavu může proces provést bezpečný zápis do stránky, jelikož všechna potřebná metadata už jsou v perzistentní paměti.

Výsledkem je poměrně jednoduchý mechanismus, který bude fungovat mnohem lépe než aktuálně dostupná alternativa – explicitní volání fsync() před každým zápisem do perzistentní paměti. Potenciální nevýhodou je, že každá operace zápisu může vyvolat vlnu I/O operací, protože souborový systém se vypořádává s dotčenými dirty metadaty. To může vést k blokování procesu, ačkoliv mělo jít o prostou operaci zápisu do paměti, a tak se objeví nečekaná a nechtěná latence. Obavy z této latence vedly k hledání alternativních řešení.

MAP_DIRECT

Jednou z alternativ je sada patchů MAP_DIRECT Dana Williamse. Lze je považovat za současnou podobu výše zmíněného patche daxctl(), ačkoliv toto nové systémové volání již není součástí návrhu. Místo toho máme zase nový příznak mmap(), ale navrhovaná sémantika je poněkud odlišná. Tento příznak eliminuje možnou latenci při selhání zápisu tím, že „zapečetí“ stav souboru v okamžiku, kdy dojde k jeho namapování.

Když souborový systém uvidí žádost o mapování s použitím MAP_DIRECT, měl by se ujistit, že všechna metadata související s mapovanou oblastí jsou na úložném zařízení konzistentní, než bude pokračovat. Jakmile dojde k namapování, musí souborový systém odmítnout jakoukoli operaci, která by způsobila zápis metadat ovlivňujících namapovanou část souboru. Bloky nelze například přesouvat, pokud souborový systém nemůže pomocí magie provést atomický přesun, aniž by neriskoval ztrátu dat při souběžném zápisu do tohoto bloku jiným procesem. Operace jako zkrácení souboru, přerušení sdílení extentů v souboru nebo alokace bloků selžou. To platí i pro alokaci bloků pro namapovanou oblast. Aplikace se tedy musí ujistit, že všechny příslušné bloky byly alokovány před vytvořením mapování.

Důležitým aspektem této „pečetící“ operace je to, že je součástí běhového stavu souborového systému, neukládá se na úložiště samotné. Takže pokud dojde k pádu systému, soubor už nebude po restartu zapečetěn. Pečeť slouží pouze konkrétnímu mapování a zmizí, jakmile zmizí mapování. Je také třeba poznamenat, že implementace souborového systému může zapečetit buď pouze mapovanou část souboru, nebo soubor celý.

Aplikace, která používá MAP_DIRECT, bude od jádra vyžadovat jasné indicie, že soubor byl opravdu zapečetěn. Bohužel, mmap() je jedno z těch systémových volání, která nekontrolují neznámé příznaky. MAP_DIRECT tak lze použít s libovolným jádrem, aniž by došlo k chybě. Aby to nová sada patchů obešla, přidává novou variantu mmap3(), která s neznámým příznakem opravdu selže. Interně pak přidává struktuře file_operations pole mmap_supported_mask, takže každá nízkoúrovňová implementace může specifikovat, které příznaky dokáže obsloužit. Chtít od aplikací, aby používaly novou verzi mmap() není hezké, ale není jiného způsobu, jak tento problém vyřešit bez změny ABI.

Použití MAP_DIRECT vyžaduje vlastnost CAP_LINUX_IMMUTABLE. Panují obavy, že bez tohoto omezení by mohlo být možné provést útok typu odmítnutí služby (denial of service) zapečetěním souboru, který musí být jiný proces schopen změnit. Výsledkem je, že tato funkce není většině uživatelů dostupná, což její užitečnost poněkud omezuje. Ve snaze situaci vylepšit přidává sada patchů také novou operaci F_MAP_DIRECT volání fcntl(). Tato operace, která rovněž podléhá kontrole [vlastnosti CAP_LINUX_IMMUTABLE], nastaví příznak otevřeného souboru, který způsobí, že příští operace mmap() se budou chovat, jakoby měly příznak MAP_DIRECT, ale bez uvedené kontroly. Myšlenka spočívá v tom, že privilegovaný proces by mohl soubor otevřít a nastavit mu tento příznak, načež by předal deskriptor souboru neprivilegovanému procesu, který nad souborem vykoná požadovanou úlohu.

Jednou z výhod MAP_DIRECT je, že jeho využití se neomezuje na umožnění přímého zápisu do úložiště výkonným aplikacím. Pečetící mechanismus se blíží tomu, co jádro beztak potřebuje pro soubory používané jako odkládací prostor, u čehož je prostor ke zlepšování. Umožňuje také nastavit DMA I/O operace z ovladačů v uživatelském prostoru, což je vlastnost docela zajímavá v oblasti RDMA.

Po zatím posledním zaslání obou sad patchů komentáře poněkud utichly. Oba se pravděpodobně blíží k možnému začlenění. Zatím ale nedošlo na diskuzi o tom, který z přístupů je lepší nebo zda by neměly být nějak zkombinovány do jednoho. Takže i když se komunita blíží k vyřešení přímých zápisů do perzistentní paměti, bude to asi ještě chvíli trvat, než dojde k začlenění některého řešení.

       

Komentáře

[JaGa]

příznak „vím, co dělám“ viz též:

https://cs.wikipedia.org/wiki/Leteck%C3%A9_ne%C5%A1t%C4%9Bst%C3%AD_na_Tenerife_1977

https://cs.wikipedia.org/wiki/%C4%8Cernobylsk%C3%A1_hav%C3%A1rie

https://cs.wikipedia.org/wiki/Costa_Concordia