Portál AbcLinuxu, 9. června 2026 13:57
Aktuální verze jádra: 2.6.30-rc3. Citáty týdne: Ingo Molnár, Rusty Russell. Hledání perfektního changelogu. Mechanismus pomalé práce. DRBD: Distribuované blokové zařízení.
Současné vývojové jádro je 2.6.30-rc3 vydané 21. dubna. Diffstat skutečně ukazuje spoustu malých jednořádkových a dvouřádkových patchů, i když jsou oblasti, kam se dostávají větší patche (ignoruji velké, ale nezajímavé aktualizace defconfig pro arm): nějaké aktualizace x86, některé opravy plánování blokového I/O, pročištění a opravy splice a mnoho změn v ovladačích (zvuk, síťování, staging, usb). Zkrácený changelog je v oznámení, všechny detaily vizte v kompletním changelogu.
Současné stabilní jádro 2.6 je 2.6.29.1; od 2. dubna nebyly žádné stabilní aktualizace 2.6.
Pro fanoušky extrémně stabilních jader je tu nicméně 2.4.37.1 vydané 19. dubna. Většina těchto oprav se týká menších bezpečnostních problémů, které byly backportovány z 2.6 (většinou lokální DoSy). Dle mého mínění by aktualizaci měli zvažovat jenom lidé s lokálními uživateli, pokud takoví ještě existují!
-- Ingo Molnár
-- Ingo Molnár
Když se jaderný vývojář zapojí do dlouhé diskuze o psaní changelogů k patchům, jeden by si mohl myslet, že mu došly užitečné věci, které by mohl dělat. Hádky o changelozích nicméně nejsou to samé, jako flamewary o pravopisu nebo gramatice. V prostředí, kde se v každém tříměsíčním cyklu do jádra začleňuje okolo 10 000 změn, vývojáři potřebují veškerou dostupnou pomoc k tomu, aby porozuměli tomu, co se v něm děje. Špatně popsaným patchům je těžké porozumět a těžké najít, když se v historii hledá něco specifického. Udělat changelogy správně tedy znamená pomoci vývojovému procesu – a jádru – jako celku.
Celé to nicméně začalo nevinně; Linus se účastnil rutinního flamování o patchích, když narazil na značky „Impact:“ (dopad), které někteří vývojáři (obzvláště ti, kteří pracují se stromy Inga Molnára) začali v nedávných měsících používat:
Dopad: zjednodušuje a rozšiřuje existující API
Postačí říct, že ho to příliš neohromilo:
Od té chvíle se delší konverzace zaměřila na dvě s tím spojená témata: Na hodnotu značky „dopad“ a na to, jak obecně psát lepší changelogy. Co se prvního týče, hlavní (ale ne jediný) propagátor těchto značek je Ingo Molnár, který vyjmenoval několik výhod jejich používání. Používání těchto značek, tvrdí, nutí vývojáře psát menší patche, které lze adekvátně popsat jedinou řádkou. Poskytují správcům subsystémů jednoduchý způsob, jak zhodnotit změny vyvolané sadou patchů a riziko s nimi spojené; také zjednodušují revizi patche jeho srovnáním s předpokládaným „dopadem“ Také se o těchto značkách říká, že vynucují jistou čistotu myšlení, kterou nutí vývojáře přemýšlet o dopadu změny.
Většina těchto argumentů s kritiky nepohnula. Ti by místo přidávání další značky byli raději, kdyby vývojáři rovnou psali lepší changelogy. Ve správně dokumentovaném patchi je nová značka prostě irelevantní. Andrew Morton řekl:
S tímto tvrzením Ingo dlouho diskutoval, což není překvapující. Šel ale dál a tvrdil, že i když by lepší changelogy byly určitě žádoucí, nejsou praktickým cílem. Podle Inga většina vývojářů jednoduše neumí psát dobré changelogy. Část problému často představuje neznalost jazyka, ale je zde i něco navíc: Většina vývojářů jednoduše postrádá spisovatelské schopnosti k tomu napsat changelog jasně a stručně. To Ingo považuje za nezvratný fakt, který nelze změnit, ale většinu vývojářů lze alespoň vycvičit k tomu, aby psali rozumnou značku „dopad“.
Je pravděpodobně férové říci, že většina vývojářů se takto postižena necítí. Na druhou stranu je ale nutné dodat, že mnoho patchů se do hlavní řady dostane bez užitečného changelogu. To lze pravděpodobně změnit – přinejmenším v nějakém rozsahu – tlakem od správců a lepším porozuměním tomu, jak dobrý changelog napsat. Jako pokus o pomoc Jonathan Corbet, autor tohoto článku, navrhl krátký dodatek do Documentation/development-process:
Další možné dodatky navrhl Ted Ts'o a Paul Gortmaker. Všechny tyto patche jsou samozřejmě postaveny na základě optimistického předpokladu, že vývojáři čtou dokumentaci.
Dalo by se dohadovat, že jaderná komunita se k tomuto problému dostává poněkud pozdě. Je to očekávatelné; v době před BitKeeperem (tj. do února 2002) se jednotlivé změny jádra téměř vůbec nesledovaly. To, že se o pouhých sedm let později diskutuje, jak psát správné changelogy, naznačuje, že se věci pohybují správným směrem. Úroveň profesionality jaderné komunity roste již nějaký čas; tento proces bude pravděpodobně pokračovat. Ať už se v budoucnu nějaká forma značky „Dopad“ bude používat, nebo ne, lze předpokládat, že kvalita changelogů jako celku se zlepší.
Před mnoha lety slyšel Jonathan, autor tohoto článku, Vana Jacobsona prohlásit, že algoritmus „pomalého startu“ byla jedna z největších chyb, kterou kdy udělal. Jméno algoritmu se odkazuje na techniku zvyšování rychlosti přenosů pomalu, dokud není určena přenosová kapacita spojení. Ostatní ale uviděli „pomalého“ a stěžovali si, že nechtějí, aby jejich spojení byla pomalá. Faktu, že díky „pomalému startu“ se síť zrychlila, si nevšimli. Jeden by se mohl ptát sám sebe, jestli mechanismus „pomalé práce“ Davida Howella – začleněný do 2.6.30 – narazí na podobné problémy; žádný vývojář nechce, aby věci běžely pomalu. To ale, stejně jako u pomalého startu, není cílem.
Pomalá práce je implementace fondu vláken [thread pool] – dalšího fondu vláken, dalo by se říci. Jádro již má pracovní fronty [workqueue] a infrastrukturu pro asynchronní volání funkcí; modul distribuovaného úložiště (DST) přidaný do 2.6.30 do stromu -staging v sobě také skrývá fond vláken. Každý z těchto fondů je zaměřen na jinou sadu uživatelů. Pracovní fronty poskytují vlákna samostatně pro jednotlivá CPU dedikovaná specifickým subsystémům, zatímco asynchronní volání funkcí je optimalizováno pro specifické řazení úloh. Pomalá práce vypadá spíše jako nástroj pro "dávkové zpracování úloh", který mohou využít jaderné subsystémy ke spuštění úloh, od kterých se očekává, že jejich zpracování spotřebuje větší množství času.
Jaderný subsystém, který chce spustit pomalou úlohu, musí nejprve deklarovat svůj záměr kódu pomalé práce:
#include <linux/slow-work.h> int slow_work_register_user(void);
Volání slow_work_register_user() zajišťuje, že fond vláken bude nastaven a připraven k práci – než se registruje první uživatel, nejsou vytvořena žádná vlákna. Návratová hodnota je buď nula (úspěch) nebo obvyklý záporný chybový kód.
Skutečná úloha pomalé práce vyžaduje vytvoření dvou struktur:
struct slow_work;
struct slow_work_ops {
int (*get_ref)(struct slow_work *work);
void (*put_ref)(struct slow_work *work);
void (*execute)(struct slow_work *work);
};
Struktura slow_work je vytvářena volajícím, ale jinak je neprůhledná. Skutečná práce se provádí ve struktuře slow_works_ops vytvářené odděleně. Funkci execute() volá kód pomalé práce k vykonání daného úkolu. Předtím se ale volá get_ref(), aby se získala reference na strukturu slow_work. Jakmile se práce dokončí, volání put_ref() tuto referenci vrátí. Položky pomalé práce se mohou nějaký čas poté, co byly předány, ještě potulovat po okolí, takže počítání odkazů je nutné, aby se zajistilo, že budou uvolněny ve správný čas. Implementace funkcí get_ref() a put_ref() není volitelná.
Prakticky jaderný kód využívající pomalou práci vytvoří svou vlastní strukturu, která bude obsahovat strukturu slow_work a nějaký druh primitiva pro počítání odkazů. Struktura slow_work() musí být inicializována jedním z následujících:
void slow_work_init(struct slow_work *work, const struct slow_work_ops *ops); void vslow_work_init(struct slow_work *work, const struct slow_work_ops *ops);
Rozdíl mezi těmito dvěma spočívá v tom, že vslow_work_init() úkol identifikuje jako „velmi pomalou práci“, od které se očekává, že poběží (nebo bude spát) významné množství času. Dokumentace naznačuje, že zápis do souboru může být „pomalá práce“, zatímco „velmi pomalá práce“ může být sekvence vyhledávání souborů, jejich vytváření a operací mkdir(). Kód pomalé práce upřednostňuje „velmi pomalou práci“ nad pouze pomalou, ale jenom do bodu, kdy využívá 50 % (výchozí nastavení) dostupných vláken. Jakmile běží maximální počet velmi pomalých úloh, vykonají se pouze úkoly „pomalé práce“.
Skutečné spuštění úlohy pomalé práce se provede voláním:
int slow_work_enqueue(struct slow_work *work);
Tato funkce naplánuje úlohu k běhu. Uspěje, pokud neselže s ní spojená funkce get_ref(), v takovém případě je vráceno -EAGAIN.
Úlohy pomalé práce lze naplánovat několikrát, ale neexistuje žádný čítač, takže úloha naplánovaná několikrát před svým spuštěním proběhne pouze jednou. Úloha, která je naplánována, když běží, je opravdu vložena zpět do fronty pro pozdější opětovné spuštění. Je garantováno, že stejná úloha nepoběží simultánně na několika CPU.
Není žádný způsob, jak z fronty odstranit naplánované úlohy, a není žádný způsob (zabudovaný do mechanismu pomalé práce), kterým by bylo možné čekat na dokončení těchto úloh. Funkci „vyčkej na dokončení“ může zajisté vytvořit volající, pokud ji potřebuje. Obecný předpoklad nicméně je, že položky pomalé práce mohou přetrvávat neomezeně dlouho. Dokud existují úlohy s nenulovým počtem odkazů, všechny zdroje, na kterých závisí, musí zůstat dostupné.
V /proc/sys/kernel/slow-work jsou tři parametry, kterými lze řídit pomalou práci: min-threads (minimální velikost fondu), max-threads (maximální velikost) a vslow-percentage (maximální procento dostupných vláken, které lze použít pro „velmi pomalé“ úlohy). Výchozí nastavení je mezi dvěma a čtyřmi vlákny, z nichž 50 % může spouštět „velmi pomalé“ úlohy.
Jediný uživatel pomalé práce v jádře 2.6.30 je cachovací souborový systém FS-Cache. Funkce fondu vláken je nicméně zjevně zapotřebí, takže nebude překvapivé, když se v budoucích vydáních objeví další uživatelé. Co by bylo více překvapující (nicméně žádané) by byla konzolidace implementací fondu vláken v budoucím vývojovém cyklu.
Originál tohoto článku pro lwn.net napsal Goldwyn Rodrigues
Základem vysoké dostupnosti jsou tři R: redundance, redundance a redundance. Nicméně na typické sestavě vytvořené z běžného hardwaru není možné dosáhnout redundance nad určitý limit tak, aby se počet devítek vaší dostupnosti (tj. 99,999 %) zvýšil. Vezměme jednoduchý příklad: iSCSI server s clusterovými uzly používající distribuovaný systém, jako je GFS2 nebo OCFS2. I s redundantním napájením a datovými kanály na úložném iSCSI serveru je zde bod selhání: úložiště.
Patch distribuovaného replikovaného blokového zařízení [distributed replicated block device, DRBD] vyvinutý firmou Linbit zavádí síťové duplikované blokové úložiště se synchronní replikací dat. Jestliže jeden z úložných uzlů v replikovaném prostředí selže, systém má další blokové zařízení, na které se může spolehnout a bezpečně na něj přepnout. V krátkosti to lze považovat z implementaci RAID1 zrcadlení používajícího kombinaci místního disku a vzdáleného uzlu, ale s lepší integrací s clusterovým softwarem, jako je heartbeat, a efektivní resynchronizací se schopností vyměňovat bitmapy špinavých stránek a identifikátorů generace dat. DRBD v současnosti funguje s pouze dvouuzlovými clustery, ale lze použít hybridní verzi, se kterou lze tento limit rozšířit. Když jsou oba uzly aktivní, zápisy se replikují a posílají jak na lokální disk, tak na druhý uzel. Z důvodů efektivity se čte z lokálního disku.
Úroveň párování dat záleží na zvoleném protokolu:
Protokol A: Zápis se považuje za dokončený, jakmile se dokončí zápis na lokální disk a do odesílací fronty se vložil datový paket pro protějšky. V případě selhání uzlu může dojít ke ztrátě dat, protože data zapisovaná do vzdáleného uzlu mohou stále být v odesílací frontě. Data na záložním uzlu jsou nicméně konzistentní, ale neaktuální. Toto se obvykle používá pro geograficky oddělené uzly.
Protokol B: Zápisy do primárního uzlu se považují za kompletní, jakmile se dokončí zápis na lokální disk a replikační paket dorazil na uzel – protějšek. Ke ztrátě dat může dojít v případě simultánního selhání na obou stranách, protože data na cestě nemusela být uložena na disk.
Protokol C: Zápisy se považují za kompletní pouze poté, co místní i vzdálený disk hlásí, že zápisy jsou kompletní. Nehrozí zde ztráta dat, takže pro clusterované uzly je to populární schéma, nicméně propustnost I/O závisí na propustnosti sítě.
DRBD klasifikuje clusterové uzly jako "primární" nebo "sekundární". Primární uzly mohou zahájit modifikace nebo zápisy, zatímco sekundární uzly ne. To znamená, že sekundární DRBD uzel neposkytuje žádný přístup a nelze ho připojit. Z důvodů koherence cache je zakázán i přístup pouze pro čtení. Sekundární uzel je přítomen hlavně k tomu, aby sloužil jako záložní zařízení v případě chyby. V závislosti na konfiguraci sítě se sekundární uzel může stát primárním. Přiřazování rolí provádí software pro správu clusteru.
Jsou dva způsoby, jakými lze uzel označit jako primární:
Samostatný primární: Jako primární je označen pouze jeden člen clusteru. Vzhledem k tomu, že pouze jeden člen manipuluje daty, je tento režim užitečný pro souborové systémy jako ext3 či XFS.
Dvojitý primární: Oba uzly mohou být primární a je jim umožněno modifikovat data. To se typicky používá s clusterovými souborovými systémy, jako je ocfs2. DRBD v současném vydání může podporovat maximálně dva primární uzly v základním clusteru.
Aby bylo možné se vyhnout komplexním problémům návrhu a deadlockům, je část komunikace mezi uzly obsluhována vlákny. Tato vlákna používaná pro komunikaci jsou:
drbd_receiver: obsluhuje příchozí pakety. Na sekundárním uzlu alokuje buffery, přijímá bloky dat a vysílá požadavky na zápis na lokální disk. Pokud obdrží zapisovací bariéru, spí, dokud nejsou všechny probíhající požadavky na zápis dokončeny.
drbd_sender: Vysílající vlákno pro datové bloky reagující na požadavky čtení. Aby se předešlo distribuovaným deadlockům, probíhá tato činnost v jiném vlákně než drbd_receiver. Pokud probíhá proces resynchronizace, jeho pakety jsou generovány tímto vláknem.
drbd_asender: Vysílání potvrzení. Ovladače pevných disků jsou o dokončení požadavku informovány přerušením. Vysílání dat přes síť v rutině zpětně volané pro obsluhu přerušení by mohlo obsluhu blokovat, obsluha přerušení tedy vloží paket do fronty, odkud si ho toto vlákno vybere a pošle přes síť.
DRBD potřebuje malou rezervní oblast pro metadata, aby mohlo řešit operace po selhání (jako je například resynchronizace) efektivně. Tuto oblast lze konfigurovat buď na odděleném zařízení (externí metadata), nebo na blokovém zařízení (interní metadata) DRBD. Metadata drží s ohledem na disk, včetně logu aktivity a bitmapě špinavých stránek (popsáno níže.)
Jestliže sekundární uzel odumře, systém jako celek to neovlivní, protože sekundární uzel neiniciuje zápisy. Jestliže selhal primární uzel, data k zapsání na disk, pro která nebyla přijata potvrzení, se mohou ztratit. Aby se tomu vyhnulo, udržuje DRBD "log aktivity"; rezervovanou oblast na lokálním disku, která obsahuje informace o operacích zápisu, jež nebyly dokončeny. Data uložená v jeho rozsazích [extents] jsou udržována v seznamu typu nejdéle nepoužité [least recently used, LRU]. Každá změna v logu aktivity způsobí aktualizaci metadat (zápis jediného sektoru). Velikost logu aktivity je nastavena uživatelem; určuje zde podíl mezi minimalizací aktualizací metadat a času resynchronizace dat po pádu primárního uzlu.
DRBD udržuje "bitmapu špinavých stránek" pro případ, že musí běžet bez uzlu – protějšku nebo bez lokálního disku. Popisuje stránky, které místní uzel zašpinil. Zápisy do bitmapy jsou minimalizovány logem aktivity. Pokaždé, když je rozsah odstraněn z logu aktivity, část bitmapy s ním spojená, která již logem není pokryta, je zapsána na disk. Bitmapy špinavých stránek se posílají přes síť, aby se sdělilo, které stránky jsou špinavé, pokud by byla nutná resynchronizace. Bitmapy jsou před odesláním na síť komprimovány (použitím run-length kódování), aby se omezila režie sítě. Vzhledem k tomu, že je většina map rozptýlená, ukazuje se, že je to poměrně efektivní.
DRBD synchronizuje data, jakmile se spadlý uzel zaktivuje nebo v reakci na nekonzistence způsobené přerušeným spojením. Synchronizace se provádí v lineárním pořadí podle posunu [offset] na disku ve stejném rozvržení disku, jako má konzistentní uzel. Tempo synchronizace lze nakonfigurovat parametrem rate v konfiguračním souboru DRBD.
V případě chyb lokálního disku si systém může vybrat z následujících tří způsobů řešení v závislosti na konfiguraci:
odpojení [detach]: Odpojí uzel od zařízení a pokračuje v bezdiskovém režimu. V této situaci se zařízení na uzlu – protějšku stává hlavním diskem. Pro vysokou dostupnost je toto doporučená konfigurace.
pass_on [předání]: Předá chybu vyšším vrstvám na primárním uzlu. Chyba disku se ignoruje, ale loguje, pokud je uzel sekundární.
call-local-io-error: Zavolá skript. Tento režim lze využít k přepnutí na "zdravý" uzel a automaticky přesunout označení primární na jiný uzel.
V případě dvojité primární konfigurace mohou oba uzly zapsat do stejného sektoru na disku, následkem čehož data nebudou konzistentní. U zápisů na různé offsety není potřeba žádná synchronizace. Aby se odstranily problémy s nekonzistencí,jsou datové pakety pro síť sekvenčně číslovány, aby se určilo pořadí zápisů. Je zde nicméně krajní případ problémů s nekonzistencí, kterým může systém trpět:
Simultánní zápisy oběma uzly naráz. V takové situaci se zápisy jednoho uzlu zahazují. Jeden z primárních uzlů je označen příznakem „zahodit-souběžné-zápisy“ [discard-concurrent-writed], který způsobuje, že jsou požadavky na zápis z druhého uzlu zahazovány, pokud se detekují souběžné zápisy. Uzel s tímto příznakem posílá druhému uzlu „discard ACK“, kterým ho informuje o tom, že byl zápis zahozen. Druhý uzel, když přijme „discard ACK“, zapíše data z prvního uzlu, aby byly disky konzistentní.
Lokální požadavky, zatímco jsou vzdálené požadavky na cestě. To se může stát, pokud latence disku překročí latenci sítě. Lokální uzel zapíše do daného bloku, přičemž vyšle zápisovou operaci na druhý uzel. Vzdálený uzel poté operaci potvrdí a vyšle nový zápis na stejný blok – to vše předtím, než se lokální zápis dokončí. V tomto případě lokální uzel pozastaví nový požadavek na zápis do doby, než se dokončí lokální zápisy.
Vzdálené požadavky, zatímco stále probíhají lokální požadavky: K této situaci dojde, pokud síť změní pořadí paketů, takže vzdálený zápis do daného bloku přijde před potvrzením předchozího, lokálně generovaného zápisu. Přijímající uzel opět jednoduše nová data pozdrží, dokud není přijato ACK.
DRBD není jediná implementace distribuovaného úložiště ve vývoji. Implementace distribuovaného úložiště [distributed storage, DST], kterou přispěl Jevgenij Poljakov a která byla přijata do stromu staging, používá jiný přístup. DRBD je omezeno na clustery z 2 aktivních uzlů, zatímco DST může mít větší počet uzlů. DST funguje s klient-server modelem, kde úložiště je server, zatímco DRBD je založeno na principu protějšek-protějšek a navrženo pro vysokou dostupnost v porovnání s distribuovaným úložištěm. DST je na druhou stranu navrženo pro akumulující ukládání, kde lze úložné uzly přidávat podle potřeby. DST umožňuje připojování modulů, kterými akceptuje různé algoritmy pro mapování úložných uzlů do kumulativního úložiště. Zvolený algoritmus může být zrcadlení, které by poskytovalo stejné základní schopnosti replikovaného úložiště jako DRBD.
Kód DRBD je spravován v gitovém repozitáři na git://git.drbd.org/linux-2.6-drbd.git ve větvi drbd. Obsahuje menší komentáře z revizí zaslané na LKML, které byly přidány poté, co Philipp Reisner sadu patchů vydal. Další informace vizte v několika PDF dokumentech zmíněných v zaslání DRBD patchů.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.