Jaderné noviny - 3. 3. 2016: Perzistentní paměť a příznak „vím, co dělám“

12. 3. 2016 | Redakce | Jaderné noviny | 4837×

Stav vydání jádra. Zpráva ze soudního slyšení VMware. Perzistentní paměť a příznak „vím, co dělám.“

Stav vydání jádra

Současný vývojový kernel nese označení 4.5-rc6 a byl vydán 28. února. Linus k tomu řekl: „Rád bych řekl, že vše směřuje k běžnému datu vydání, ale uvidíme, jak to bude vypadat příští týden. Pokud se rc7 nezačne zmenšovat, možná se rozhodnu, že toto bude vydání, kdy uděláme ještě rc8. Zatím je příliš brzy. Nic strašidelného se neděje, ale byl bych rád za klidnější týden.“

Stabilní aktualizace: 4.4.3, 3.14.62 a 3.10.98 byly vydány 26. února.

Verze 4.4.4 (342 změn), 3.14.63 (130 změn) a 3.10.99 (80 změn) byly v době psaní tohoto článku v procesu revidování, nyní již by měly být venku. Díky těmto verzím jádra se fronta aktualizací, čekajících na své zařazení do stabilního jádra, konečně vyprázdnila, říká Greg Kroah-Hartman.

Welte: Zpráva ze soudního slyšení VMware GPL

Harald Welte má na svém blogu report ze soudního slyšení v Německu, které se týkalo VMware a jejich údajného porušování GPL. Welte je bývalý jaderný vývojář a také zakladatel gpl-violations.org, takže má o případ velký zájem. Ten vyvolal Christoph Hellwig a platí ho Software Freedom Conservancy. Podle Welteho zde jde o dvě věci: zda jsou vmklinux a vmkernel jedna nebo dvě díla (ve smyslu ochrany práv – copyrightu) a zda má Hellwig právo žalovat: „Situaci využívá VMware k obhajobě tvrzením, že vlastně využili jen velmi málo funkcí, jejichž autorství lze připsat Christophovi, a že celkově může jít o 1 % procento linuxového kódu, který používají v ESXi. Soud uznává složitost případu, protože v německém autorském právu funguje něco, čemu se říká koncept ‚slábnutí‘ (fading). Jestliže došlo k takové úpravě původního díla jednoho autora, že je téměř nerozeznatelné, jeho původní dílo ‚zesláblo‘ a s ním i jeho práva. Soud zatím nerozhodl, zda věří, že se tak stalo. Naopak uvádí, že i několik řádků kódu může mít velký vliv na dílo jako celek. Nicméně je velmi problematické rozhodnout, jelikož soud nerozumí zdrojovým kódům a vývoji softwaru. Takže pokud (po dalších rozpravách z obou stran a projednání u soudu) se bude i nadále jednat o otevřenou věc, může se stát, že si soud vyžádá odborného znalce, který by soudu tyto věci objasnil.“

Perzistentní paměť a příznak „vím, co dělám“

Neil Brown minulý týden napsal ve svém článku, že vývojáři pracující na perzistentní paměti mají našlápnuto k vyřešení problému se systémovým voláním fsync(). Funkční fsync() umožní aplikacím ujistit se, že zapsaná data jsou bezpečně uložena v perzistentní paměti – a co je důležitější – že aplikace, které byly korektně napsány pro posixové souborové systémy obecně, budou s perzistentní pamětí fungovat správně, aniž by si všimly rozdílu. Někteří vývojáři ovšem chtějí psát kód, který bude specifický pro perzistentní paměť – jako způsob, jak zvýšit výkon. Patch, který se týká těchto potřeb, se stal předmětem dlouhých debat o tom, jak zajistit, aby se data zapsaná do perzistentní paměti neztratila, a jak by měl vývoj v této oblasti pokračovat.

Problém se vznikajícím řešením v podobě fsync() je podle Boaze Harroshe v tom, že vyžaduje, aby jádro udržovalo radixový strom všech stránek, které by mohly obsahovat nepřesné nebo nekompletní řádky dat v cache CPU. Jestliže byla aplikace napsána s ohledem na perzistentní paměť, může zabránit v ponechávání dat v cache. Tato data mohou být explicitně přesunuta (flushed) aplikací nebo, jako alternativa, mohou být použito trvalé (non-temporal) zápisování k úplnému obejití cache CPU. Pokud aplikace takové techniky využívá, není podle Boaze potřeba, aby kernel příslušné řádky cache perzistentní paměti mazal, takže je možné zcela se vyhnout plýtvání udržováním radixového stromu.

Jenže kernel v současné době nemá možnost zjistit, zda se aplikace stará o svou vlastní cache (vyrovnávací paměť). Napravit by to měl Boazův patchset zveřejněný v únoru. Přidává příznak MAP_PMEM_AWARE pro systémové volání mmap(). Pokud aplikace mapuje soubor uložený v perzistentní paměti s tímto příznakem a souborový systém podporuje mechanismus DAX (direct-access), pak může kernel předpokládat, že si aplikace obstará vlastní správu cache a kernel tak nebude muset sledovat stránky s možnými nekompletními řádky cache. Podle Boaze má tento patch velký vliv na zlepšení výkonu.

Nějaké obavy

Upřímně řečeno, tento patch se nesetkal s všeobecným přijetím. Objevila se řada námitek, které přidání takové funkcionality kritizují. Zaprvé, i aplikace, která si obstará vlastní cache management, bude muset volat fsync() (potažmo msync()), aby se ujistila, že její data jsou skutečně perzistentní. Děje se tak proto, že data nejsou samostatná – jsou uložená v souborovém systému a aplikace nemůže vědět, zda neexistují nějaká metadata souborového systému, která je třeba přesunout pro zajištění přístupu k datům. Jediným způsobem, jak se přesvědčit, že metadata jsou na disku konzistentní, je volání fsync(), které volají také aplikace, jež pracují s daty na tradičních paměťových médiích.

Teoreticky může aplikace alokovat a zapsat celý soubor, potom zavolat fsync() pro přesun do perzistentní paměti s cílem, že bude moci posléze přepsat data v souboru bez dalších změn v metadatech (kromě časových razítek, která nejsou pro přístup k těmto datům podstatná). Souborové systémy ovšem mohou provádět akce jako je deduplikace dat, opožděná alokace nebo, jak zmínil Christoph Hellwig, copy-on-write operace. Takže vskutku jediný způsob, jak se ujistit, že jsou data skutečně bezpečně zapsána v perzistentní paměti, je zavolat fsync(). Příznak MAP_PMEM_AWARE by tento požadavek neodstranil.

Boaz se ohradil tvrzením, že eliminace volání fsync() nebyla nikdy smyslem patche. Místo toho si klade za cíl uskutečňovat tato volání rychleji. Další režie, spojená zejména s výpadky stránek v oblastech nad perzistentní pamětí, by byla snížena. Bohužel, obavy z MAP_PMEM_AWARE tímto nekončí.

Uvažme například interakci mezi aplikacemi, které využívají tento příznak, a ostatními, které si perzistentní paměti nejsou vědomy. Takové aplikace (a může jít o něco tak jednoduchého jako mv nebo nástroj pro zálohování) mohou vytvářet změny v metadatech, které vyžadují zápis, a mohou tak vytvořit nekompletní řádky cache v oblasti perzistentní paměti, o které aplikace pracující s perzistentní pamětí nic nevědí. Zkušenosti s přímým I/O ukazují, že takové interakce mohou být záludné, těžko detekovatelné a je nemožné je opravit.

Snad největší starostí jsou vývojáři aplikací, kteří co nejrychleji prohlásí, že jejich kód si je „vědom“ [perzistentní paměti], aniž by ve skutečnosti pochopili vše, co potřebují k tomu, aby se mohli zaručit za integritu svých dat. Podle Dava Chinnera se téměř každý vývojář aplikací, který tvrdí, že rozumí tomu, jak souborové systémy poskytují integritu dat, skoro vždycky plete. Pokud by kernel poskytoval těmto vývojářům příznak „vím, co dělám“, potom by na základě těchto úvah mohli brzy začít psát kód, který dokazuje nedostatek těchto znalostí – na úkor uživatelů.

Dalo by se říct, že všechny takové aplikace, které obsahují chyby, budou buď opraveny, nebo nahrazeny něčím lepším. Ovšem Dave dal jasně najevo, že takový vývoj nepředvídá.

Historie nám říká něco jiného. Uživatelé vždy viní nejprve souborový systém, načež vývojáři odmítnou opravit své aplikace, protože si myslí, že by je to buď zpomalilo, nebo se jedná o problém souborového systému, jelikož testovali na jiném souborovém systému a tam to fungovalo. Výsledkem je, že nám nezbude než pracovat s takovými problémy v souborovém systému, aby uživatelé nepřišli o data vlivem mizerných aplikací.

To stejné se stane zde – souborové systémy budou ignorovat tento speciální příznak „vím, co dělám“, protože drtivá většina vývojářů aplikací ani neví dost na to, aby si uvědomili, že neví, co vlastně dělají.

Poslední bod je ovšem klíčový. Vývojáři souborových systémů budou z pudu sebezáchovy tento příznak ignorovat, protože alternativou je čelit hněvu uživatelů, kteří je budou vinit ze ztráty dat. Konflikt týkající se ztráty dat na ext4 z roku 2009 zanechal rány, které se dosud nestačily zahojit, a vývojáři si rozhodně nepřejí být znovu v podobné situaci.

Integrita dat na prvním místě

Vývojáři měli ještě jeden důvod, proč se stavět proti tomuto patchi – ten však se specifiky patche samotného skoro nesouvisí. DAX a jeho přidružené funkce perzistentní paměti jsou stále nové, takže je jasné, že se stále objevují problémy. Dave prohlásil, že základní problém bezpečného ukládání dat skrze DAX se ještě nepodařilo vyřešit, takže není dobrý nápad zabývat se optimalizacemi. Zatím je třeba soustředit se na spolehlivost. Až pak přijde čas podívat se na problémy s výkonem a optimalizovat.

Selhání při řešení problémů se správným chováním jen povede k dalším problémům s přibývajícími dalšími funkcemi. Přirovnal to k problému s Btrfs, u nějž se známé problémy nevyřešily včas a výsledkem jsou hluboce zakořeněné nedostatky, které je téměř nemožné odstranit. Pokud se tyto známé problémy nepodaří odstranit dříve v DAXu, může dojít ke stejné situaci.

Také by rád viděl obecné optimalizace, namísto optimalizace zaměřené na několik málo programů. Oprava problémů místo jejich obcházení přinese výhody všem, tedy lepší výsledek než v případě, že se povolí několika aplikacím implementovat jejich vlastní řešení. Pokud se tyto aplikace rozhodnout dělat si věci po svém, nebudou mít prospěch z těch obecných vylepšení a následně budou mít tato zlepšení menší šanci na realizaci.

Oddalování a zpožďování prací, které by vývojáři kernelu rádi viděli začleněné, není nikdy příjemné. Daná práce byla vykonána z nějakého důvodu a její odmítnutí znamená, že alespoň nějaká část byla provedena zbytečně, což může vést ke vzniku pocitu křivdy. Ovšem zkušenosti ukazují, že oddalování prací, které působí nehotově nebo v nesouladu s dlouhodobými cíli, vede k lépe udržitelnému jádru v dlouhodobém horizontu. Infrastruktura DAX bude muset dlouho sloužit jako důležitý, jádrem podporovaný přístup k perzistentní paměti. Komunita si nemůže dovolit udělat v tomto případě chybu. Konzervativní přístup je tedy v této oblasti alespoň zatím na místě.

       

Komentáře

[lertimir]

Máte někdo vědomosti o jakých problémech s btrfs vlastně mluví v:

Selhání při řešení problémů se správným chováním jen povede k dalším problémům s přibývajícími dalšími funkcemi. Přirovnal to k problému s Btrfs, u nějž se známé problémy nevyřešily včas a výsledkem jsou hluboce zakořeněné nedostatky, které je téměř nemožné odstranit.

Na původním článku jsem si našel, že se jedná o:

ENOSPC, single tree lock, using generic RAID and device layers, etc

Ale blíže o tom nic nevím, co jsou to za problémy a jaké omezení generují.