Jaderné noviny – 20. 1. 2010

12. 2. 2010 | Jirka Bourek | Jaderné noviny | 3494×

Aktuální verze jádra: 2.6.33-rc4. Citáty týdne: H. Peter Anvin, Alan Cox. devtmps přijde o značku EXPERIMENTAL. LCA: Proč jsou souborové systémy obtížné. Uprobes: Stále na cestě.

Obsah

• Aktuální verze jádra: 2.6.33-rc4
• Citáty týdne: H. Peter Anvin, Alan Cox
• devtmps přijde o značku EXPERIMENTAL
• LCA: Proč jsou souborové systémy obtížné
• Uprobes: Stále na cestě

Aktuální verze jádra: 2.6.33-rc4

Současné vývojové jádro je 2.6.33-rc4 vydané 12. ledna. Od té doby se do Linusova stromu dostalo 366 neslučovacích sad změn, většinou jde o opravy chyb. -rc5 lze očekávat brzy, pravděpodobně těsně po vydání článku.

Stabilní aktualizace: 18. ledna byla vydána tři stabilní jádra: 2.6.32.4, 2.6.31.12 a 2.6.27.44. Každé obsahuje několik oprav (2.6.32.4 obsahuje 52 patchů) včetně nějakých bezpečnostních záležitostí. Greg Kroah-Hartman také vydal hlášení o stavu stabilních stromů, ve kterém poznamenává, že téměř určitě nebudou žádné další aktualizace 2.6.31, 2.6.27 je udržitelné jenom po dalších 6 – 8 měsíců a že jako „dlouhodobé“ stabilní vydání bude udržovat 2.6.32.

Citáty týdne: H. Peter Anvin, Alan Cox

Vzhledem k tomu, že 32 bitů pro jakýkoliv stroj s více než 1 GB paměti znamená HIGHMEM, ne-embedded stroje, na kterých by dnes měla běžet 32bitová jádra, v podstatě tvoří prázdnou množinu. Bohužel linuxová distra nedostatečně propagovala 64bitová jádra pro 32bitové distribuce; i když čistých 64 bitů je lepší, i tak by bylo sakra lepší, kdyby lidi používající 32 bitů kvůli kompatibilitě měli rozumnější alternativu.

-- H. Peter Anvin

Mohli by lidé nyní přijmout fakt, že důvodem, proč máme o něco složitější modely pro bezpečnostní politiku, je to, že obecně řečeno tyto malé kouzelné páčky „á, jak jednoduché“ prostě nefungují a neřeší problémy ze skutečného světa.

-- Alan Cox

devtmps přijde o značku EXPERIMENTAL

Během poměrně krátké doby se devtmpfs dostal od květnového kontroverzního návrhu k začlenění do hlavní řady ve verzi 2.6.32. Byl nicméně začleněn jako experimentální vlastnost, což by jeho vývojáři rádi změnili. Kay Sievers zaslal patch, který by toto označení odstranil a zároveň by devtmpfs ve výchozím nastavení zapnul: Všechny velké distribuce na současných systémech devtmpfs povolují, takže odstranění příznaku EXPERIMENTAL a jeho povolení ve výchozím nastavení odráží stav, jak se používá.

Komentáře naznačují, že proti odstranění příznaku nejsou velké stížnosti, ale nastavení výchozí hodnoty na zapnuto příliš populární nebylo. Arjan van de Ven si stěžoval, že to porušuje konvenci: ,default y‘ používáme jenom pro věci, které předtím byly zapnuté a kterým byla přidána konfigurační volba. Přinejmenším Kay o této konvenci nikdy neslyšel, ale je ochoten se jí řídit. Pokud existuje.

Alan Cox upozornil, že existující distribuce devtmpfs nepoužívají; jenom ty ve vývoji, ale Kay u starších systémů nevidí problém:

A na žádném starém systému by to zapnuté nemělo dělat potíže. Pokud se používá initramfs, bude to naprosto neviditelné; pokud se používá vlastní jádro s rootfs, který je připojen jádrem, bootovací skript udevu obvykle devtmpfs překryje tak, že do /dev připojí prázdný tmpfs, stejně jako to dělal vždy.

Není jasné, jestli je tato změna míněna pro 2.6.33, nebo byla jenom předběžně navržena pro 2.6.34, ale proti odstranění EXPERIMENTAL podle všeho není žádná opozice. Jestli tato vlastnost bude ve výchozím nastavení zapnutá, je otázka, ale své místo v hlavní řadě si devtmpfs v poměrně krátké době vydobyl.

LCA: Proč jsou souborové systémy obtížné

Souborový systém ext4 se blíží k vyvrcholení svého dlouhého vývojového procesu. V hlavní řadě je již rok označen jako stabilní, distribuce ho používají jako výchozí a do konce tohoto roku by se mohl dočkat i širšího nasazování na podnikové úrovni. Na linux.conf.au 2010 programátor ext4 Ted Ts'o mluvil o procesu stabilizace ext4 a o tom, proč souborovým systémům trvá dlouho, než jsou připraveny pro produkční nasazení.

Ted říká, že obecně lidé bývají až příliš optimističtí ohledně toho, jak rychle se souborový systém může stabilizovat. Z mnoha poměrně jasných důvodů nejde o rychlý proces. Obecně existuje několik aspektů softwaru, kvůli kterým ho může být obtížné testovat a ladit – mezi ně patří předčasná optimalizace („kořen všeho zla“), přítomnost velkého množství vnitřních stavů a prostředí zahrnující značný paralelismus. Jakákoliv z těchto vlastností ztěžuje chápání kódu a komplikuje testovací prostředí.

Souborové systémy trpí všemi těmito problémy. Uživatelé vyžadují, aby byl obecný souborový systém optimalizován pro velkou škálu zátěží; tato práce na optimalizaci musí být odvedena na všech úrovních kódu. Celá práce souborového systému spočívá v ukládání a správě interních stavů. To mezi jinými věcmi ztěžuje vývojářům reprodukování problémů; specifické chyby jsou s největší pravděpodobností spojeny se stavem specifického souborového systému, který jeho uživatel nemusí chtít sdílet, nemluvě o praktických potížích spojených se zpřístupňováním stovek gigabytů dat vývojářům. A paralelismus je vnitřní součástí prostředí každého všeobecného souborového systému; vždycky se bude dít víc věcí naráz. Všechny tyto faktory dohromady způsobují, že se souborový systém stabilizuje obtížně.

Podle Teda jsou souborové systémy podobné kvalitnímu vínu, musí poměrně dlouho stárnout, než jsou hotovy. S tím ale souvisí problém: Závislost na pracovní zátěži u většiny souborových systémů garantuje, že vývojáři těchto souborových systémů nemohou sami o sobě najít všechny chyby v kódu. Vždy je potřeba, aby uživatelé kód testovali a hlásili své zkušenosti. Vývojáři tedy mají silnou motivaci povzbuzovat uživatele k testování kódu, ale ti etičtější (přinejmenším) nechtějí, aby uživatelé ztratili data. Je to hranice, na které je těžké se pohybovat.

Co je tedy potřeba k naprogramování souborového systému a k tomu, aby byl připraven k použití? Během získávání financí pro vývoj Btrfs Ted hovořil s veterány vývoje souborových systémů posledních let. Ti všichni odhadovali, že dostat souborový systém do stavu vhodného pro nasazení vyžaduje něco mezi 75 až 100 člověk-let práce – nebo více. To je poměrně skličující věc, když ji máte říct vedení společnosti při snaze získat finance; u Btrfs se Ted spokojil s návrhem, že by každá ze zainteresovaných firem měla věnovat dva programátory. Bohužel ne všechny společnosti se tohoto návrhu držely, do cesty se připletly nějaké problémy spojené s ekonomickou krizí.

S tím spojený příklad: Sun začal pracovat na ZFS roku 2001. Projekt byl oznámen až roku 2005 a dodávat se začal roku 2006. Ale až v tom posledním roce správci systému získali dostatek důvěry v ZFS, aby ho začali nasazovat na produkční stroje. A během této doby tým ZFS – dobře přes tucet lidí – věnoval spoustu času vývoji souborového systému.

Kde si věci stojí u ext4? Ted říká, že je to teď zajímavá doba. V komunitních distribucích se ext4 dodává již nějakou dobu, přičemž mnoho z nich jej instaluje jako výchozí. Se štěstím ho brzy začnou dodávat distribuce s prodlouženou podporou a pro podnikové nasazení; nasazení na podnikové úrovni lze očekávat přibližně rok poté.

Během posledního roku bylo v každém vydání hlavní řady něco mezi 60 a 100 patchi ext4. Jenom méně než polovina z nich jsou opravy chyb; mnoho z toho zbytku jsou pročišťovací patche. Stále se objevuje i malé množství patchů pro vylepšení výkonnosti a přidávání vlastností. Ted poznamenal, že počet oprav chyb v nedávných vydáních neklesá; podle něj je to očekávatelné, komunita uživatelů ext4 se rapidně rozrůstá a víc uživatelů najde (a ohlásí) víc chyb.

Určité množství těchto chyb jsou problémy s odepřením služby; mnoho z nich jsou pády systému v reakci na poškozený obraz souborového systému na disku. Větší podíl mají souběhy a deadlocky obzvlášť. Je pár problémů spojených se synchronizací; těch si běžně nelze všimnout, pokud systém nespadne ve špatnou chvíli. A pak je několik úniků paměti většinou spojených se špatně testovanými cestami řešení chyb.

Oblasti, kde lze nalézt většinu chyb, mohou něco napovědět. Objevily se problémy při interakci mezi alokátorem bloků a funkcí změny velikosti za běhu – ukazuje se, že lidé nemění velikost souborového systému často, takže tento kód není vždy dobře otestován. Další chyby se objevily při interakci mezi předalokací bloků a řešení situace, kdy dojde místo. Defragmentace za běhu měla mnoho problémů včetně jedné ošklivé bezpečnostní chyby; ukázalo se, že tento kód nikdo netestoval. ioctl() příkaz FIEMAP, který ve skutečnosti používá jenom jeden nástroj, měl své problémy. Objevily se záležitosti spojené s diskovými kvótami; tato vlastnost se také příliš nepoužívá a obzvláště ji nepoužívají vývojáři souborových systémů. A byly problémy i s režimem běhu bez žurnálu, kterým přispěl Google; souborový systém obsahoval mnoho předpokladů „vždycky máme žurnál“ zděděných z ext3, ale tento kód opět testovalo jenom pár lidí.

Společný znak by měl být jasný: Spousta chyb, které se objevují v této fázi hry, je spojena s málo využívanými vlastnostmi, které nebyly testovány tolik jako hlavní funkce souborového systému. Dobrá zpráva je, že většina chyb ve skutečnosti nepostihla tolik uživatelů.

Objevil se jeden konkrétní problém, který trvalo šest měsíců najít; přibližně jednou za měsíc se rozbil souborový systém patřící odhodlanému a dlouho trpícímu testerovi. Ukázalo se, že existoval souběh, který dokázal disk poškodit, pokud dva procesy zapisovaly naráz do stejného souboru. Jak se stává, přesně to dělá Samba, zatímco aplikace používané většinou vývojářů souborových systémů ne. Poučení z tohoto příběhu: To, že vývojář nepozoruje problémy, neznamená, že je kód bezpečný.

Další chyba udeřila jenom v případě, pokud systém spadl ve špatnou chvíli; existovala dlouho, než si jí někdo všiml. Jak dlouho? Byla i v souborovém systému ext3 a nikdo ji nikdy nenahlásil.

Také bylo nalezeno a opraveno mnoho problémů s výkonností. Pravděpodobně nejvýznamnější měl co do činění s výkonností zpětného zápisu. Podle Teda v současnosti vnitřní kód zpětného zápisu v jádře funguje poměrně špatně, výsledkem je to, že souborovému systému řekne, že má zpětným zápisem zapsat nejvíce 1024 bloků naráz. To je pro velká a rychlá zařízení příliš málo. Ext4 proto obsahuje hack, díky kterému dojde na zpětný zápis většího množství dat, než požadovala vrstva VFS. Ted říká, že je to ospravedlnitelné, protože všechny ostatní souborové systémy dělají totéž. Obecně nikdo nechce na kód pro zpětný zápis sahat, částečně kvůli obavám z rozbití všech obezliček, které si během let našly svou cestu do kódu specifického pro souborové systémy.

Ted přednášku uzavřel s tím, že v jistém ohledu jsou souborové systémy jednoduché: Linuxové jádro obsahuje hodně obecného podpůrného kódu, který odvádí spoustu práce. Pravda je však taková, že jsou složité. Je potřeba podporovat spoustu typů pracovních zátěží, jsou značné požadavky na výkonnost a bývá spousta paralelně běžících procesů. Vytvoření souborového systému je výsledkem práce s láskou; z obchodní perspektivy je to většinou ospravedlnitelné obtížně. Tato realita se odráží v tom, že v současnosti téměř nikdo neinvestuje do vývoje souborového systému; jediná výrazná výjimka je Sun a jeho práce na ZFS. Jak ale Ted poznamenal, tato práce stála hodně a není jasné, jestli byla taková investice ospravedlněna ziskem. Doufejme, že významné množství práce věnované vývoji souborových systémů pro Linux přinese zjevnější užitek.

Uprobes: Stále na cestě

Během posledního přibližně roku je v Linuxu vidět velký pokrok, co se týče podpory sledování [tracing]. Podpora jedné důležité vlastnosti v hlavní řadě ale stále chybí: Bezproblémové sledování běhu v uživatelském prostoru jádrem. Subsystém, který to má zajišťovat – utrace – narazil na své cestě do hlavní řady na mnoho překážek. Jako řešení dynamického sledování aplikací v uživatelském prostoru byla nyní navržena vlastnost na vyšší úrovni – usondy [uprobes]. Můžeme předeslat, že tato kombinace vykazuje rychlý postup směrem k začlenění, ale následná diskuze naznačila, že jsou zde stále problémy, které je nejdříve nutné překonat.

Tato verze usond je ve skutečnosti tvořena dvěma nezávislými moduly, které problém řeší na dvou úrovních. Kus na nižší úrovni se jmenuje „UBP“, což je zkratka pro user-space break points [bod přerušení v uživatelském prostoru]; jeho úkolem je vkládání sond do procesů v uživatelském prostoru. Vývojáři to odůvodnili tím, že sondy v uživatelském prostoru mohou mít v budoucnu i další uživatele, takže nástroje pro vkládání a odebírání těchto sond byly vytvořeny odděleně.

Nad UBP je už skutečný kód usond, který řeší detaily na vyšší úrovni. Usondy slouží jako arbitr mezi více uživateli sledovacích bodů, a to i když dva uživatelé chtějí vložit sondu na stejné místo. Používají utrace k tomu, aby se ujistily, že proces neběží nikde v oblasti, do které se bude vkládat sonda, a řeší situaci, kdy několik procesů používá stejný kód, přičemž některé z těchto procesů jsou sledovány, a jiné ne. Kód usond je také zodpovědný za volání sledovací funkce, když se narazí na sondu, a za správné zotavení, když se tato funkce chová špatně.

Toto rozdělení je prvním bodem sporu; Peter Zijlstra (který je doteď hlavním revidovatelem kódu) považuje usondy za zbytečnou vrstvu lepidla, které by se šlo zbavit. Peter by byl radši, kdyby byly všechny potřebné vlastnosti vytlačeny dolů do UBP, takže by bylo možné zahodit kód na vyšší úrovni. Vývojáři usond nicméně nesouhlasí a tvrdí, že funkce implementované na této úrovni jsou nutné a nemohou být odstraněny. Tato část diskuze v podstatě utichla, ale nezdá se, že by vývojáři byli nakloněni tomu dělat zde významné změny.

Další problém spočívá v samotné implementaci sond. Když je do programu v uživatelském prostoru vložena sonda, instrukce na sledované pozici je přepsána bodem přerušení. Když se dojde k tomuto bodu, je zavolána funkce obsluhy sondy [probe handler]; když se vrátí, je nutné nahrazenou instrukci nějak vykonat. Jednoduchá implementace by instrukci vrátila na její místo, odkrokovala ji [single-step] a pak zase obnovila bod přerušení. Tento přístup ale selže, když existuje druhý proces (nebo vlákno), který je také sledován. Pokud takový proces projde přes sledované místo v době, kdy je sonda odstraněna, příslušná událost se ztratí.

Vývojáři usond tedy použili jiný přístup nazvaný „úkrok stranou“ [single-step out of line] či „vykonání mimo“ [execute out of line, XOL]. Pro instrukce přepsané sledovacím bodem je vytvořena samostatná oblast paměti. Když má být jedna z nich vykonána, je spuštěna (opět v režimu krokování) v této oddělené oblasti; poté se běh vrátí na místo sondy. Toto řešení sondě umožňuje pracovat s několika procesy naráz.

Problém spočívá v následujícím: Paměť obsahující XOL instrukce musí být v adresovém prostoru sledovaného procesu. Kód XOL proto přidává procesu oblast virtuální paměti [virtual memory area, VMA], čímž rezervuje pro tento účel rozsah v adresovém prostoru. To funguje, ale některým vývojářům to připadá přinejlepším neelegantní, přinejhorším potenciálně rušivé. V současnosti je rozvržení adresového prostoru procesu téměř úplně pod kontrolou procesu samotného. Vložení zvláštního jaderného VMA může narušit rozvržení adresového prostoru, takže se ostatní VMA budou muset přemístit; dokonce může dojít i ke konfliktu, pokud se proces pokusí umístit VMA na specifické místo. Debuggery jsou známy tím, že často naruší chování aplikace (což vede k „heisenbugům“, které zmizí, když se je někdo pokusí pozorovat přímo), ale sledování, které je zamýšleno pro produkční systémy, by taková narušení mělo minimalizovat. Peterovi se také nelíbí, že by jádro hrabalo do adresového prostoru procesu. A nakonec na 32bitových systémech ztráta i malé části adresového prostoru kvůli funkci jádra může být v mnoha případech nevítaná.

Řešení problému není úplně jednoduché. Peter podle všeho straní emulaci vynechané instrukce, ale to by vyžadovalo v jádře implementovat kompletní emulátor instrukcí. Takový kód by byl rozsáhlý, specifický pro architekturu a náchylný k chybám. Diskutovalo se o tom, že by se zkusilo instrukci spustit v jaderném prostoru, ale je poměrně náročné udělat to bezpečně. Po dlouhé diskuzi podle všeho zvítězil názor, který je podobný tomu, co vyjádřil Pekka Engberg:

Hádám, že pro normální případy se díváme na několik megabytů adresového prostoru, což se nezdá být tak moc… To pomyšlení se mi moc nelíbí, ale jestliže jsou výkonnostní zisky skutečné (jsou?), pak je to možná výměna, která za to stojí.

Nakonec možná jaderní vývojáři přimhouří oči a tento přístup začlení, ale je dost pravděpodobné, že o tom ještě chvíli budou muset mluvit.

Kód usond je dodáván s pluginem pro ftrace, který uživatelskému prostoru poskytuje rozhraní pro umisťování a správu sond. Problém je zde v tom, že se jaderní vývojáři v podstatě rozhodli, že se už do jádra nebudou přidávat další pluginy pro ftrace. Od nových vlastností se očekává, že se budou přidávat do subsystému událostí výkonnosti [perf events], který je považován za lépe navržené rozhraní. Před začleněním kódu tedy bude téměř s určitostí nutné tento plugin přepracovat.

Ftrace plugin také spojuje sondy v uživatelském prostoru se specifickým procesem. Peter argumentuje, že je smysluplnější zaháčkovat sondy do spustitelných souborů a spojení zajistit pomocí VMA struktury, když je soubor mapován. V jádře existující vlastnosti, možná doplněné o jednoduchý háček nebo dva, by usondám usnadnily nalézání procesů, které běží s kódem z daného souboru, a práci s vytvářením a ukončováním procesů, když jsou sondy na místě. Vývojáři usond to neřekli, ale v době psaní tohoto článku se zdá, že API by bylo možné takto přepsat.

Pak je zde nepříjemná záležitost, že vrstva utrace se ještě nedostala do hlavní řady. Nedávno byla přidána do linux-next, ale jsou s ní určité nepříjemnosti a není jisté, jestli tam zůstane.

To vše může vypadat jako spousta překážek v začlenění tohoto kódu, ale také to představuje krok kupředu. Cesta do hlavní řady byla pro utrace dlouhá; jedna nebo dvě závěrečné objížďky se nezdají být příliš. Existence usond jako jaderného uživatele utrace by mohla v této věci pomoci, jakmile usondy samy projdou. Za předpokladu, že se podaří u zmíněných záležitostí dosáhnout konsenzu, by mělo být možné provést poslední kolo změn a být poměrně blízko k začlenění kódu – i když pravděpodobně bude obtížné stihnout to do začleňovacího okna 2.6.34. Pokud věci půjdou dobře, sondy v uživatelském prostoru bychom měli mít nedlouho poté.

       

Komentáře

[Radek Podgorny]

Diky moc za tenhle serial!

...ale, jsem exot, kdyz mi pripada preklad typu "usondy" uz trochu moc?

[Nikola Ciprich]

nejste, taky mi to prijde hrozne... ale nejde se vzdycky zavdecit vsem, a vetsina lidi zrejme preferuje prekladat vsechno co nejvice.. :( takze se my anglofilove musime podridit :)

[ewqrqwr]

hlavni je informacni hodnota, i kdyz je fakt, ze u_sondy zni jak nazev pajzlu.

[Filip Jirsák]

Mně se ten překlad naopak líbí, myslím si, že přesně takhle by měl překlad vypadat.

[Michal2]

Myslis tak, aby si to clovek musel prelozit zpet aby pochopil o cem je rec? Kdo to nedokaze tak je v haji uplne. Chce vedet vic, napise do googlu usondy a najde prd.

[Filip Jirsák]

Právě naopak – člověk si to nemusí překládat zpátky, nemusí dokonce zdrojovému jazyku vůbec rozumět, a přesto pochopí, o čem je řeč. Je to překlad, který plnohodnotně nahrazuje originál a čtenář, který rozumí česky, se z něj dozví totéž, co se dozví z originálu anglicky mluvící.

Když zadá někdo do Googlu „usondy“ a nenajde nic, znamená to asi, že o nich nic v češtině není. Pokud chce hledat články v angličtině, nevím, proč čte české Jaderné noviny a ne anglický originál.

[neaktivni]

a co jsou to teda usondy?

[Filip Jirsák]

Vlastnost pro řešení dynamického sledování aplikací v uživatelském prostoru. Máte to napsané v článku. Jinak, jak je z názvu patrné, jsou to určité druhy sond.

[Libor Chocholaty]

Problem nastal v dalsim clanku, kdy autor slovo "usondy" zacal skonovat. Kdyz vidim "usond" patram v pameti po nejakem daemonu, ktery se tak jmenuje. Ze jde o uprobes me ani nenapadlo. A ze by se melo jednat o nejake sondy taky ne.

[Ondrej 'SanTiago' Zajicek]

Pokud chce hledat články v angličtině, nevím, proč čte české Jaderné noviny a ne anglický originál.

Treba proto, ze si radsi precte clanek v cestine, ale kdyz dalsi dokumentace v cestine neni, tak se spokoji s anglickou dokumentaci.

[Filip Jirsák]

Pokud chce hledat anglickou dokumentaci, tak ať hledá anglický termín (v článku jej má napsaný také). Hledat anglickou dokumentaci s použitím českého termínu je poněkud hloupé.

[Robert Krátký]

aby si to clovek musel prelozit zpet aby pochopil o cem je rec

V článku je uveden i původní termín.

[mikro]

Pochopil niekto, ako sa to myslelo s tymi 32-bit vs 64-bit jadrami tam na zaciatku? Pozrel som anglicky original, precital viac krat po sebe ten cesky preklad, ale stale nechapem, co bola vlastne pointa.

[petr_p]

Že kdokoliv, kdo má více jak 1 GB, má použít 64b jádro.

[petr_p]

Na druhou stranu pán asi žije v jiném světě. U nás se běžně do 32b strojů dokupuje paměť.

[Pavel Francírek]

Ona signatura "H. Peter Anvin, Intel Open Source Technology Center" o něčem vypovídá :) Podle Intelu už asi mají dávno být všude nové 64bit procesory.

[stativ]

No, jak já to chápu, tak tím myslí následující. Pokud máš teď ve svém PC více než 1GB paměti, ale kvůli nějaké pitomosti (třeba nějaký program, úchylka uživatele na 32bit userland) musíš provozovat 32bit systém, tak musíš mít jádro s podporou HIGHMEM, což je, jestli se nepletu ne zrovna efektivní. Co autor doporučuje, je mít 64bit jádro a vše ostatní mít 32bit. Bohužel to žádná současná distribuce neumožňuje (buď máš komplet 32bit systém nebo 64bit systém, do kterého si můžeš nainstalovat vybrané 32bitové balíčky)

[trekker.dk]

Bohužel to žádná současná distribuce neumožňuje

Slyšel jsi někdy o Debianu?

[stativ]

Překládal jsem jen, jak jsem to pochopil. U Debianu v tom nevidím nějaký zvláštní problém. Sice jsem tuhle kombinaci ještě neviděl, ale když tam člověk může mít jako jádro Hurd tak by bylo divný, kdyby to nešlo. Gentoo a SourceMage to samé. A samozřejmě LFS

[trekker.dk]

Překládal jsem jen, jak jsem to pochopil.

Jo tak. Ona ta stížnost nebyla, že to distribuce nepodporují, ale spíš že taková možnost není dostatečně propagována.

[Jiří J.]

Je tam Dokonce v defaultním i386 repozitáři.

Původně jsem si to tak chtěl nechat, mám tu docela dost binárních 32bit aplikací (bez dostupného zdrojáku) a štvát se s nějakým transparentním chrootem se mi nechtělo. Pak mé oko našlo něco jako lib32 v amd64 verzi repozitáře a už jedu vesele na 64bit .

[Václav Kramář]

vaclav@debian:~$ uname -a
Linux debian 2.6.30-bpo.1-amd64 #1 SMP Mon Aug 17 19:58:33 UTC 2009 x86_64 GNU/Linux
vaclav@debian:~$ file /bin/bash
/bin/bash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped
vaclav@debian:~$

http://packages.debian.org/stable/linux-image-amd64

[Kaacz]

hmm, tak tohle si musim nekde vygooglit ... protoze vsude se vzdy tvrdilo ze 32bit primo adresuje 4GB .. coz pravda je .. tak k cemu HIGHMEM ?!?!?!

mozne je ze jinak to dela i386 a jinak i686. Mel jsem pocit, ze kdyz mam kernel i586/i686, tak 2-3GB adresuje primo a nepotrebuje zadne berlicky. U plneho vyuziti 4GB uz by clovek potreboval PAE a tam je samozrejme lepsi jit do 64bit.

Ale napr. na iAtom330+ION media center s 2GB RAM pro prehravani HD filmu nevidim jediny duvod jit do 64bit. Vykonove nic neziskam, instalace je vetsi, binarky jsou malinko vetsi, nektere si zaberou vic pameti .. proste zbytecne.

Nemluve o tom, ze XBMC autori neustale pindaji ze to ladi jen na 32bit a 64bit je nezajima ..

Tak ted babo rad.

[stativ]

hmm, tak tohle si musim nekde vygooglit ... protoze vsude se vzdy tvrdilo ze 32bit primo adresuje 4GB .. coz pravda je .. tak k cemu HIGHMEM ?!?!?!

Proč to tak je nevím, ale můžu potvrdit, že 1,5 GB RAM mi bez HIGMEM na 32bitu neběhá.

[trekker.dk]

AFAIK to souvisí s dělením adresového prostoru mezi jádro a uživatelský prostor.

[Jakub Lucký]

# aptitude show linux-image-2.6.32-2-686-bigmem 
Package: linux-image-2.6.32-2-686-bigmem
Version: 2.6.32-8
Provides: linux-image, linux-image-2.6, linux-modules-2.6.32-2-686-bigmem
Description: Linux 2.6.32 for PCs with 4GB+ RAM
 The Linux kernel 2.6.32 and modules for use on PCs with 4-64GB RAM, using PAE (Physical Address Extension). 

A na mém stroji 32bitový kernel (64bitový má/měl rozbitý ioctl wrapper (nefungoval třeba wpa supplicant)) zvládá 2GB RAM bez problémů (Opera mi je občas zdatně zaplní)

[Filip Jirsák]

V části o souborových systémech je za větou Ted hovořil s veterány vývoje souborových systémů posledních let odkaz bez textu (který se projevuje jen šipečkou). Předpokládám, že jeho utajení nebyl záměr…

[trekker.dk]

Textem toho odkazu je ten obrázek vedle, ta šipka je v místě, kde je v HTML ten odkaz. Je to udělané stejně jako na LWN, jenže tam to jednak nevede mimo a druhak nemají tyhle praštěný šipky.

[Filip Jirsák]

V tom případě by se tomu odkazu měla přidat třída noext, která tu šipečku odstraní.

[trekker.dk]

Napiš, jak ten odkaz má vypadat, já to tam klidně budu dávat (ale tady to už změnit nemůžu)

[Filip Jirsák]

V tomto případě by to mělo být: <a class="noext" href="http://lwn.net/Articles/370421/"><img height="178" border="0" align="right" width="150" alt="[Ted Ts'o]" src="http://lwn.net/images/conf/lca2010/TedTso-sm.jpg"/> </a>

[Robert Krátký]

Především bych neměl zapomínat přenášet obrázky na server abclinuxu.cz - tím by se mnoho věcí vyřešilo...

[Martin]

Mě teď zarazila jedna věc. Ve stabilním jádře jsem narazil na chybu, která způsobuje zatuhnutí systému cca jednou za den. Chybu jsem našel nahlášenou asi od listopadu minulého roku.

Myslel jsem, že v takovém okamžiku se všechno zastaví a všichni začnou řešit tento problém. Přece není možné, aby jádro jen tak při zátěži tuhlo.

Kdepak. Nikoho to nezajímá. Nikdo podrobnosti nehledá. Nikdo se nesnaží pád nasimulovat. "Čekejte na další verzi, třeba se to spraví samo." Docela mě to udivilo, měl jsem o vývoji jádra jiné představy.

[Nikola Ciprich]

to zalezi... ja resim podobne problemy docela casto, ve vsech moznych castech jadra (nebo i jineho sw), a autori jsou vetsinou ochotni pomoct, ale clovek se musi nekdy trochu snazit i sam, nestaci rict - mi to nefunguje, opravte mi to, ale treba aspon priblizne odhadnout kde chyba je, poslat co nejvice ladicich informaci atd. a docela casto se pak stane ze si chybu uz rovnou opravi sam a jen posle patch :)

[JoHnY2]

Mas pravdu, ale rochnit se v jadru je pro vetsinu administratoru docela problem. Obzlast blby je, kdyz se objevi bug v novy verzi SW na produkcni masine. Admin nemuze strelit firemni mailserver/db/... a jit si den hrat s debugovaci nastrojema.

[Marek 'marx' Grác]

Druhá možnosť pre ľudí, ktoré nemajú túto schopnosť je zaplatiť si podporu :)

[Jakub Lucký]

Hlásil jste to na distribuci, nebo přímo do kernelu? V distribuci většinou bývá člověk, co se právě těmahle věcma zabývá... V Debianu se obvykle ozve docela rychle (oproti jiným maintainerům) a často aspoň poradí workaround...

[Karry]

Pošli link na bug. Je nějaký zaručený způsob jak to reprodukovat? Chyby které se projevují u malé skupinky uživatelů jsou většinou způsobeny ovladači. Jaký nestandardní hw používáš? Já osobně nesleduji všechny bugy, pouze ty které se osobně týkají, nebo ty které způsobují ovladače jejiž kód znám... Člověk občas musí zařvat aby ho bylo slyšet :)

[thingie]

Já mám pocit, že ten článek of filesystémech jsem tady už četl. Nebo možná na LWN v originále? Strašně se mi to plete. Mělo by se to spravit.

[michich]

Pokud čteš LWN.net pravidelně, takovýto pocit máš správně mít při čtení Jaderných novin pokaždé

[thingie]

To je právě to, že nečtu. Ale občas jo.

[stativ]

Tak si říkám, že pod každými jadernými novinami jsou vždycky diskuse jen co se týče překladu a dalších estetických kravin místo toho aby se řešily důležitější věci, jako je devtmpfs. O kterém si myslím, že je to naprostá kravina a v jádře nemá co dělat (buď to mělo přijít před udevem, nebo nepřijít vůbec).

V současné době to neřeší vůbec nic (s výjimkou emebeded zařízení, které stejně budou nejspíš používat něco na způsob statického /dev). Klidně ať si tvrdí, že je to lepší než udev, protože to používá informace, které už jádro má (kdežto udev je znovu „vykopává“ ze sysfs) ale stejně se nakonec udev bude muset spustit. Radši ať upraví příslušná rozhraní které udev používá tak, aby měl ty informace dispozici hned.

Důvod, že boot bude na některých systémech rychlejší neberu (nehledě na to, co jsem řekl výše, že udev se stejně bude muset spustit), spouštění udevu za normálních okolností trvá chvilku. Takový HAL zabere desetkrát tolik času.

[vlastikroot]

No ... u mě trvá start udevu tak 6 sekund (přitom načítá ty moduly), přitom je to pitomost. Já jsem za devtmpfs rád, však ty soubory v /dev jsou to jediný, co člověk potřebuje pro běh. Nějakej HAL, bez toho by se člověk i obešel. A pořád lepší opravdu funkční dynamický /dev jako je to na normálních unixech, než statická patlanina. Imho je největší výhoda devtmpfs v přidání souboru, hned jak ho dá ovladač k dispozici, místo toho aby to dělal udev najednou (a pak to trvalo těch 6 sekund).

[stativ]

Konečně trochu smysluplná diskuse.

Podle mě právě tohle by šlo udělat nějakým zlepšením rozhraní udevu. V podstatě důvod, proč se na udev čeká než se spustí cokoli jiného je vytvoření základního /dev (console, null, zero). Ani to zařízení disku není potřeba pokud jsou potřebné věci v initrd. Takže by se to (možná) dalo udělat tak, že udev vytvoří základní strukturu /dev a systém začne vesele bootovat dál zatímco se /dev zaplňuje. Taky nevěřím tomu, že devtmpfs bude stejně konfigurovatelný jako udev.

Osobně si myslím, že za těch 6 sekund ani tak nemůže udev jako samotné jádro, které nahrává moduly. V nemodulárním systému na desktopu start udevu zabere myslím kolem 500ms. Jakmile jsem použil distribuční jádro s moduly, trvalo to několikanásobně déle. Rozdíl tedy podle mého je způsoben nahráváním modulů. Možná ale udevu dlouho trvá rozhodnout se, jaký modul nahrát. Možná by to jádro zvládlo rychleji, možná by to trvalo úplně stejně dlouho.

Jen tak mimochodem – bojím se, že řetěz xkb–HAL–udev v X.org bude pokračovat.

[Ondrej 'SanTiago' Zajicek]

Ja mam s udevem presne opacnou zkusenost - jeho start trva dlouho vcelku bez ohledu, zda zavadi moduly, nebo zda jsou moduly uz zavedene.

[stativ]

Holt jsem tedy klikař .

[Ondrej 'SanTiago' Zajicek]

Respektive tedy ne samotny start demona (ten je rychly), ale cela startovaci sekvence:

udevd --daemon
udevadm trigger
udevadm settle

Ktera spousti a ceka na dokonceni prehrani udalosti z bootu.

[trekker.dk]

V podstatě důvod, proč se na udev čeká než se spustí cokoli jiného je vytvoření základního /dev (console, null, zero). Ani to zařízení disku není potřeba pokud jsou potřebné věci v initrd.

Není to náhodou tak, že ty základní věci jako console tam už musí být před startem udevu? Pokud si vzpomínám, s prázdným /dev si jádro stěžuje, že can't open initial console

Osobně si myslím, že za těch 6 sekund ani tak nemůže udev jako samotné jádro, které nahrává moduly.

Neřekl bych - nemůžu říct, jestli je to na všech distrech, ale v Debianu se moduly nahrávají až když je udev a podobné nastartovaný (samozřejmě kromě těch nutných pro start systému). Takže udev nastartuje s minimální konfigurací (jádro + pár modulů), pak systém bootuje dál a v určité fázi se natáhnou věci zapsané v /etc/modules. A ani tam nemusí být všechno, hodně modulů se natáhne až když jsou potřeba (USB mass storage atd.)

Možná ale udevu dlouho trvá rozhodnout se, jaký modul nahrát.

Já měl za to, že o nahrání modulu rozhoduje jádro, když je modul zapotřebí k zařízení, které se právě detekovalo, a udev jenom vytvoří odpovídající soubory v /dev

Jen tak mimochodem – bojím se, že řetěz xkb–HAL–udev v X.org bude pokračovat.

Zatím naštěstí několik let úspěšně žiju s tím, že HAL vypínám a zakazuju.

[stativ]

V podstatě důvod, proč se na udev čeká než se spustí cokoli jiného je vytvoření základního /dev (console, null, zero). Ani to zařízení disku není potřeba pokud jsou potřebné věci v initrd.

Není to náhodou tak, že ty základní věci jako console tam už musí být před startem udevu? Pokud si vzpomínám, s prázdným /dev si jádro stěžuje, že can't open initial console

Minimálně v případě console máš nejspíš pravdu. To nic ale nemění na tom, že v současnosti coldplug připojuje úplně všechno, co je připojené předtím, než boot pokračuje. Přitom by stačilo to málo aby boot mohl pokračovat. Do doby než např. nastartují X-ka se pak detekují i věci jako je myš a klávesnice, flashka a další zbytečnosti.

Osobně si myslím, že za těch 6 sekund ani tak nemůže udev jako samotné jádro, které nahrává moduly.

Neřekl bych - nemůžu říct, jestli je to na všech distrech, ale v Debianu se moduly nahrávají až když je udev a podobné nastartovaný (samozřejmě kromě těch nutných pro start systému). Takže udev nastartuje s minimální konfigurací (jádro + pár modulů), pak systém bootuje dál a v určité fázi se natáhnou věci zapsané v /etc/modules. A ani tam nemusí být všechno, hodně modulů se natáhne až když jsou potřeba (USB mass storage atd.)

Možná ale udevu dlouho trvá rozhodnout se, jaký modul nahrát.

Já měl za to, že o nahrání modulu rozhoduje jádro, když je modul zapotřebí k zařízení, které se právě detekovalo, a udev jenom vytvoří odpovídající soubory v /dev

No, udev umožňuje nahrávat při hotplugu potřebné moduly (a případně provádět i skripty). Stoprocentní důkaz nemám, ale většinou je module autoloading zmiňován spolu s udevem. Např. Arch wiki: „udev loads kernel modules simultaneously, which can provide a speed increase during bootup.“. Gentoo wiki to neříká tak okatě, ale opět zmiňuje autoloading modulů v souvislosti s udevem. Podobně se o něm zmiňují i v LFS a Mandriva dokumentaci.

Tím neříkám, že to dělá udev, ale to, že to na mě tak působí.

Zatím naštěstí několik let úspěšně žiju s tím, že HAL vypínám a zakazuju.

Já už rezignoval.

[trekker.dk]

Minimálně v případě console máš nejspíš pravdu. To nic ale nemění na tom, že v současnosti coldplug připojuje úplně všechno, co je připojené předtím, než boot pokračuje. Přitom by stačilo to málo aby boot mohl pokračovat.

Otázka je, jak definuješ to málo, které stačí. Patří tam disk (ovladače řadiče a spol)? Když bootuješ ze sítě, tak ne.

Patří tam síť? Pokud bootuješ lokálně, tak ne. Pokud jsou části systému na síti (např. /usr/bin a spol.), tak už jo.

Takhle by se dalo pokračovat. Klávesnice může být potřeba, aby mohl zadat heslo k šifrovanému oddílu před bootem.

Pokud nevymyslíš způsob, jak nastavit, co je potřeba a co může počkat - tak, abys to mohl sdělit jádru - tak má jádro jedinou možnost a sice připojit všechno, co se nadetekovalo.

[petr_p]

Ovladače obsahují identifikátory podporovaných zařízení. Když si do jádra zakompilujete automatické zavádění modulů, tak jádro, vždy když najde nové zařízení na sběrnici, tak zavolá /proc/sys/kernel/modprobe a v argumentech mu předá alias zařízení. Tohle funguje bez udevu. Jádru se zařízení objevují a jádro zavádí moduly od určité rané verze 2.6 asynchronně.

Samozřejmě stejnou úlohu může zastat udev, který se o novém zařízení dozví od jádra přes netlink, alias si zjistí ze sysfs a nakonec stejně zavolá modprobe.

[stativ]

Ovladače obsahují identifikátory podporovaných zařízení. Když si do jádra zakompilujete automatické zavádění modulů, tak jádro, vždy když najde nové zařízení na sběrnici, tak zavolá /proc/sys/kernel/modprobe a v argumentech mu předá alias zařízení. Tohle funguje bez udevu. Jádru se zařízení objevují a jádro zavádí moduly od určité rané verze 2.6 asynchronně.

Samozřejmě stejnou úlohu může zastat udev, který se o novém zařízení dozví od jádra přes netlink, alias si zjistí ze sysfs a nakonec stejně zavolá modprobe.

Díky za osvětu.

[Josef Kufner]

V podstatě důvod, proč se na udev čeká než se spustí cokoli jiného je vytvoření základního /dev (console, null, zero). Ani to zařízení disku není potřeba pokud jsou potřebné věci v initrd.

Není to náhodou tak, že ty základní věci jako console tam už musí být před startem udevu? Pokud si vzpomínám, s prázdným /dev si jádro stěžuje, že can't open initial console

Před startem udevu je na / adresář /dev, který obsahuje základní sadu souborů pro případ, že by udev nenastartoval (jsou tam i disky a podobné věci). Jakmile udev nastartuje, tak mountne do /dev tmpfs a začne vytvářet všecky ty speciální soubory.

[trekker.dk]

No jasně, to jo. Ale moje otázka byla, jestli jádro vůbec nabootuje, když bude před startem udevu ten /dev úplně prázdný. Moje zkušenosti s tou výše zmíněnou hláškou naznačují, že ne.

[cronin]

Tak si říkám, že pod každými jadernými novinami jsou vždycky diskuse jen co se týče překladu a dalších estetických kravin místo toho aby se řešily důležitější věci, jako je devtmpfs.

Ide o to, ze tunajsie diskusie mozu mat dopad na preklad a ostatne "esteticke kraviny", zatial co na devtmpfs, otazky zivota, vesmiru a vobec, dopad asi mat nebudu.

[trekker.dk]

Když ti devtmpfs tak vadí, tak si ho vypni. Nikomu to neškodí, udělané je to dobře, tak proč to nezačlenit?

[stativ]

Vypínat ho nebudu, protože ho v jádře nemám.

[kralyk z abclinuxu]

Vzhledem k tomu, že 32 bitů pro jakýkoliv stroj s více než 1 GB paměti znamená HIGHMEM, ne-embedded stroje, na kterých by dnes měla běžet 32bitová jádra, v podstatě tvoří prázdnou množinu. Bohužel linuxová distra nedostatečně propagovala 64bitová jádra pro 32bitové distribuce; i když čistých 64 bitů je lepší, i tak by bylo sakra lepší, kdyby lidi používající 32 bitů kvůli kompatibilitě měli rozumnější alternativu.

Hehe, tohle číst Jardík, tak klekne na koberec a několikrát skloní hlavu ve směru Mekky Helsinek

[trekker.dk]

Na druhou stranu minule se psalo něco o tom, že 64bitová jádra byla v jednom ohledu pomalejší než 32bitová