Chris Down v obsáhlém článku „vyvrací mýty o zswap a zram“, vysvětluje, co vlastně dělají a jaké jsou mezi nimi rozdíly. Doporučuje vyhýbat se zram na serveru a bez OOM.
Porota v Los Angeles shledala firmy Google a Meta odpovědnými v přelomovém soudním sporu, který se týká závislosti na sociálních sítích; firmy musí zaplatit odškodné tři miliony dolarů (63,4 milionu Kč). Společnosti, které s verdiktem nesouhlasí, čelily obvinění, že své sociální sítě a platformy záměrně navrhly tak, aby si na nich děti vypěstovaly závislost. Porota došla k závěru, že technologické společnosti při navrhování a
… více »Jelikož vývojáři editorů Vim a Neovim začali při vývoji využívat LLM, Drew DeVault se rozhodl forknout Vim a vytvořil projekt Vim Classic. Vychází z Vimu 8.2.0148, tj. těsně před zavedením Vim9 skriptování.
Byla vydána nová verze 0.56 open source počítačové hry Unvanquished (Wikipedie), forku počítačové hry Tremulous. Instalovat ji lze také z Flathubu.
FreeCAD (Wikipedie), tj. svobodný multiplatformní parametrický 3D CAD, byl vydán ve verzi 1.1 (YouTube). Po roce a čtyřech měsících od předchozí verze 1.0. Přehled novinek i s náhledy v poznámkách k vydání.
Společnost OpenAI oznámila [𝕏], že ukončí aplikaci Sora pro generování krátkých videí pomocí umělé inteligence. Podrobné informace a harmonogram pro aplikaci a API budou brzy zveřejněny.
Evropská směrnice NIS2 přináší nové požadavky v oblasti kybernetické bezpečnosti, které se promítají také do správy doménových jmen. Do českého právního řádu je směrnice implementována prostřednictvím nového zákona o kybernetické bezpečnosti. Jedním z praktických důsledků této legislativní změny je posílení požadavků na dostupnost a správnost kontaktních údajů držitelů domén. Správce registru domény .cz, sdružení CZ.NIC, je v
… více »Jonathan Thomas oznámil vydání nové verze 3.5.0 video editoru OpenShot (Wikipedie). Zdrojové kódy OpenShotu jsou k dispozici na GitHubu. Ke stažení je i balíček ve formátu AppImage. Stačí jej stáhnout, nastavit právo na spouštění a spustit.
Byla vydána (𝕏, Bluesky) nová verze 2026.1 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem 8 nových nástrojů v oficiálním oznámení na blogu.
Vláda jmenovala novým zmocněncem pro digitalizaci a strategickou bezpečnost prvního náměstka ministra vnitra Lukáše Klučku. Ten ve funkci nahradil poslance Roberta Králíčka poté, co Králíček na tento post vládního zmocněnce rezignoval. Klučka chce do roka digitalizovat všechny státní služby tak, aby vyhověly zákonu o právu na digitální služby, přičemž dosavadní plán Fialovy vlády počítal s dokončením digitalizace až někdy v roce
… více »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.
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í.
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.
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í“.
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.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
14.4.2014 15:41
pavlix | skóre: 54
| blog: pavlix
14.4.2014 13:02
Saljack | skóre: 28
| blog: Saljack
| Praha
14.4.2014 22:04
Jendа | skóre: 78
| blog: Jenda
| JO70FB
15.4.2014 14:41
Gilhad | skóre: 20
| blog: gilhadoviny
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz