abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 19:22 | Nová verze

Byla vydána verze 11.3 open source alternativy GitHubu, tj. softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech, GitLab (Wikipedie). Představení nových vlastností i s náhledy v příspěvku na blogu.

Ladislav Hagara | Komentářů: 0
22.9. 13:00 | Komunita

Do 30. října se lze přihlásit do dalšího kola programu Outreachy (Wikipedie), jehož cílem je přitáhnout do světa svobodného a otevřeného softwaru lidi ze skupin, jež jsou ve světě svobodného a otevřeného softwaru málo zastoupeny. Za 3 měsíce práce, od 4. prosince 2018 do 4. března 2019, v participujících organizacích lze vydělat 5 500 USD.

Ladislav Hagara | Komentářů: 88
21.9. 22:22 | Komunita

Společnost Purism představila kryptografický token Librem Key. Koupit jej lze za 59 dolarů. Token byl vyvinut ve spolupráci se společností Nitrokey a poskytuje jak OpenPGP čipovou kartu, tak zabezpečení bootování notebooků Librem a také dalších notebooků s open source firmwarem Heads.

Ladislav Hagara | Komentářů: 8
21.9. 20:33 | Nová verze

Společnost NVIDIA oficiálně vydala verzi 10.0 toolkitu CUDA (Wikipedie) umožňujícího vývoj aplikací běžících na jejich grafických kartách. Přehled novinek v poznámkách k vydání.

Ladislav Hagara | Komentářů: 0
21.9. 20:00 | Upozornění

Příspěvek Jak přežít plánovanou údržbu DNS na blogu zaměstnanců CZ.NIC upozorňuje na historicky poprvé podepsání DNS root zóny novým klíčem dne 11. října 2018 v 18:00. Software, který nebude po tomto okamžiku obsahovat nový DNSSEC root klíč, nebude schopen resolvovat žádná data. Druhým důležitým datem je 1. února 2019, kdy významní výrobci DNS softwaru, také historicky poprvé, přestanou podporovat servery, které porušují DNS standard

… více »
Ladislav Hagara | Komentářů: 11
21.9. 15:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 156. brněnský sraz, který proběhne v pátek 21. září od 18:00 v restauraci Na Purkyňce na adrese Purkyňova 80.

Ladislav Hagara | Komentářů: 0
21.9. 13:22 | Nová verze

Alan Griffiths z Canonicalu oznámil vydání verze 1.0.0 display serveru Mir (GitHub, Wikipedie). Mir byl představen v březnu 2013 jako náhrada X serveru a alternativa k Waylandu. Dnes Mir běží nad Waylandem a cílen je na internet věcí (IoT).

Ladislav Hagara | Komentářů: 0
20.9. 22:00 | Nasazení Linuxu
Stabilní aktualizace Chrome OS 69 (resp. Chromium OS), konkrétně 69.0.3497.95, přináší mj. podporu linuxových aplikací. Implementována je pomocí virtualizace, a proto je tato funkce také omezena na zařízení s dostatkem paměti a podporou hardwarové akcelerace, tudíž nejsou podporovány chromebooky s 32bitovými architekturami ARM, či Intel Bay Trail (tzn. bez Intel VT-x).
Fluttershy, yay! | Komentářů: 5
20.9. 21:32 | Zajímavý projekt

Došlo k uvolnění linuxové distribuce CLIP OS, vyvíjené francouzským úřadem pro kybernetickou bezpečnost ANSSI, jako open source. Vznikla za účelem nasazení v úřadech, kde je potřeba omezit přístup k důvěrným datům. Je založená na Gentoo.

Fluttershy, yay! | Komentářů: 2
20.9. 16:00 | Komerce

Zjistěte více o bezpečné a flexibilní architektuře v cloudu! IBM Cloud poskytuje bezpečné úložiště pro Vaše obchodní data s možností škálovatelnosti a flexibilitou ukládání dat. Zároveň nabízí prostředky pro jejich analýzu, vizualizaci, reporting a podporu rozhodování.

… více »
Fluttershy, yay! | Komentářů: 12
Na optické médium (CD, DVD, BD aj.) jsem naposledy vypaloval(a) data před méně než
 (13%)
 (14%)
 (21%)
 (23%)
 (24%)
 (3%)
 (0%)
Celkem 401 hlasů
 Komentářů: 33, poslední 16.9. 11:55
Rozcestník

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

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

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

       

Hodnocení: 100 %

        špatnédobré        

Nástroje: Tisk bez diskuse

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

2.10.2017 10:57 JaGa
Rozbalit Rozbalit vše Re: Jaderné noviny – 24. 8. 2017: Další dva přístupy k zápisu do perzistentní paměti
ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.