Open source RDP (Remote Desktop Protocol) server xrdp (Wikipedie) byl vydán ve verzi 0.10.0. Z novinek je vypíchnuta podpora GFX (Graphic Pipeline Extension). Nová větev řeší také několik bezpečnostních chyb.
Rocky Linux byl vydán v nové stabilní verzi 9.4. Přehled novinek v poznámkách k vydání.
Dellu byla odcizena databáze zákazníků (jméno, adresa, seznam zakoupených produktů) [Customer Care, Bleeping Computer].
V lednu byl otevřen editor kódů Zed od autorů editoru Atom a Tree-sitter. Tenkrát běžel pouze na macOS. Byl napevno svázán s Metalem. Situace se ale postupně mění. V aktuálním příspěvku Kdy Zed na Linuxu? na blogu Zedu vývojáři popisují aktuální stav. Blíží se alfa verze.
O víkendu 11. a 12. května lze navštívit Maker Faire Prague, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Byl vydán Fedora Asahi Remix 40, tj. linuxová distribuce pro Apple Silicon vycházející z Fedora Linuxu 40.
Představena byla služba Raspberry Pi Connect usnadňující vzdálený grafický přístup k vašim Raspberry Pi z webového prohlížeče. Odkudkoli. Zdarma. Zatím v beta verzi. Detaily v dokumentaci.
Byla vydána verze R14.1.2 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5). Přehled novinek v poznámkách k vydání, podrobnosti v seznamu změn.
Dnešním dnem lze již také v Česku nakupovat na Google Store (telefony a sluchátka Google Pixel).
Apple představil (keynote) iPad Pro s čipem Apple M4, předělaný iPad Air ve dvou velikostech a nový Apple Pencil Pro.
Současné vývojové jádro je 2.6.32-rc3, které Linus vydal 4. října. Všimněte si, že nebylo žádné -rc2; tato verze byla přeskočena, aby se zabránilo zmatkům způsobených překlepem u čísla verze -rc1.
Další pro uživatele viditelná změna: Souborové systémy VFAT jsou nyní připojovány s shortname=mixed místo shortname=lower, což brání převodu všech písmen na malá, když se souborové systémy kopírují. Za povšimnutí také stojí, že Btrfs již konečně umí zvládnout situace, kdy se zaplní disk; měli bychom najít něco jiného, co bude Chrise Masona trápit. Zkrácený changelog je v oznámení, kompletní changelog obsahuje všechny detaily.
Současné stabilní jádro je 2.6.31.3 vydané 7. října. Obsahuje jedinou opravu problému v TTY, který postihoval mnoho uživatelů.
Předtím bylo 5. října vydáno 2.6.31.2. Je to velké stabilní vydání; z oznámení revizí:
Očekávejme tedy větší než je obvyklé množství změn na stabilní aktualizaci.
2.6.27.36 a 2.6.30.9 byly také vydány 5. října; obsahují o něco menší sady oprav.
-- z Z poznámek o Netconf 2009
-- Jon Masters; kdo říká, že podcasty jsou nudné?
-- Alan Cox
„Netconf 2009“ byl summit pouze pro pozvané vývojáře síťování, který se konal před LinuxCon. Poznámky ze dvou dnu diskuzí byly nyní zaslány na stránku Netconf 2009. Mezi probíranými tématy je omezení počtu přerušení přenosů, bridgování, síťování ve více frontách, bezdrátové síťování a další.
Jedna ze změn, která se protáhla do vydání 2.6.32-rc3, bylo přidání režimu „nízké latence“ do I/O plánovače CFQ. Plánovač se běžně pokouší zpozdit mnoho nových I/O požadavků o krátkou dobu s tím, že by mohlo být možné spojit je s dalšími požadavky, které přijdou těsně poté. Toto chování minimalizuje posun hlaviček na disku a maximalizuje velikost I/O požadavku, takže je zjevně dobré pro propustnost. Zanášení zpoždění ale může být problém, pokud je hlavním cílem dokončit operaci tak rychle, jak je to možné.
Nový režim (původně nazvaný „desktopový“ před přejmenováním na „nízká latence“) je ve výchozím nastavení zapnut; lze ho přepínat nastavením atributu iosched/low_latency spojeným s každým blokovým zařízením v sysfs. Když je nastaven, nedochází k některým zpožděním u „synchronních operací“ (obecně čtení). Výsledkem by mělo být I/O s rychlejší odezvou a, jak jeden doufá, šťastnější uživatelé.
Poznámka: Popis této změny vizte v komentářích na LWN, kde je, ehm, přesnější. Autor článku vinu svaluje na smrtící chřipku, kterou mu domů přinesly děti.
Patche začleněné do hlavní řady si s sebou nesou mnoho značek, které popisují, kdo je napsal, kdo je revidoval atd. Jistý commit začleněný do 2.6.32 nicméně obsahuje relativně neobvyklou značku:
NACKed-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Začlenění tohoto patche vyvolalo několik stížností: Jak to, že se dostal do hlavní řady, když s ním má jeden z hlavních vývojářů problém?
Příběh je asi takový: ACPI poskytuje mechanismus, kterým může požádat systém, aby uvedl procesory do klidu v případě nouze; mezi takové případy mohou patřit problémy s napájením nebo přehřívající se systém. Lidé od ACPI původně navrhovali přidat do plánovače nějaké hacky, které by tuto funkci implementovaly, tyto změny se nicméně příliš nelíbily; to byl patch, který Peter Zijlstra rovnou zablokoval.
Shaohua Li se tedy vrátil k rýsovacímu prknu a implementoval tuto funkci jako ovladač. Když ACPI hardware vyhlásí červený poplach, ovladač vytvoří realtimové vlákno o nejvyšší prioritě a spustí ho na CPU, které má být uvedeno do klidu. Když vlákno „běží“, jednoduše CPU na chvíli přepne do stavu relativně hlubokého spánku. Když nouze pomine, vlákno zmizí a obnoví se normální běh. Je to tak trochu hack, ale svoji práci udělá a na rozdíl od odpojení CPU za běhu není tolik destruktivní vůči stavu systému.
Správnou opravou by bylo vylepšit plánovač (správným způsobem), aby tuto funkcionalitu poskytoval sám. To by ale téměř určitě vyžadovalo zásah skutečného hackera plánovače a ti se ještě nedostali k tomu, aby problém řešili. V hlavní řadě je tedy prozatím „ovladač“ ACPI. A tak to může zůstat; Linus řekl:
Tak si věci stojí. Ovladač je stále neoblíben, ale také nebude příliš používán, lze ho nahradit lepším mechanismem, pokud budou správní lidé chtít, a mezitím může některým uživatelům vyřešit skutečné problémy.
Chybné pojmenování 2.6.32-rc1 v makefile mohlo být zdrojem určitého zmatku, ale přeskočení -rc2 zabránilo tomu nejhoršímu. Zdá se ale, že jsou zmatky ohledně číslování na jiných místech, což vede k tlaku ke změně, kterou Linus ani omylem nehodlá udělat.
V reakci na oznámení 2.6.32-rc3 Len Brown poznamenal, že co se čísla verze týče, v podstatě není rozdíl mezi (řekněme) 2.6.31 a jádrem staženým na konci začleňovacího okna 2.6.32, přestože tato dvě jádra se od sebe významně liší. Len měl jednoduchý požadavek:
Další teto požadavek podpořili, ale Linus dal jasně najevo, že ho tento nápad nezajímá:
Jaký má tedy nápad mít -rc0 háček? Ukazuje se, že jich pár je, přičemž mezi jeden z nich patří to, že systém pro překlad jádra již jeden flexibilnější mechanismus obsahuje. Pokud je nastavena konfigurační volba LOCALVERSION_AUTO, specifičtějším způsobem je nastavena dodatečná informace o verzi. Autor článku, který již nějakou dobu nebyl doma dost dlouho na to, aby na svůj desktop nainstaloval nové jádro, v současnosti používá jádro, které jako svou verzi hlásí:
2.6.31-rc5-00002-g3ce001e
Ta říká, že takové jádro je k nalezení v gitu u ID commitu g3ce001e. 00002 znamená, že to je dva commity po 2.6.31-rc5. Tato verze ukazuje přesně, jaké jádro běží, takovým způsobem, jak by to jednoduché upravování Makefile nedokázalo. I kdyby -rc0 opravdu něco značilo, ani tak by to nesdělovalo, jaké jádro běží.
A je to ještě horší, obzvlášť když vývojáři dělí půlením [bisect] a hledají tak chyby v jádře. Vezměme tento příklad: Dva commity po 2.6.31-rc5 v jádře autora článku jsou pár patchů odstraňujících BKL, na kterých se pracovalo a které nestihly začleňovací okno 2.6.32. Za předpokladu, že se dostanou do 2.6.33, bude (zjednodušená) historie revizí v gitu vypadat nějak takto:
![[Nákres revizí]](http://lwn.net/images/ns/kernel/git-revisions.png)
Vývojář, který se bude půlením pokoušet najít problém v 2.6.33-rc1, může snadno skončit na commitu g3ce001e; tento commit rozhodně nemůže být příčinou problému. Pokud by se vývojář jádra v tu chvíli podíval na verzi jádra, neuvidí 2.6.33-rc0 (i kdyby Linus změnu udělal) a ani 2.6.32 – verze bude 2.6.31-rc5, což je verze, na které je tento commit založen. V éře gitu není vývoj jádra přímočará záležitost.
Z toho vyplývá, že každý, kdo bude, co se verze jádra týče, záviset na Makefile, bude pravděpodobně dřív či později zmaten. Samozřejmě je zde jedna důležitá výjimka: Toto číslo má smysl pouze pro vydání, které reprezentuje. V jakémkoliv jiném případě je to nespolehlivá informace.
To nemění fakt, že jsou lidé stále zmateni, když spustí jádro, které se identifikuje jako 2.6.x, ale ve skutečnosti je blíže 2.6.x+1. Zdá se tedy pravděpodobné, že se udělá pár věcí, aby se tomu zabránilo. Jednou z nich bude, že volba LOCALVERSION_AUTO bude ve výchozím nastavení zapnuta a možná ji bude obtížné vypnout. Další věcí je přidání nějakých vychytávek do překladového systému, které se pokusí zjistit, jestli se překládané jádro liší od toho, které bylo označeno oficiálním číslem verze. V takovém případě bude k číslu verze jednoduše připojeno „+“. Jádro stažené uprostřed začleňovacího okna 2.6.33 se tedy bude identifikovat jako 2.6.32+.
Linusovi se tato poslední možnost příliš nelíbí (zdá se mu, že se ztrácí mnoho informací, které poskytuje kompletní volba LOCALVERSION_AUTO), ale také se mu „neprotiví“. Dokonce se mu podařilo neprotivit si tento nápad tak, že dal dohromady patch, který ho implementuje. V době psaní článku nebyl začleněn; stále se diskutuje o možných změnách formátu LOCALVERSION_AUTO. Zdá se ale pravděpodobné, že něco podobného bude začleněno během začleňovacího okna 2.6.33, pokud ne dřív.
„Fond vláken“ [thread pool] je obecná skupina procesů, které lze zavolat, aby někdy v budoucnu provedly práci. Jádru implementace fondů vláken rozhodně nechybí; ve skutečnosti je možností víc, než by se jednomu mohlo líbit. Na výběr je mezi pracovními frontami [workqueues], mechanismem pomalé práce a asynchronním voláním funkcí – a to nezmiňujeme různé soukromé implementace, které lze najít na různých místech. Dlouho panuje názor, že by bylo lepší mít jenom jeden mechanismus pro fond vláken, ale zatím se nikomu nepodařilo dát dohromady jednu implementaci, která by se líbila všem.
Z mechanismů zmíněných výše se nejvíce používají pracovní fronty. Pracovní fronty kódu umožňují snadno odložit nějakou práci tak, aby byla vykonána v kontextu procesu někdy v budoucnu, ale nejsou bezproblémové. Existuje sdílená pracovní fronta, kterou mohou používat všichni, ale jeden dlouhodobě běžící úkol může ostatním způsobit nekonečná zpoždění, takže ji využívá jenom pár vývojářů. Místo toho se jádro zaplnilo pracovními frontami specifickými pro jednotlivé subsystémy a každá z nich přispívá k nadbytku jaderných vláken, která na současných systémech běží. Vlákna pracovních front mezi sebou soupeří o CPU, což způsobuje častější přepínání kontextu, než je nutné. Je až příliš jednoduché vytvořit souběh [deadlock] pracovních front tak, že jedna úloha závisí na práci, kterou provádí jiní. Shrnuto – pracovní fronty – přestože byly již několikrát významně přepsány – potřebují nepatrně vyladit.
Toho se ujal Tejun Heo a poskytl patche pracovních front řízených souběžností [Concurrency-managed workqueues]. Tato série o devatenácti částech významně přepracovává kód pracovních front a řeší současné nedostatky tohoto subsystému. Je v ní vidět i snaha o nahrazení jiných implementací fondů vláken v jádře, tato práce je však ponechávána na později.
Se současnými pracovními frontami jsou spojena dedikovaná vlákna – v některých případech jediné vlákno, jedno vlákno za každé CPU v jiných. Nové pracovní fronty toto ruší; neexistují žádná vlákna určená pro specifickou pracovní frontu. Místo toho je v systému globální fond vláken připojený ke každému CPU. Když je do fronty zařazena položka ke zpracování, je ve správný čas (určený kódem pracovních front) předána jednomu z globálních vláken. Jeden zajímavý důsledek této změny je, že úlohy zařazené do stejné pracovní fronty na stejném CPU mohou nyní běžet souběžně – to se u současných pracovních front nestane.
Jedna z klíčových vlastností nového kódu je možnost řídit souběžnost obecně. V jistém smyslu jsou souběžně zpracovávány všechny úlohy v pracovní frontě. Je samozřejmé, že dělat to skutečně takto by vedlo na ubohé výsledky; úlohy by jednoduše mezi sebou soupeřily, což by vedlo k častějšímu přepínání kontextu, horšímu chování cache a obecně k horší výkonnosti. Ve skutečnosti je potřeba nechat běžet v jedné frontě právě jednu úlohu (vyhnout se soupeření), ale okamžitě přepnout na jinou, pokud úloha z nějakého důvodu začne blokovat (vyhnout se nicnedělajícímu procesoru). Udělat to správně vyžaduje, aby se ze správce pracovní fronty stal určitý druh plánovače pro zvláštní účely.
A přesně tak to Tejun implementoval. Patch pracovních front přidává novou třídu plánovače, která se chová jako běžná třída férového plánovače. Ta přidává několik háčků, které zavolají kód pracovních front, kdykoliv úloha běžící v této třídě přejde mezi blokovaným [blocked] a spustitelným [runnable] stavem. Když je do fronty zadán první úkol, je vytvořeno vlákno běžící pod plánovačem pracovní fronty, které daný úkol začne zpracovávat. Dokud úloha běží, ostatní čekají. Jakmile ale běžící úloha z nějakého důvodu začne blokovat kvůli nějakému zdroji, plánovač upozorní kód pracovních front, načež se vytvoří další vlákno, které nechá běžet další úlohu. Správce pracovní fronty vytvoří tolik vláken, kolik je potřeba (do limitu), aby CPU bylo zaměstnáno, ale snaží se udržovat stav, kdy běží jenom jedna úloha.
V Tejunově patchi je také koncept „záchranných“ vláken. V systému, jehož zdroje jsou hodně omezeny, nemusí být možné vytvořit nové pracovní vlákno. Všechna existující vlákna ale mohou čekat na výsledky jiných úloh, které ještě nebyly vykonány – a v takovém případě všechno zamrzne. Aby se problém vyřešil, udržují se zvláštní „záchranná“ vlákna; pokud po určitý čas selhávají pokusy vytvořit nová pracovní vlákna, povolají se záchranná vlákna, aby vykonávala úlohy a při troše štěstí zátaras zlikvidovala.
Zajímavé je řešení odpojování a připojování CPU za běhu. Když je CPU vypínáno, systém musí z tohoto CPU co nejrychleji odklidit všechnu svou práci. Za tímto účelem správce pracovní fronty reaguje na upozornění o odstavení CPU tím, že vytváří speciálního „poručnického“ správce na nějakém CPU, které zůstává aktivní. Poručník přebírá zodpovědnost za pracovní fronty běžící na CPU odsouzenému k záhubě, vykonává úlohy, dokud všechny nezmizí, načež lze frontu vypnout. Odstavované CPU se přitom může vypnout hned a nečekat přitom, až se úlohy dokončí.
Tyto patche byly obecně přijaty dobře, ale bylo vyjádřeno několik obav. Největší stížnost souvisela s plánovací třídou pro zvláštní účely. Háčky byly popsány jako (1) ne zcela vztahující se k plánovači a (2) potenciálně zajímavé mimo kód pracovních front. Linus například naznačil, že tento druh háčku by mohl být použit k implementování sémantiky velkého jaderného zámku [big kernel lock] s tím, že zámek je uvolněn, když se proces uspí, a znovuzískán, když se probudí. Plánovací třída pravděpodobně v příští verzi patche zmizí; uvidíme, čím bude nahrazena.
Jedním z návrhů bylo použít háčky pro upozorňování na preempci, které již v jádře jsou. Tyto notifikátory by nově musely být povinné a byla by zapotřebí nová zpětná volání [callback]. Další možností by bylo vzdát se nevyhnutelné budoucnosti, ve které čítače události výkonnosti ovládnou celé jádro. Sledovací body událostí jsou navrženy tak, aby poskytly zpětná volání pro určitá místa v jádře; pro většinu zajímavých událostí plánovače již nějaké existují. Jejich použití v tomto kontextu by z větší části znamenalo pouze upravit mechanismus událostí výkonnosti tak, aby tuto úlohu zvládal efektivně.
Andrew Morton měl obavy z toho, že nový kód znemožňuje specifickému uživateli pracovní fronty modifikovat své úlohy – řekněme měnit jejich prioritu nebo nechat je běžet pod jiným UID. Ukazuje se, že zatím bylo takto modifikováno jenom několik pracovních front. Pracovní fronta používaná ve stop_machine() svá vlákna přesouvá do plánovací třídy reálného času, což jim umožňuje zabrat si procesor, když potřebují; Tejun jednoduše tuto pracovní frontu nahradil sadou dedikovaných jaderných vláken. Kód ACPI vlákna pracovní fronty poutá k CPU 0, protože některé operace systém shodí v případě, že běží kdekoliv jinde; tento případ je snadno řešitelný existující funkcí schedule_work_on(). Zdá se tedy, že přinejmenším nyní není potřeba mít jiná než výchozí pracovní vlákna.
Jednou zbývající záležitostí je to, že některé subsystémy používají jednovláknové pracovní fronty jako synchronizační mechanismus; očekávají, že se úlohy dokončí v takovém pořadí, v jakém byly zadány. Globální fondy vláken toto chování mění; Tejun ještě neřekl, jak tento problém vyřeší.
Téměř určitě vyřešen bude, společně s ostatními obavami. David Howells, tvůrce subsystému pomalé práce, si myslí, že nové pracovní fronty mohou být dobrou náhradou. Zdá se tedy, že tato změna pravděpodobně bude přijata, možná již v 2.6.33. Potom bychom konečně mohli mít v jádře jediný fond vláken.
Originál tohoto článku pro LWN.net napsal Neil Brown.
Po mnoho let měl Linux dva oddělené subsystémy pro správu nepřímých blokových zařízení: Virtuálních úložných zařízení, která různými způsoby kombinují úložiště z jednoho nebo více dalších zařízení tak, aby poskytla větší výkonnost, flexibilitu, kapacitu nebo redundanci. Tyto dva jsou DM (což je zkratka pro Device Mapper) a MD (zkratka pro Multiple Devices (násobné zařízení) nebo metadisk, obrácené pořadí písmen je čistá náhoda).
Téměř po stejnou dobu se objevují návrhy, že mít dva frameworky je zbytečnost a že by měly být sjednoceny. Nicméně nedošlo k žádné viditelné a významné snaze o sjednocení a ty pokusy, ke kterým došlo, nevedly k žádnému trvajícímu úspěchu. K největšímu sjednocení došlo tím, že oba subsystémy nyní mají ve stromě zdrojových kódů jádra stejný adresář (drivers/md); to je spíš vnášení zmatku než sjednocení. Oba subsystémy jsou bok po boku vyvíjeny, přičemž oba čas od času získají funkcionalitu, kterou má ten druhý, takže určitým způsobem jsou si podobnější. Podobnost ale není jednota, naopak to spíš zdůrazňuje nedostatek jednoty, protože už to není funkce, co oba dělí, ale pouze forma.
Vysvětlení toho, proč ke sjednocení nikdy nedošlo, by bylo zajímavé cvičení z historie, které by se muselo dotknout osobností zainteresovaných lidí, posunu funkcionality mezi těmito dvěma systémy, které vznikly s jinými cíli, různých pohledů na oba dva ze strany různých členů komunity a technologických rozdílů, které by bylo nutné vyřešit. Vzhledem k tomu, že není historikem, se Neil cítí být kompetentní pouze k tomu, aby okomentoval ten poslední bod. Navíc, protože pouze u tohoto bodu větší porozumění může pomoci sjednocení, pokusí se tento článek odhalit významné technologické záležitosti, které tyto dva udržují oddělené. Konkrétně prozkoumáme slabiny obou infrastruktur. Tam, kde má systém silné stránky, dojde dříve či později k jejich okopírování, což vede k jednotě. Místům, kde má slabiny, se ostatní systematicky vyhýbají, což vytváří překážky.
Abychom poskytli co nejúplnější obraz, nebudeme se zabývat jenom DM a MD. Smyčka [loop], NBD a DRBD poskytují za svou infrastrukturou zaměřenou na jediný účel podobnou funkcionalitu; jejich prozkoumáním zajistíme, že nepřehlédneme žádné důležité problémy nebo potřeby.
Vzhledem k tomu, že Neil je již několik let hlavním vývojářem MD, velí mu čest začít výčtem slabin v tomto systému.
Jedním z ošklivých aspektů je vytváření nového pole. To je spuštěno jednoduše otevřením zvláštního souboru zařízení typicky v /dev. Ve dávných dnech, když jsme měli poměrně statický adresář /dev, se to zdálo být jako rozumný přístup. Bylo jednoduše nutné vytvořit několik záznamů v /dev (md0, md1, md2, …) s odpovídajícím hlavním a vedlejším číslem zařízení v době, kdy byl vytvářen ostatní statický obsah /dev. Když byl poté kterýkoliv z těchto záznamů otevřen, spontánně se vytvořily interní datové struktury, do kterých se vyplnily detaily o zařízení.
S modernějším konceptem dynamického /dev, který odráží fakt, že výčet zařízení připojených k systému se často mění, se nicméně toto uspořádání příliš nevyrovnává. udev, který typicky /dev spravuje, vytváří záznamy pouze o zařízeních, o kterých jádro ví. Dokud tedy jádro nebude věřit, že nějaké md zařízení existuje, nevytvoří se žádný soubor zařízení. A ten nebude existovat, dokud nebude vytvořen a otevřen – klasická Hlava 22.
mdadm, hlavní obslužný nástroj pro MD, tento problém obchází tak, že vytvoří dočasný soubor zařízení, jenom aby ho mohlo otevřít a tím vytvořit zařízení. To funguje docela dobře, ale i tak je to poněkud ošklivé. Interní implementace je obzvláště ošklivá a až relativně nedávno byly uzavřeny souběhy při likvidaci MD zařízení (které může být z uživatelského prostoru kdykoliv vytvořeno znovu), takže MD zařízení nemusí existovat věčně.
S MD úzce souvisí problém, že se blokové zařízení reprezentující pole objeví dřív, než jsou v něm nějaká data. Když tedy udev vytvoří /dev/md0, pokus ho otevřít a číst z něj (například aby se zjistilo, jestli je tam uložen nějaký souborový systém) nenajde žádný obsah. Teprve poté, co jsou do pole připojeny komponenty a je zcela nakonfigurováno, je možné z něj s úspěchem číst.
Tento počáteční stav, kdy zařízení existuje, ale je prázdné, je trochu podobný případu zařízení s vyměnitelným úložištěm a je možné ho řešit podobným způsobem: Mohli bychom pole považovat za úložiště, které se samovolně objeví. V ostatních ohledech se ale MD vyměnitelnému úložišti příliš nepodobá (není možné ho „vysunout“) a obecně by způsobovalo méně zmatků, kdyby se MD zařízení objevilo zcela nakonfigurované, aby více vypadalo jako běžný disk.
Problém, který byl řešen nedávno, je, že MD spravuje metadata polí interně. Jaderný modul ví o rozvržení dat v superbloku a aktualizuje ho podle potřeby. To je snadno implementovatelné, ale těžko rozšiřitelné. Vzhledem k absenci skutečného standardu existuje mnoho rozvržení metadat specifických pro výrobce, které lze všechna využít k popisu stejného druhu pole. Podpora všech by jádro zbytečně zaneřádila a podpora v uživatelském prostoru vyžaduje spolehlivým způsobem přenášet do uživatelského prostoru informace o změnách.
Jak bylo zmíněno, tento problém byl nedávno vyřešen, takže je nyní poměrně bezproblémové spravovat z uživatelského prostoru pro výrobce specifická metadata. Má nicméně smysl to zde poznamenat, protože to byl jeden z problémů, který stál v cestě předchozím pokusům o integraci DM/MD: DM metadata nespravuje vůbec, nechává to na nástrojích v uživatelském prostoru.
Poslední nedostatek MD, který zde bude odhalen, je používání ioctl() a povaha příkazů, kterými jsou MD pole konfigurována a spravována. Používání ioctl() není v linuxové komunitě příliš oblíbené, což má několik důvodů. Jedním z nich je, že strace nedokáže dekódovat nově vytvořená ioctl, takže použití ioctl() může ztěžovat pozorování chování programu. Další je, že je to binární rozhraní (typicky předávající C struktury), takže když je Linux nastaven, aby podporoval několik ABI (například 32bitovou a 64bitovou verzi), je často potřeba přeložit binární strukturu z jednoho ABI do jiného (vizte téměř 3000 řádek v fs/compat_ioctl.c).
V případě MD není ioctl() rozhraní příliš rozšiřitelné. Příkaz pro konfiguraci pole umožňuje specifikovat pouze „úroveň“, „rozvržení“ a „velikost bloku“ [chuck size]. To funguje dobře u RAID0, RAID1 a RAID5, ale už u RAID10 je potřeba do pole „rozvržení“ zakódovat několik hodnot, což je sice efektivní, ale není to elegantní.
V několika minulých letech si MD vypěstovalo oddělené konfigurační rozhraní pomocí sbírky souborů vlastností [attribute files] v sysfs. To je mnohem snáze rozšiřitelné a roste počet vlastností MD, které potřebují rozhraní v sysfs. I zde je nicméně prostor pro zlepšení. Soubory vlastností MD jsou uloženy v podadresáři adresáře blokového zařízení (například /sys/block/md0/md); i když se to zdá přirozené, vztahuje se na to výše zmíněný problém, že předtím, než lze pole nastavit, musí existovat blokové zařízení. Pokud bychom chtěli zpozdit vytvoření blokového zařízení, dokud nebude schopno poskytovat data, museli bychom tyto soubory vlastností uložit do sysfs někam jinam.
DM má dědictví velmi odlišné od MD a i když s MD sdílí některé nedostatky, jiným se vyhýbá.
DM zařízení v /dev nemusí existovat, aby mohlo být vytvořeno. K vytváření zařízení slouží „znakové zařízení“, které přijímá ioctl() příkazy pro DM včetně příkazu pro vytvoření zařízení. Problém s Hlavou 22, kterým trpí MD, není v DM přítomen. Bylo navrženo, že by MD mohlo tento přístup používat také, ale přestože se vyřeší jeden problém, stále zůstává používání ioctl(). Nezdá se, že by mělo velký smysl udělat v subsystému významnou změnu, pokud se výsledek nevyhne všem problémům. Během čekání na perfektní řešení se tedy neudělaly žádné malé krůčky, které by pomohly MD a DM sblížit.
S tím spojená záležitost, že blokové zařízení může existovat předtím, než je nakonfigurováno, je v DM přítomna také, i když oddělení událostí ,vytvoření DM zařízení‘ a ,vytvoření blokového zařízení‘ by v DM bylo mnohem jednodušší. Důvodem pro to je, jak bylo zmíněno, že veškeré nastavování DM se děje přes znakové zařízení, kdežto u MD se musí konfigurovat přímo přes blokové zařízení, které tedy před nastavením musí existovat.
I když DM také používá ioctl() příkazy, což lze považovat za slabinu, vybrané příkazy jsou mnohem snáze rozšiřitelné než ty, které používá MD. ioctl() příkaz, který má nastavit zařízení, jednoduše zahrnuje předání textového řetězce relevantnímu modulu v DM, který následně řetězec interpretuje zcela podle své libovůle. DM tedy není omezen na pole, která byla považována za relevantní, když byl DM poprvé navrhován.
Správa metadat je u DM značně odlišná od MD. V původním návrhu nikdy nebylo potřeba, aby jaderný modul měnil metadata, takže správa metadat byla ponechána výhradně na uživatelském prostoru, kam patří. V nedávné době, kdy se objevilo RAID1 a RAID5 (který je stále ve vývoji), je od jádra vyžadováno synchronně aktualizovat metadata, aby se zaznamenalo selhání zařízení. To vyžaduje určitou úroveň interakce mezi jádrem a uživatelským prostorem, která musela být přidána.
Hlavním problémem návrhu DM je fakt, že má dvě vrstvy. Vrstvu tabulky a vrstvu cíle. Toto nepochybně pochází z původního záměru DM, což byla správa logických svazků [logical volume management, LVM], a tomto záměru vyhovuje poměrně dobře. Toto vrstvení nicméně není nutné a aplikacím, které se LVM netýkají, se jenom plete do cesty.
„Cíl“ je koncept interní pro DM, je to abstrakce, kterou představuje každý modul. Takže dělení na pruhy [striping], raid1, vícecestné ukládání [multipath] atd. představují cíl a tyto cíle lze pomocí tabulky zkombinovat do zařízení.
„Tabulka“ je jednoduše seznam cílů, přičemž každý má svou velikost a posun [offset]. To je analogické k modulu „linear“ v MD nebo k tomu, co je jinde popisováno jako spojení [concatenation]. Cíle jsem jednoduše propojeny tak, aby se vytvořilo jediné větší blokové zařízení.
To je v kontrastu s MD, kde každý modul – například raid0, raid1 a multipath – prezentuje blokové zařízení. Toto blokové zařízení lze použít tak, jak je, nebo ho lze kombinovat s jinými pomocí zvláštního pole do jediného většího blokového zařízení.
Abychom vliv tohoto vrstvení zdůraznili o něco více, řekněme, že máme dvě různá pole vytvořená z několika zařízení. V jednom poli chceme dělit [stripe] data mezi zařízení, v druhém chceme, aby data nejprve zaplnila první zařízení a potom teprve se přešlo k dalšímu. U MD by jediný rozdíl spočíval ve výběru modulu („raid0“ nebo „linear“), který má pole spravovat. U DM by první krok zahrnoval začlenění všech zařízení do jediného cíle „stripe“, načež by se tento cíl jako jediný vložil do tabulky. Druhý krok by potom zahrnoval vytvoření několik cílů „linear“, pro každé zařízení jeden, a jejich následné zkombinování do tabulky s několika záznamy.
Tato interní abstrakce „cíle“ slouží k oddělení a izolaci DM od vrstvy blokových zařízení, což je společná vrstva používaná ostatními virtuálními zařízeními. Dobrým příkladem tohoto oddělení je funkce změny konfigurace za běhu, kterou DM nabízí. Hranice mezi tabulkou a cílem umožňuje DM zachytit nové požadavky ve vrstvě tabulky, což umožní cílové vrstvě požadavky vyčerpat, přejít do klidového stavu a následně potenciálně nahradit všechny cíle jinými předtím, než jsou všechny pozdržené požadavky provedeny.
Bez této interní „cílové“ vrstvy by tuto funkcionalitu bylo nutné implementovat na hranici s kódem ovladačů (tj. v generic_make_request() a bio_endio()). Udělat to by znamenalo víc práce (tj. DM by z tohoto oddělení nemělo prospěch) a bylo by to obecněji užitečné (tj. DM by nebylo tak izolované). Mnoho lidí chtělo mít možnost konvertovat normální zařízení na degradované „pole“ RAID1 nebo povolit podporu více cest na zařízení, aniž by museli nejprve odpojit souborový systém, který je připojen přímo na jedné z cest. Pokud by rekonfigurace za běhu byla podporována v blokové vrstvě, tyto změny by byly možné.
DRBD, distribuované replikované blokové zařízení, je nejsložitější z těch virtuálních blokových zařízení, která se nesnaží poskytnout obecný framework. Zatím není začleněno v hlavní řadě, ale možná ještě bude v 2.6.33.
Konfigurační mechanismus je podobný tomu, který má DM, v mnoha ohledech. Pro vytváření a správu blokových zařízení se používá jediný kanál. Protokol používaný v tomto kanálu je navržen tak, aby byl rozšiřitelný, i když současné definice jsou velmi zaostřené na konkrétní potřeby DRBD (což je pochopitelné), takže jak snadno by ho šlo rozšířit pro jiný druh pole, není zcela jasné.
Zatímco DM používá ioctl() s příkazem v řetězci, který se posílá k tomu určenému znakovému zařízení, DRBD používá paketový binární protokol přenášený přes netlink. V podstatě se jedná o spojení na socketu mezi jaderným modulem a programem pro správu v uživatelském prostoru, které přenáší binární zakódované informace tam a zpět. Pravděpodobně to není ani lepší, ani horší než ioctl(); je to prostě jiné. Vybráno bylo pravděpodobně tak, že z ioctl() mají lidé obecně špatné pocity, které nemají z netlinku. Linusovi se nicméně podle všeho nelíbí ani jedno.
Zdá se, že u DRBD je správa metadat sdílena mezi jádrem a uživatelským prostorem. Metadata, která popisují konkrétní konfiguraci DRBD, jsou vytvořena a interpretována nástroji v uživatelském prostoru a informace, které potřebuje jádro, jsou přeneseny přes netlink. DRBD používá další metadata, kterými popisuje současný stav replikace v systému – informace o tom, které bloky jsou s jistotou bezpečně replikovány a které možná nejsou v jednotlivých replikách z nějakého důvodu konzistentní. Tato metadata (a záznamy o aktivitě [activity log] a bitová mapa) jsou spravována jádrem, pravděpodobně z důvodů týkajících se výkonnosti.
Toto sdílení odpovědnosti dává smysl, protože to umožňuje, aby na výkonnost citlivé části zůstaly v jádře, ale ponechává to dostatek flexibility pro podporu různých formátů metadat. Tento přístup lze ještě vylepšit tím, že by se bitmapy a záznamy o aktivitě přepracovaly na samostatné moduly, které by bylo možné použít pro další virtuální zařízení. DM, MD i DRBD mají velmi podobné mechanismy pro sledování nekonzistencí mezi komponentami; to je pravděpodobně oblast, na které je nejzjevnější, že sdílení by bylo užitečné.
Smyčku [loop] a NBD [síťové blokové zařízení] je vhodné zmínit částečně proto, aby se zdůraznilo, že není nutně zapotřebí mít framework k tomu, aby bylo možné vytvořit virtuální blokové zařízení. I když se u smyčky nezdá, že by se snažila poskytnout framework pro násobnost virtuálních zařízení, i přesto kombinuje tři funkce do jednoho zařízení. Může zajistit, že se běžný soubor tváří jako blokové zařízení, dokáže poskytnout primitivní dělení [partitioning] jiného blokového zařízení a dokáže šifrovat a dešifrovat, aby bylo možné přistupovat k šifrovanému zařízení. Významné je, že všechny tyto funkce byly následně přidány do DM, což zvýrazňuje izolující efekt návrhu DM.
NBD je mnohem jednodušší v tom, že má pouze jednu funkci: Poskytuje takové blokové zařízení, které přesměrovává všechny požadavky do síťového spojení, aby byly obslouženy – obvykle – na jiném hostiteli. Je to pravděpodobně nejpoučnější příklad virtuálního blokového zařízení, které nepotřebuje žádný obalující framework ani infrastrukturu.
Dvě oblasti, kde DM a MD zařízení využívají infrastrukturu, kdežto smyčka a NBD se musí ohánět samy za sebe, jsou vytváření nových zařízení a jejich konfigurace. NBD používá velmi jednoduchý přístup, při inicializaci modulu vytváří předdefinovaný počet zařízení a víc jich neumožňuje. Smyčka je o trochu flexibilnější a k vytváření zařízení, když je otevřen speciální soubor blokového zařízení, používá stejný mechanismus jako MD, z větší části poskytovaný blokovou vrstvou. Neumožňuje tato zařízení smazat, dokud není modul odstraněn, což je obvykle při vypínání. Tato architektura naznačuje, že by těmto ovladačům mohla být nějaká infrastruktura užitečná a že nejlepším místem pro takovou infrastrukturu by možná mohla být bloková vrstva, což by umožňovalo sdílení všemi zařízeními.
Smyčka i NBD pro konfiguraci používají poměrně ad hoc sbírku ioctl() příkazů. Jak jsme již viděli, je to jak běžné, tak problematické. Obě by mohla profitovat ze standardizovanějšího a transparentnějšího mechanismu pro konfiguraci.
Mohlo by být vhodné se na tomto místě zeptat, jestli je vůbec potřeba nějaký subsystém infrastruktury jako DM a MD. Proč se jednoduše nedržet vzoru, který vidíme u smyčky, NBD a DRBD, a nemít oddělené ovladače blokového zařízení pro každý druh virtuálního blokového zařízení? Nejzjevnější důvod je ten, který již neplatí. V době, kdy byly psány DM a MD, byla silná vazba mezi hlavním číslem zařízení a ovladačem blokového zařízení. Každý ovladač potřeboval své hlavní číslo – smyčka je 7, NBD 43, DRBD 147 a MD 9. DM nemá trvale alokované číslo, vybírá si volné, když je modul nahrán, takže obvykle dostane 254 nebo 253.
Navíc v té době byl počet hlavních čísel zařízení omezen na 255 a hrozilo, že dojdou. Alokovat jedno hlavní číslo pro RAID0, jedno pro LINEAR, jedno pro RAID1 a tak dál by vypadalo jako plýtvání, takže přiřazení jednoho čísla MD a připojování různých personalit do jednoho ovladače mohlo být jednoduše záležitostí číselné ekonomie. Dnes máme k dispozici mnoho hlavních čísel, takže již není nutné těsné spojení mezi hlavními čísly a ovladači – ovladač si jednoduše zabere jakékoliv číslo zařízení, které v danou chvíli chce, když je zaváděn modul nebo vytvářeno zařízení.
Druhým důvodem je to, že všechny personality MD, o kterých se v dané době přemýšlelo, měly mnoho společného. Konkrétně všechny používaly určitý počet komponent, ze kterých vytvářely větší zařízení. I když vytvoření mezivrstvy, která tuto funkcionalitu obalí, může být chybou, je to velmi lákavý krok a zdá se, že to zjednodušuje implementaci.
A nakonec, jak již bylo zmíněno, mít jediný modul, který definuje své vlastní interní rozhraní, může poskytnout prostředek, jakým se izolovat od dalších částí jádra. I když to bylo zmíněno pouze u DM, MD to rozhodně není cizí. Tato izolace, i když není nutně v nejlepším zájmu jádra jako celku, může jednotlivému vývojáři značně zjednodušit život.
Žádný z těchto důvodů dnes není obhajitelný, i když některé v minulosti rozhodně platné byly. Takže je možné, že místo snahy o sjednocení DM a MD bychom se měli snažit o jejich označení za zastaralé. Pokud bychom našli jednoduchý přístup, který by umožnil vznik různých implementací virtuálních blokových zařízení jako nezávislých ovladačů, ale přitom by zachoval stejnou funkcionalitu, kterou mají teď, byla by to pravděpodobně nejlepší cesta vpřed.
To nás přivádí k linuxovému modelu zařízení. I když nemusí být skutečně potřeba DM a MD sjednotit, zařízení, která tyto dva systémy vytváří, se musí vejít do sjednocujícího modelu pro zařízení, který nazýváme „model zařízení“ [device model] a který je nezjevněji viditelný v různých adresářových stromech v sysfs. Model zařízení má velmi široký koncept „zařízení“. Jde o mnohem víc než o tradiční unixová bloková a znaková zařízení; zahrnuje sběrnice, zprostředkující zařízení [intermediate device] a v podstatě všechno, co lze nějak adresovat.
V tomto modelu se zdá být rozumné, aby existovalo zařízení „pole“, které bylo poměrně vzdálené „blokovému“ zařízení poskytujícímu prostor pro data v poli. To není nepodobné současné situaci, kde SCSI sběrnice má potomka, což je SCSI cíl [target], který následně má potomka, který je SCSI LUN (Logical UNit, logická jednotka), a toto zařízení samo o sobě je stále oddělené od blokového zařízení, které považujeme za „SCSI disk“. Toto oddělení by umožnilo vytvořit a nastavit pole předtím, než se objeví blokové zařízení, takže by se odstranil prostor, ve kterém může být udev zmaten.
Model zařízení již umožňuje ovladači sběrnice, aby objevoval zařízení na této sběrnici. V mnoha případech se toto děje během bootu v době připojování za běhu [hotplug time]. Je nicméně možné požádat sběrnici, aby vyhledávala nová zařízení nebo aby hledala konkrétní nové zařízení. Tento poslední krok by bylo snadno možné si vypůjčit ke správě vytváření virtuálních blokových zařízení na virtuální sběrnici. Automatické prohledávání by žádné zařízení nenašlo, ale výslovný požadavek pro výslovně pojmenované zařízení by mohl vždy uspět tak, že se zařízení jednoduše vytvoří. Pokud zařízení nastavíme tak, že se vyplní soubory vlastností virtuálního blokového zařízení, budeme mít jednotný a rozšiřitelný mechanismus pro nastavování všech blokových zařízení, které vyhovují existujícímu modelu.
Model zařízení opět umožňuje připojování různých ovladačů k zařízením, což je implementováno v různých souborech „bind“ v adresářové struktuře /sys/bus. Tuto myšlenku by šlo využít tak, že jakmile bude virtuální blokové zařízení „objeveno“ na sběrnici virtuálních blokových zařízení, mohl by k němu být připojen vhodný ovladač, který by atributy interpretoval, případně vytvořil dodatečné soubory pro další atributy a nakonec vytvořil blokové zařízení.
Existující vlastnost, kterou bude pravděpodobně nejsložitější čistě reprezentovat v modelu zařízení, je změna nastavení za běhu, kterou poskytuje DM a od nedávna i MD. Tato změna umožňuje předat kontrolu nad polem jinému ovladači bez potřeby odstranit a znovuvytvořit blokové zařízení (souborový systém tudíž může zůstat během přechodu připojený.) Udělat to zcela obecným způsobem by znamenalo oddělit blokové zařízení od jednoho rodiče a připojit ho k jinému. To by bylo z několika důvodů složité, jedním z nich je struktura backing_dev_info, která vytváří poměrně těsné spojení mezi souborovým systémem a ovladačem pro připojené blokové zařízení.
Další slabinou modelu zařízení je, že závislosti mezi zařízeními jsou značně omezené – zařízení může záviset maximálně na jednom jiném zařízení, na rodiči. Toto uspořádání příliš nesedí, když si uvědomíme, že pole závisí na všech svých komponentách a tyto komponenty se mohou čas od času měnit. Tato slabina byla již naštěstí identifikována a snad bude vyřešena způsobem, který bude fungovat i pro virtuální bloková zařízení.
Takže i když je spousta záležitostí, které tento model nechává bez řešení, zdá se, že sjednocení s modelem zařízení obsahuje klíč ke sjednocení MD a DM společně s ostatními virtuálními blokovými zařízeními.
I když víme, že je problém složitý, neomlouvá nás to od jeho neřešení. S rostoucím zájmem o správu několika zařízení zároveň, jak to vidíme u DRBD a Btrfs, a také s rostoucí shodou funkcionality mezi DM a MD by nyní mohl být ideální čas na to začít řešit problémy a sjednocení dosáhnout. Vzhledem k různým problémům a rozdílnostem diskutovaným výše by se zdá, že velmi důležitým krokem je definovat a dohodnout se na několika rozhraních; konkrétně na dvou.
První rozhraní, které potřebujeme, je rozhraní pro vytváření a konfiguraci zařízení. Musí poskytovat prostředky pro všechny různící se potřeby DM, MD, Smyčky, NBD, DRBD, a možná dokonce i Btrfs. Musí být dostatečně kompletní, aby současná rozhraní komunikující pomocí ioctl() a netlinku bylo možné zcela implementovat voláními tohoto nového rozhraní. Je téměř určité, že toto rozhraní by mělo být zpřístupněno přes sysfs a že je tedy potřeba, aby se dobře integrovalo do modelu zařízení.
Druhé rozhraní je to mezi blokovou vrstvou a jednotlivými blokovými ovladači. Toto rozhraní musí být rozšířeno tak, aby podporovalo veškerou funkcionalitu, které DM cíl očekává od svého rozhraní s DM tabulkou, a konkrétně aby bylo schopné podporovat výměnu ovladače pod sebou, i když blokové zařízení zůstane aktivní.
Definice a, což je velmi důležité, shoda na těchto rozhraních bude znamenat významný krok směrem k dosažení tak dlouho hledaného sjednocení.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
s/používají/používajá/g
ale aj tak to velmi nedava zmysel
> aby generovaly hluk v mailové konferenci.
s/hluk/šum/g
5.11.2009 19:26
Nicky726 | skóre: 56
| blog: Nicky726
Cíle jsem jednoduše propojeny tak, aby se vytvořilo jediné větší blokové zařízení.
Je tam toho víc, bohužel jsem byl tak začten do tématu, že nebyl čas na poznámky od cesty 
.
Jinak už tuším, proč kombinace dvou rozvržení raid10 je těžká na implementaci v současném systému. Snad se to zlepší 
.
Situace byla údajně vyřešena tak, jak ji mohl vyřešit jenom Al Viro.
To je, prosím, jak? 
(nežádám vysvětlení od překladatele, je to myšleno obecně).
Závěrem - díky, dneska jsem si opravdu dosytosti početl!
... a rozdílnostem diskutovaným výše by se zdá, že ...inak super článok
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz