Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
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.
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)
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.
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í.
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í.
Nástroje: Tisk bez diskuse
Tiskni Sdílej: