Hudební přehrávač Amarok byl vydán v nové major verzi 3.0 postavené na Qt5/KDE Frameworks 5. Předchozí verze 2.9.0 vyšla před 6 lety a byla postavená na Qt4. Portace Amaroku na Qt6/KDE Frameworks 6 by měla začít v následujících měsících.
Byla vydána nová verze 2.45.0 distribuovaného systému správy verzí Git. Přispělo 96 vývojářů, z toho 38 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání. Vypíchnout lze počáteční podporu repozitářů, ve kterých lze používat SHA-1 i SHA-256.
Před 25 lety, ve čtvrtek 29. dubna 1999, byla spuštěna služba "Úschovna".
Byla vydána nová verze 24.04.28 s kódovým názvem Time After Time svobodného multiplatformního video editoru Shotcut (Wikipedie) a nová verze 7.24.0 souvisejícího frameworku MLT Multimedia Framework. Nejnovější Shotcut je vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Byla vydána verze 5.30 dnes již open source operačního systému RISC OS (Wikipedie).
V aktuálním příspěvku na blogu počítačové hry Factorio (Wikipedie) se vývojář s přezývkou raiguard rozepsal o podpoře Linuxu. Rozebírá problémy a výzvy jako přechod linuxových distribucí z X11 na Wayland, dekorace oken na straně klienta a GNOME, změna velikosti okna ve správci oken Sway, …
Rakudo (Wikipedie), tj. překladač programovacího jazyka Raku (Wikipedie), byl vydán ve verzi #171 (2024.04). Programovací jazyk Raku byl dříve znám pod názvem Perl 6.
Společnost Epic Games vydala verzi 5.4 svého proprietárního multiplatformního herního enginu Unreal Engine (Wikipedie). Podrobný přehled novinek v poznámkách k vydání.
Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Aktuální předverze řady 2.6 je 2.6.20-rc3. Linus ji vydal těsně před Novým rokem. Obsahuje opravu chyby, která způsobovala poškození souborů (vizte níže) a pár set dalších oprav.
23. prosince vyšla s další velkou dávkou oprav verze 2.6.20-rc2.
Od vydání -rc3 bylo do hlavního git repozitáře přidáno jen několik patchů. V seznamu neopravených regresí, který spravuje Adrian Bunk, je teď šest položek.
Aktuální verze -mm stromu je 2.6.20-rc2-mm1. Mezi nedávné změny patří nová verze patche pro ovladače v uživatelském prostředí, další háčky [hooks] pro paravirtualizaci, implementace obecného času pro x86_64 a obecný kód pro ovladače GPIO.
Starší jádra: verze 2.6.16.37 byla 28. prosince vydána s velkým počtem oprav.
2.4.34 vyšla také 28. prosince. Obsahuje několik bezpečnostních oprav a podporu kompilátorů gcc 4.x.
Je mi to docela jedno, fakt. Ale na druhou stranu... já tomu rozumím. Zkus někomu vysvětlovat, jak spolu souvisí nečisté pte, stránky, radix stromy a buffer_head [pte-dirtiness, page-dirtiness, radix-tree-dirtiness and buffer_head-dirtiness].
Psaní ovladačů zařízení může být zrádné. Samotné zprovoznění zařízení - často s pomocí chybné nebo neexistující dokumentace - může být nepříjemná práce. Kromě toho však musí ovladač pro zařízení alokovat několik různých druhů zdrojů; například mapování paměti pro I/O, linky přerušení, bloky paměti, DMA buffery, registrace u více subsystémů atd. Všechny tyto alokace musí být po zmizení zařízení (nebo jeho ovladače) vráceny systému. Není neobvyklé, že autoři ovladačů něco zapomenou dealokovat, což vede k úniku zdrojů.
Když do toho započteme inicializační chyby, může být problém ještě horší. Pokud se ovladači nepodaří zařízení správně nastavit, musí vrátit všechny registrace, které až do té chvíle provedl. Pokusy o řešení chyb při inicializaci většinou nabývají podoby několika goto značek v rámci inicializační funkce nebo nějaké globální proměnné "inicializačního stavu", která popisuje, kde by mělo čištění začít. Tak jako tak nebývají tyto způsoby moc dobře testovány, takže při selhání inicializace je na nějaký únik zdrojů slušná šance.
Tejun Heo, který během uplynulého roku velmi přispěl k vylepšení linuxového SATA subsystému, už měl těchto inicializačních problémů dost. Takže dal dohromady patch pro správu zdrojů, který by mohl, pokud bude přijat, zařídit ovladačům jednodušší a stabilnější kód. Hlavní myšlenka je prostá: pokaždé, když ovladač alokuje zdroj, kód pro správu si to zapamatuje společně se všemi informacemi potřebnými pro uvolnění. Když se ovladač od zařízení odpojí, jsou všechny zapamatované alokace vráceny systému.
Takový způsob sledování alokací nelze do současného API nijak rozumně přidat. Tejunův patch místo toho vytváří nové, "spravované" verze jednotlivých alokovacích funkcí. Nové funkce vypadají jako ty staré, ale přidávají k názvu "m" (nebo "devm") a také doplňují parametr struct device - pokud už ho funkce nemá. Takže například spravované verze funkcí pro alokaci přerušení jsou:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
int devm_request_irq(struct device *dev, unsigned int irq,
irq_handler_t handler, unsigned long irqflags,
const char *devname, void *dev_id);
void devm_free_irq(struct device *dev, unsigned int irq,
void *dev_id);
Patch také obsahuje spravované funkce pro zacházení s DMA buffery, I/O oblastmi paměti, prostými alokacemi paměti a nastavováním PCI zařízení. Umožní autorovi ovladače nahradit celou skupinu dealokačních volání jediným zavoláním devres_release_all(), což kód výrazně zjednoduší. I toto volání je vlastně zbytečné; ovladačové jádro ho zavolá, když se ovladač od zařízení odpojí.
Pro komplikovanější situace existuje "skupinový" koncept. Skupiny si lze představit jako značky v sérii alokací prováděných daným zařízením. Alokace v rámci jedné skupiny je možné vrátit bez ovlivnění ostatních. Skupinové API vypadá takto:
void *devres_open_group(struct device *dev, void *id, gfp_t gfp);
void devres_close_group(struct device *dev, void *id);
void devres_remove_group(struct device *dev, void *id);
int devres_release_group(struct device *dev, void *id);
Volání devres_open_group() vytvoří pro dané zařízení novou skupinu identifikovanou hodnotou id. Všechny potom provedené alokace budou považovány za součást této skupiny, dokud není zavoláno devres_close_group(). Pokud však inicializace funguje podle plánu, lze použít devres_remove_group(), což odstraní režii skupiny, ale alokace (včetně informací o nich) ponechá netknuté. Dojde-li k problému, devres_release_group() vrátí všehny alokace, které do skupiny patří.
O této sadě patchů se zatím moc nediskutovalo. Autoři ovladačů se možná ještě vzpamatovávají z vánočních oslav. Není těžké si představit, že by všechna ta extra režie spojená se sledováním alokací vyvolala nelibost - zvláště uvážíme-li, že ve většině případů věci normálně fungují. Nakonec by však mohl příslib správné funkce v širším spektru situací začlenění nového rozhraní motivovat.
V minulém čísle se psalo o chybě způsobující poškození souborů, která se vyskytovala převážně (ale ne pouze) u souborových systémů ext3. Některé aplikace s nezvyklým způsobem přístupu k souborům mapovaným v paměti mohly občas vidět mezery tam, kde se data nedostala až na disk. Jednou z těchto aplikací je rtorrent; jak se honba za odhalením příčiny chyby stupňovala, byly nalezeny (a vyvinuty) další případy pro testování. Problém je teď vyřešen, ale poučil nás o tom, jak se může taková nenápadná chybka projevit - a jak ji opravit.
V zájmu snahy o vysvětlení jsem [Jonathan Corbet] opět zapřáhl své spíše pochybné umělecké vlohy. Proto čtenáře laskavě prosím, aby popatřili na diagram zobrazený vpravo a potlačili své pochybnosti natolik, že si v něm představí stránku paměti - stránku, která obsahuje zajímavá data, a která reprezentuje ekvivalentní sadu bloků nacházejících se na disku v rámci souboru. Rozlišení mezi stránkou a jejími bloky je důležité, a proto stránku rozdělují tečkované čáry. Stránka v paměti o 4096 bajtech je nejspíše reprezentována osmi diskovými bloky o 512 bajtech (které jsou pravděpodobně zase spojeny diskovou jednotkou, ale budeme předstírat, že se to neděje).
Existuje pár jaderných datových struktur, které o této stránce obsahují informace, což diagram trochu komplikuje:
Stránka může být mapována do jednoho nebo více adresních prostorů procesů. Pro každé takové mapování bude záznam v tabulce stránek [PTE - page table entry], který provádí překlad mezi virtuální adresou v uživatelském prostoru a fyzickou adresou, kde se stránka doopravdy nachází. V PTE jsou ještě další informace, včetně "nečistého" bitu ["dirty" bit]. Když aplikace stránku upraví, procesor nastaví nečistý bit, což operačnímu systému umožní zareagovat například zapsáním stránky zpět na úložné zařízení. Ukazuje-li na jednu stránku více PTE, nemusí se shodovat v tom, jestli je stránka čistá nebo ne. Jediným způsobem, jak to zjistit, je projít všechny existující PTE a podívat se, jestli není některý z nich označen jako nečistý.
Jádro si udržuje samostatnou datovou strukturu známou jako mapa paměti systému; obsahuje jednu struct page pro každou existující fyzickou stránku. Tato struktura obsahuje několik zajímavých informací, včetně ukazatele na zálohu [backing store] stránky (pokud nějaká existuje), datové struktury umožňující relativně snadno nalézt příslušné PTE a sadu příznaků. Jeden z těchto příznaků je nečistý bit - další příznak, který značí, že by stránku bylo potřeba zálohovat.
A nakonec sada struktur, které mohou být se stránkou spojeny:
"Hlava bufferu" ["bh" - buffer head] pochází z nejranějších dnů Linuxu. Lze si ji představit jako mapování mezi diskovým blokem a jeho kopií v paměti. Bh už není tak důležité pro linuxovou správu paměti jako dříve, ale dost souborových systémů to pořád používá pro sledování diskového I/O. Ne každý blok na stránce musí mít nutně bh; pokud si souborový systém myslí, že zapsat potřebují jen některé bloky, nemusí pro ty ostatní bh struktury vytvářet. Kromě jiného obsahuje bh struktura ještě další nečistý příznak.
Když je tolik příznaků, které značí v podstatě totéž, není tak překvapivé, že nakonec vznikly zmatky. Správa redundantních datových struktur může představovat problém všude - tím více u jádra, které přidává ještě další obtíže.
Hluboko v jádře je funkce nazývaná set_page_dirty(); používá ji kód pro správu paměti, když si všimne (díky PTE nebo přímé akci aplikace), že stránka potřebuje zapsat do zálohy. Mimo jiné zkopíruje nečistý bit ze záznamů tabulky stránek do struktury page. Je-li stránka součástí souboru, zavolá set_page_dirty() zpět do příslušného souborového systému - ale pouze pokud daný souborový systém poskytuje odpovídající metodu. Mnohé souborové systémy však zpětné volání set_page_dirty() nenabízejí; u těchto souborových systémů tedy jádro projde seznam všech souvisejících bh struktur a každou označí jako nečistou.
A v tom je ten problém. Souborový systém si mohl klidně všimnout, že blok reprezentovaný daným bh je nečistý, a začít na něm I/O před voláním set_page_dirty(). Když je I/O hotový, souborový systém odstraní z bh nečistý příznak. Pokud dojde na volání set_page_dirty() ve chvíli, kdy na bloku probíhá I/O, souborový systém si nevšimne, že se data bloku mohla po zápisu změnit. Místo toho bude blok označen jako čistý, ačkoliv to, co bylo zapsáno, neodpovídá tomu, co je právě v paměti. Výsledkem je poškození dat.
Linusova oprava je jednoduchá. Když se subsystém virtuální paměti rozhodne, že je na čase zapsat stránku, provede se nové volání set_page_dirty(). To zajistí, že v okamžiku volání metody writepage() souborového systému budou všechny bh označeny jako nečisté. Díky tomu je jisté, že budou zapsány všechny bloky stránky; testování potvrdilo, že problém s poškozováním souborů se tím odstraní. Patch byl zařazen do hlavního git repozitáře; měl by se objevit i ve stabilní aktualizaci 2.6.19.
Do budoucna je řešením pokračovat ve vytlačování bh z cest jaderných I/O. Linus k tomu řekl:
Buffer head je posledních několik let čistě "IO entita" a ne kešová entita. Když někdo používá pro zápis do zálohy bh, přeskakuje tím skutečnou keš (stránkovou), a proto s tím jsou problémy.
Myslím, že ext3 je už v posledních křečích. Pořád používá bh v místech, kde by vážně neměl. Výsledkem je, že věci jako přístup k adresářům jsou pomalejší, než by měly. Bohužel mám dojem, že ani ext4 nic z toho neopraví.
Ted Ts'o odpověděl, že oprava pro ext4 není úplně vyloučena, ale týká se to i jiných souborových systémů. Ext3 však pravděpodobně bh nepřestane používat, takže je jádro bude muset podporovat navždy.
Tento příběh ukazuje, jak těžké může být najít a opravit některé druhy chyb v jádře. Zpočátku bylo pro vývojáře obtížné problém reprodukovat, takže museli spoléhat na to, že za ně budou patche testovat ti, kdo chybu původně objevili. Tito testeři vydrželi po celou dobu, přičemž zkompilovali a otestovali hodně jader, než byl od problému pokoj. Zaslouží si velkou část uznání za vyřešení.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Kořen slova je patřit a předpony s- nebo po-. Slovník uvádí význam pohlédnout, podívat se, slovo je knižní a zastaralé, ale pěkné
25.1.2007 10:01
Petr (DotaZ) Jakubec | skóre: 5
jsou podle meho asi nejstabilnjsi FS. (nevite zda se ta chyba tyka i xfs??)
proto me prekvapuje ze ani Linus nepredpoklada, ze se ext4 opravi systematicky (bh se budou pouzivat jak maji) a v ext3 (dejme tomu) se to opravi zalatanim (bude to jednodussi a je to mene zmen - lepe se to ohlida).
notabene kdyz by to mohlo mit vliv i na vykon (smerem nahoru) tak by to preci _melo_ byt v ext4 implementovano ciste a poradne! ne?
26.1.2007 01:06
Mikos | skóre: 34
| blog: Jaderný blog
| Praha
ReiserFS mě dvakrát za sebou vyšplouchl zrovna ve chvíli, kdy jsem na hraní s instalací vůbec neměl čas. Od té doby se pověrčivě držím dál.
25.1.2007 19:27
Mikos | skóre: 34
| blog: Jaderný blog
| Praha
Jen dodám, že dle mých dlouhodobých zkušeností je ext3 nesrovnatelně méně stabilní než reiserfs (3.6) a teď už můžu potvrdit že i než jfs. A to vubec nemluvim o té strašné pomalosti ext3 (i když člověk zapne dir_index) a její tragické práci s inody...
Jinak si nejsem jistý, jetli není ve vysvětlení chyby určitá nepřesnost.Coby neprogramátorovi mi nezbývá než spoléhat na to, co napsal Jonathan Corbet na LWN. Je však možné, že a) jsem to špatně přeložil nebo b) to špatně pochopil Jonathan. V obou případech budu rád za opravu.
25.1.2007 18:27