Jaderné noviny - 2. 4. 2008

28. 5. 2008 | Jirka Bourek | Jaderné noviny | 3190×

Aktuální verze jádra: 2.6.25-rc8. Citáty týdne: Linus Torvalds, Al Viro. Směrem k lepší škálovatelnosti přímého I/O. UBIFS - nový souborový systém pro flash. Odkud se vzalo 2.6.25.

Obsah

• Aktuální verze jádra: 2.6.25-rc8
• Citáty týdne: Linus Torvalds, Al Viro
• Směrem k lepší škálovatelnosti přímého I/O
• UBIFS
• Odkud se vzalo 2.6.25

Aktuální verze jádra: 2.6.25-rc8

Aktuální vývojové jádro je 2.6.25-rc8, vydané 1. dubna. Je v něm mnoho oprav a bylo postaráno o některé z nejodpornějších zbývajících regresí; lze si představit, že by to mohl být poslední -rc před závěrečným vydáním 2.6.25. Detaily vizte v oznámení, spoustu detailů najdete v kompletním changelogu.

Současná verze -mm stromu je 2.6.25-rc8-mm1. Nedávné změny v -mm zahrnují sadu IDE patchů, nový "speciální" příznak stránky (vizte níže), kontrolní skupinu whitelistu zařízení, podporu pro zapisovatelný mmap() pro FUSE, patche infrastruktury ladění objektů a spoustu oprav.

Citáty týdne: Linus Torvalds, Al Viro

Tohle má "vysokou" prioritu, protože mě manželka zabije, jestli nebude mít svá videa. A přehrávač od Adobe nejde se současným rawhide nainstalovat kvůli nějakým problémům s knihovnami.

-- Linus Torvalds nahlásil chybu.

Argh. Omlouvám se za svou nedbalost při flamování. Závěr platí.

-- Slušnost podle Alexandera Vira.

Směrem k lepší škálovatelnosti přímého I/O

Linuxoví nadšenci rádi poukazují na to, jak je systém škálovatelný; Linux běží na všem od kapesních zařízení po superpočítače s několika tisíci procesory. O čem mluví o něco méně, je, že v high-endu je skutečná škálovatelnost systému omezena druhem zátěže, která je provozována. Vědecké výpočetní úlohy náročné na CPU umí velké systémy využít velmi dobře, ale zátěže s převážně databázovými operacem škálují podstatně hůře. Je velký zájem, aby velké databázové systémy fungovaly lépe, ale zatím to byl obtížný úkol. Zdá se však, že Nick Piggin přišel s dalším logickým krokem v tomto směru s relativně přímočarými změnami ve vnitřní [core] správě paměti.

Po nějakou dobu Linux podporoval přímé I/O z uživatelského prostoru. I toto je technologie, která přispívá ke škálovatelnosti: cílem je ušetřit procesorový čas a paměť tím, že se vyhneme kopírování dat přes jádro během jejich cesty mezi aplikací a diskem. S dostatečnou snahou programátorů by aplikace měla být díky nejlepšímu povědomí o svých vlastních vzorech přístupu k datům schopná cachovat efektivněji, než to umí jádro; přímé I/O umožňuje cachování bez dodatečné režie. Přesně tento druh snahy programátorů je použit ve velkých databázových systémech, které kvůli tomu výrazně používají přímé I/O. Ve významném rozsahu nahrazují jaderné stránkovací algoritmy vlastním specializovaným kódem.

Když je jádro požádáno, aby vykonalo přímou I/O operaci, jednou z prvních věcí, které musí udělat, je přišpendlit [pin] všechny relevantní stránky z uživatelského prostoru do paměti a najít jejich fyzické adresy. Funkce, která tento úkol provede, je get_user_pages():

int get_user_pages(struct task_struct *tsk, 
                   struct mm_struct *mm, 
                   unsigned long start,
                   int len,
                   int write,
                   int force,
                   struct page **pages, 
                   struct vm_area_struct **vmas);

Úspěšné volání get_user_pages() přišpendlí len stránek do paměti, tyto stránky začínají v uživatelském prostoru na adrese start tak, jak jsou viděny daným mm. Adresy relevantních ukazatelů na struct page se uloží do pages a s nimi spojené ukazatele na VMA do vmas, pokud není NULL.

Tato funkce funguje, ale má problém (kromě toho, že je to dlouhý, pokřivený a komplexní nečitelný hnus): potřebuje, aby volající držel mm->mmap_sem. Jestliže dva procesy provádějí přímé I/O se stejným adresovým prostorem - běžná situace u velkých databázových systémů - budou o tento semafor soupeřit. Takový zápas o zámek rychle zabíjí škálovatelnost; jakmile musí procesory čekat jeden na druhý, jejich přidáváním se mnoho nezíská.

Když se narazí na takovýto problém škálovatelnosti, jsou dva běžné přístupy, které se dají použít. Jedním je jemnější zamykání, kde každý zámek pokrývá menší část jádra. Rozdělování zámků probíhá od doby, kdy byl poprvé vytvořen velký jaderný zámek [Big Kernel Lock], což je nejlepší příklad hrubozrnného zamykání. Zlepšení dosažitelné jemnějším zamykáním je ale omezené a přidávání více zámků přináší větší komplexitu a více příležitostí, jak vytvořit deadlock.

Druhý přístup je zamykání úplně odstranit; v posledních letech to byla, co se vylepšování škálovatelnosti týče, preferovaná cesta. Příkladem je práce, která byla odvedena na read-copy-aktualizaci [RCU]. A Nick se rozhodl, že get_user_pages() vylepší tímto směrem.

Jádrem Nickova pozorování je to, že když je get_user_pages() zavolán na běžnou stránku v uživatelském prostoru, která je již přítomna v paměti, čítač referencí této stránky může být zvýšen bez nutnosti držet předtím jakékoliv zámky. Jak se tak stává, tohle je nejčastější případ. Za tímto pozorováním je ale pár podmínek. Jedna je, že není možné procházet tabulky stránek, pokud jsou ve stejném čase modifikovány. Aby se zajistilo, že se tohle nestane, jádro musí předtím, než zamíří do stromu tabulky stránek, zakázat přerušení na současném procesoru. I tak může jádro bez držení semaforu mmap_sem procházet pouze tabulky stránek právě běžícího procesu.

Bezzámková operace také nebude fungovat pokaždé, když jsou zapojeny stránky, které nejsou "normální". Některé případy - například nepřítomné stránky - se snadno dají detekovat podle informací nalezených v samotných tabulkách stránek. Nicméně jiné jako například situace, kdy je relevantní část adresového prostoru mapovaná do paměti zařízení pomocí mmap(), nejsou zcela zjevné pohledem na záznamy v asociované tabulce stránek. V takovém případě se jádro musí podívat zpátky na řídící vm_area_struct (VMA) strukturu, aby zjistilo, co se děje. A to se bez držení mmap_sem provést nedá. Takže to vypadá, že není možnost, jak bez držení zámku zjistit, jestli je možná operace bez držení zámku.

Řešením je v tomto případě zužitkovat jeden z volných bitů v záznamu v tabulce stránek. PTE drží pro stránku, která je přítomna v paměti, fyzickou adresu rámce stránek. V takových adresách je spodních 12 bitů (platí pro architektury s 4096B stránkami) vždy nulových, takže mohou být vyčleněny pro jiné účely. Jedním z nich je indikace, jestli je stránka vůbec přítomna v paměti; další indikují zapisovatelnost, jestli je to stránka v uživatelském prostoru, jestli je dirty [nečistá] atd. Nickův patch bere jeden z mála zbývajících bitů, nazývá ho PAGE_BIT_SPECIAL a indikuje jím "speciální" stránky. To jsou stránky, které z nějakého důvodu nemají okamžitě přístupnou struct page, která je k nim přiřazená. Označení "speciálních" stránek v tabulce stránek může pomoci na mnoha místech; jedním z nich je možnost určit, jestli je pro danou stránku možné bezzámkové get_user_pages(). Nickův návrh se jmenuje fast_gup():

int fast_gup(unsigned long start, int nr_pages,
             int write, struct page **pages);

Tato funkce má mnohem jednodušší rozhraní než get_user_pages(), protože se nezabývá mnoha případy, se kterými si umí get_user_pages() poradit. Funguje pouze s adresovým prostorem současného procesu a neumí vrátit ukazatele na VMA struktury. Nicméně umí iterovat přes sadu tabulek stránek, testovat každou stránku na přítomnost, zapisovatelnost a "nespeciálnost" a inkrementovat počet referencí každé stránky (a tím je přišpendlit do fyzické paměti) procesu. Pokud funguje, je velmi rychlá. Pokud ne, vezme zpět to, co udělala, a vrátí se k get_user_pages(), která všechno provede pomalým starým způsobem.

Jak moc se tohle vyplatí? Nick tvrdí, že došlo k 10% zlepšení výkonnosti při "OLTP zátěži" (asi jedna z těch nepopsatelných sad benchmarků) na DB2 DBMS systému od IBM na dvouprocesorovém (osm jader) stroji. Zlepšení výkonnosti by prý mohlo být větší na větších systémech. Nicméně i když zůstane "jenom" na 10 %, tahle práce je pro tento druh zátěže zjevně krok správným směrem.

UBIFS

Zdá se, že plynulý nárůst využití na flash paměti založených paměťových zařízení transformuje některé části průmyslu úložných zařízení. Flash má nad rotujícím magnetickým médiem mnoho výhod: je menší, nemá pohyblivé části, vyžaduje méně energie, dělá méně hluku, umožňuje skutečně náhodný přístup a má potenciál být rychlejší. Na druhou stranu má své vlastní výstřednosti - na flash založená zařízení operují s mnohem většími bloky dat: 32 kB nebo více. Přepsání části bloku vyžaduje výmazový cyklus na celém bloku (což může být dost pomalé) a zapsání celého obsahu. Počet možných výmazů je limitován, potom blok začne poškozovat data, která jsou na něm uložena; tento limit je dost nízký na to, aby přivodil předčasný konec života daného zařízení, obzvlášť pokud je opakovaně přepisován stejný blok. A tak dál.

Existuje mnoho přístupů, jak zajistit, aby na flash založená zařízení fungovala dobře. Mnoho z nich, například USB disky, obsahují software "flash překladová vrstva" [flash translation layer, FTL]; tato vrstva provádí potřebné impedanční přizpůsobení, takže flash zařízení vypadá jako běžné blokové zařízení s malými sektory. Vnitřně FTL udržuje mapu mezi logickými bloky a fyzickými výmazovými bloky [erase blocks], která umožňuje vyrovnávání opotřebení - přepisovací operace se distribuují na celé zařízení, takže se žádný výmazový blok neopotřebuje dříve, než přijde jeho čas - i když mnoho pozorovatelů zpochybňuje, že low-endová flash zařízení se s tímhle obtěžují. Použití FTL vrstev zjednodušuje život zbytku systému, ale není to nutně cesta, která z hardwaru umožní vytěžit co největší výkon.

Pokud se můžete dostat přímo k zařízení bez toho, aby se vám do cesty pletla FTL, je možné vytvořit souborové systémy, které v sobě zahrnují povědomí o tom, jak flash funguje. Většina našich současných souborových systémů je navržena pro rotující úložná zařízení s tím výsledkem, že se těžce snaží minimalizovat časově náročné operace, jako je posun hlaviček. O takové záležitosti se souborový systém pro flash zařízení nemusí starat, ale musí se místo toho zabývat věcmi, jako jsou výmazové bloky. Takže nejlepší využití flash zařízení vyžaduje souborový systém, který byl napsán přímo pro taková zařízení.

Hlavní souborový systém pro flash zařízení je v Linuxu starobylý JFFS2. Tento souborový systém funguje, ale byl navržen pro zařízení, která byla poněkud menší než ta, která jsou dostupná dnes. Kvůli tomu, že JFFS2 musí při připojování [mount time] udělat věci, jako je rekonstrukce [rebuild] celé adresářové struktury, může být na velkých zařízeních pomalý - platí i pro relativně malé hodnoty "velké" z pohledu standardu roku 2008. Na JFFS2 je momentálně nahlíženo tak, že se blíží ke konci svého času.

Současnější alternativa je LogFS. Tato práce nicméně zůstává nedokončena a vývoj byl v nedávné době relativně pomalý; LogFS ještě nebyl vážně uvažován pro začlenění do hlavní řady jádra. Jeho mnohem aktuálnějším soupeřem je UBIFS; tento kód je téměř ve stavu dokončení a jeho vývojáři se vší vážností žádají o revize.

UBIFS závisí na UBI vrstvě, která byla začleněna do 2.6.22. UBI ("neřazené obrazy bloků" [unsorted block images]) technicky není FTL, ale provádí mnoho stejných funkcí. Srdcem UBI je překladová tabulka, která mapuje logické výmazové bloky (LEB) na fyzické výmazové bloky (PEB). Software, který používá UBI k přístupu k flash zařízení, tedy vidí jednoduchou sadu sekvenčně řazených bloků, které se zdánlivě nehýbají. Ve skutečnosti se při přepisu LEB nová data umisťují na jiné místo ve fyzickém zařízení, ale vyšší vrstva o tom nic neví. Díky tomu UBI odstraňuje pro vyšší vrstvy problémy jako vyrovnávání opotřebení a vyhýbání se špatným blokům. UBI se také stará o provádění časově náročných výmazových operací v pozadí, pokud je to možné, takže vyšší vrstvy nepotřebují při zápisu bloku čekat.

Jeden malý problém UBI spočívá v tom, že informace o mapování logický-na-fyzický jsou uloženy v hlavičce každého výmazového bloku. Takže když UBI vrstva inicializuje flash zařízení, musí přečíst hlavičku každého bloku, aby bylo možné vystavět mapovací tabulku v paměti; tato operace zjevně potřebuje čas - pro 1GB flash zařízení je tento čas strávený inicializací tolerovatelný; v budoucnosti, až budeme bootovat laptopy z řádově TB disků, bude lineární scan problém. Vývojáři UBIFS si jsou této záležitosti vědomi, ale věří, že může být vyřešena na úrovni UBI bez vlivu na kód souborového systému na vyšší úrovni.

Díky využití UBI se vývojáři UBIFS nemusí starat o některé aspekty návrhu souborového systému pro flash zařízení. Jiné problémy ale zůstávají. Například velké výmazové bloky poskytované flash zařízeními vyžadují od souborového systému sledování dat na pod-blokové úrovni a provádění občasného sběru odpadu [garbage collection]: shromáždění užitečných informací do nového bloku, aby bylo možné použít "mrtvé" místo. Sběr odpadu společně s potenciálem bloků přestat fungovat způsobuje, že správa místa na flash zařízeních je ošidná: uvolnění místa může předtím potřebovat víc místa a není způsob, jak předem zjistit, kolik místa se ve skutečnosti uvolní, až se celá akce dokončí.

V tomto případě je správa místa u UBIFS z několika důvodů ještě ošidnější. Jedním důvodem je to, že stejně jako mnoho ostatních souborových systémů pro flash UBIFS provádí transparentní kompresi dat. Druhým je to, že na rozdíl od JFFS2 UBIFS poskytuje plnou podporu pro zpětný zápis [writeback], čímž se datům umožňuje zůstat v cache předtím, než se zapíší na fyzické médium. Zpětný zápis poskytuje velké vylepšení výkonu a redukuje opotřebení zařízení, ale může vést k velkým problémům, pokud se souborový systém zaváže k zápisu víc dat, než na kolik má k dispozici místo.

Stejně jako LogFS používá UBIFS k rovnoměrnému rozptýlení změn na disku strukturu "toulajícího se stromu" [wandering tree]. UBIFS také používá žurnál, aby minimalizoval počet přepisů uzlů vyšší úrovně ve stromu.

Nejnovější verze UBIFS vyvolala požadavek na srovnání s LogFS. Následná diskuze nebyla... zcela technická, ale vyplynulo z ní několik jasných stanovisek. UBIFS je v mnohem dokončenějším stavu a zdá se, že v současnosti se chová o něco lépe. LogFS je mnohem menší, vyhýbá se lineárnímu zkoumání zařízení během bootu a je schopné fungovat (s nějakými ohledy na flash) přes FTL. Co je lepší, je otázka, kterou autor článku není momentálně schopen zodpovědět; co se zdá být jasné, je, že rostoucí konkurence mezi těmito projekty má potenciál inspirovat na obou stranách v budoucnosti velká vylepšení.

Odkud se vzalo 2.6.25

Linux Foundation zveřejnila studii, kterou sepsali Greg Kroah-Hartman, Amanda McPherson a Jonathan Corbet a ve které shrnují původ kódu začleněného do jádra od 2.6.11 do 2.6.24. Podívejme se, co se s procesem stalo v tomto vývojovém cyklu.

V době psaní tohoto článku bylo do 2.6.25 začleněno 12 269 různých sad změn - nový rekord. Předchozí rekord (2.6.24 s pouhými 10 353 sadami změn) byl překonán o téměř 2000. Do 2.6.25 se zapojilo 1174 vývojářů, z toho 419 přispělo jedním patchem. Tito vývojáři pracovali všehovšudy pro 159 zaměstnavatelů (takových, které byl autor schopen identifikovat). Změny přidaly 766 979 řádků kódu a odstranily 399 791, takže celkový růst je 367 188 řádků.

Zde je aktualizovaná verze grafu, který autor rád ukazoval v minulých letech:

Graf ukazuje kumulativní součet změněných řádků během času s přidanými daty vydání jádra. Efekt politiky začleňovacích oken lze rozpoznat ze schodovitého tvaru grafu. Zdá se, že schody se zvyšují, ale čas mezi vydáními se také trochu zvětšil, takže celkové tempo změn zůstává přibližně stejné. Toto tempo je vysoké, přes 5 miliónů změněných řádků - to je více než polovina všech - za poslední dva roky.

Takže kdo tuhle práci udělal? Tady je tradiční tabulka nejaktivnějších vývojářů v 2.6.25:

Nejaktivnější vývojáři 2.6.25

Podle sad změn Bartlomiej Zolnierkiewicz 304 2,5 % Patrick McHardy 219 1,8 % Adrian Bunk 212 1,7 % Ingo Molnár 207 1,7 % Paul Mundt 204 1,7 % Greg Kroah-Hartman 171 1,4 % Jesper Nilsson 166 1,4 % Thomas Gleixner 164 1,3 % Pavel Emelyanov 155 1,3 % Harvey Harrison 148 1,2 % Herbert Xu 136 1,1 % Mauro Carvalho Chehab 136 1,1 % Roland McGrath 134 1,1 % David Woodhouse 134 1,1 % Al Viro 132 1,1 % Michael Krufky 128 1,0 % Glauber Costa 127 1,0 % David S. Miller 112 0,9 % Andrew Morton 109 0,9 % Takashi Iwai 104 0,8 %

Podle změněných řádků Jesper Nilsson 34407 3,7 % David Howells 29733 3,2 % Eliezer Tamir 26153 2,9 % Adrian Bunk 21998 2,4 % Kumar Gala 19753 2,2 % Paul Mundt 18918 2,1 % Jiří Slabý 18002 2,0 % Glenn Streiff 16597 1,8 % Auke Kok 13939 1,5 % David Gibson 11255 1,2 % Michael Chan 11254 1,2 % Ingo Molnár 10679 1,2 % James Bottomley 9907 1,1 % Christoph Hellwig 9784 1,1 % Mauro Carvalho Chehab 9332 1,0 % Bartlomiej Zolnierkiewicz 9108 1,0 % Thomas Gleixner 9104 1,0 % Patrick McHardy 8563 0,9 % Michael Krufky 8195 0,9 % Takashi Iwai 7825 0,9 %

V seznamu jsou některá známá jména, ale také nějaká nová. Bartlomiej Zolnierkiewicz přispěl více sadami změn než kterýkoliv jiný vývojář; jeho práce se omezuje výhradně na IDE subsystém. Patrick McHardy pracuje v oblasti síťování, nejvíce (ale ne exkluzivně) v netfilter subsystému. Andrian Bunk pokračuje ve vytváření malých oprav v celém stromě a v neúnavném honu na nepoužívaný kód vhodný k odstranění. Ingo Molnár zůstává zaneprázdněn ve své nové roli jednoho ze správců x86; mnoho jeho změn také obsahuje práce na plánovači. Paul Mundt spravuje architekturu SuperH.

Tento obraz je poněkud odlišný, pokud se vezme v úvahu, kolik řádek kódu bylo změněno. Práce, kterou přispěl Jesper Nillson, byla odvedena v architektuře CRIS. David Howells pracuje v celém stromě; jeho největší příspěvek bylo přidání kódu architektury MN10300. Eliezer Tamir přispěl síťovým ovladačem bnx2x (Broadcom Everest) a Kumar Gala pracuje s architekturou PowerPC.

V seznamu zaměstnavatelů spojených s touto prací je relativně málo změn (prosím pamatujte, že čísla spojená se zaměstnavateli jsou nutně přibližná):

Nejaktivnější zaměstnavatelé v 2.6.25

Podle sad změn (žádný) 1918 15,6 % Red Hat 1562 12,7 % (neznámý) 1232 10,0 % Novell 826 6,7 % IBM 758 6,2 % Intel 566 4,6 % SWsoft 266 2,2 % Oracle 250 2,0 % Astaro 219 1,8 % (školství) 218 1,8 % Renesas Technology 217 1,8 % Movial 213 1,7 % Axis Communications 166 1,3 % linutronix 166 1,3 % Freescale 132 1,1 % Qumranet 127 1,0 % Google 124 1,0 % Analog Devices 121 1,0 % SGI 118 1,0 % (konzultant) 111 0,9 %

Podle změněných řádek (žádný) 132117 14,4 % (neznámý) 117993 12,8 % Red Hat 103188 11,2 % IBM 59249 6,4 % Freescale 52336 5,7 % Intel 46466 5,1 % Novell 41790 4,5 % Axis Communications 39382 4,3 % Broadcom 37789 4,1 % Renesas Technology 23704 2,6 % Movial 22327 2,4 % Hansen Partnership 12076 1,3 % Marvell 11661 1,3 % Oracle 11214 1,2 % linutronix 10649 1,2 % Astaro 10167 1,1 % (konzultant) 9342 1,0 % SWsoft 7849 0,9 % MontaVista 7517 0,8 % (školství) 7353 0,8 %

Jako vždy se také lze podívat na to, kdo aplikuje Signed-off-by hlavičku na kód, kterého není autorem. Tyto hlavičky ilustrují řetěz důvěry, přes který se kód dostává do jádra. Pro 2.6.25 jsou největšími schvalovateli patchů tito:

Sign-offs v jádře 2.6.25

Podle vývojářů Andrew Morton 1513 12,2 % David S. Miller 1444 11,7 % Ingo Molnár 1153 9,3 % Thomas Gleixner 991 8,0 % John W. Linville 614 5,0 % Jeff Garzik 468 3,8 % Mauro Carvalho Chehab 447 3,6 % Greg Kroah-Hartman 345 2,8 % Paul Mackerras 307 2,5 % James Bottomley 306 2,5 % Jaroslav Kysela 292 2,4 % Linus Torvalds 249 2,0 % Len Brown 220 1,8 % Russell King 197 1,6 % Takashi Iwai 170 1,4 % Avi Kivity 167 1,4 % Bryan Wu 132 1,1 % Herbert Xu 123 1,0 % Roland Dreier 121 1,0 % Kumar Gala 107 0,9 %

Podle zaměstnavatele Red Hat 4185 33,8 % Google 1516 12,2 % linutronix 994 8,0 % (žádný) 883 7,1 % IBM 689 5,6 % Novell 611 4,9 % (neznámý) 534 4,3 % Intel 468 3,8 % Hansen Partnership 306 2,5 % Linux Foundation 254 2,1 % (konzultant) 242 2,0 % Qumranet 170 1,4 % Oracle 126 1,0 % SGI 126 1,0 % Freescale 121 1,0 % Cisco 121 1,0 % Analog Devices 115 0,9 % Astaro 107 0,9 % Renesas Technology 82 0,7 % Movial 78 0,6 %

Někteří z těchto vývojářů jsou docela zaměstnaní; Andrew Morton podepisuje více než dvacet patchů každý den včetně víkendů. Vrátní jádra stále pracují pro relativně málo firem, protože prvních deset zaměstnavatelů má na kontě přes 75 % neautorských podpisů.

Shrnuto - všechna tato čísla malují obraz vývojového procesu, který je zdravý a pokračuje v nastaveném rychlém tempu. Zahrnuje práci od zvětšující se komunity vývojářů, kteří jsou schopni pracovat vysoce spolupracujícím způsobem i přes to, že jejich zaměstnavatelé jsou zapřísáhlí nepřátelé. Je jenom málo podobných projektů.

(Díky Gregu Kroah-Hartmanovi za pomoc při vytváření těchto statistik.)

       

Komentáře

[Prcek]

Peknej obrazek tucnaka s novinama, to je nejak novota, ne?

[Robert Krátký]

To je tučňák, který čte LWN

[cronin]

S tmavym CSS su ale okraje tucniaka skaredo zubate.

[Robert Krátký]

Vím, neměl jsem čas to pilovat. Kdyby se někomu chtělo, rád vylepšenou verzi použiji.

[petr_p]

Příloha:

• lwntux.png (3343 bytů)

70 × 80 px PNG s průhledností, 3,3 KiB.

[cronin]

Super, vdaka.

Hehe, podla "open source modelu" si mal poslat iba patch.

[petr_p]

Vidím, že se líbí. Nejtěžší bylo zjistit, jak se to v GIMPu dělá. Takže tady je postup:

Označit pozadí vybráním spojitých oblastí podle barvy, zvětšení výběru o jeden dva pixely, abychom postihly do bíla aliasovanou hranu, a barvovou funkcí „Barva do alfy“ převést bílou v takto vybraném prostoru na průhlednost.

[Leoš Literák]

Ty prilohy jsou ale sikovna featurka

[trekker.dk]

Alexandr Viro? Tak takhle to jméno vidím prvně

Btw. u jeho citátu vypadl odkaz na originál - http://lwn.net/Articles/276159/

[Robert Krátký]

Alexandr Viro?

No jo, jedno písmenko mi vypadlo...

[trekker.dk]

No spíš jsem chtěl říct, čeho se člověk nedočká - nejdřív zjistí, že příjmení Grega KH není KH (kupodivu), pak se z nějakýho chlapa vyklube ženská a teď zase Al není Al.

Že v někde chybí písmenko, to mě teda opravdu nenapadlo

[ondrejch]

Ahoj experti,

mam eeePC a na flasce mam zasirfrovany home (luks+dmcrypt). Jaky FS pouzit nad dmcrypt, zalezi na tom? Puvodne jsem pouzil oblibene XFS, ale temer kazdy druhy reboot se XFS rozsypalo, coz mne znacne udivilo. Preformatovel jsem dmcryptovany svazek na EXT3 a od te doby nemam problem.

Porad me ale vrta v hlave, 1) jaktoze XFS blazni; 2) jestli je EXT3 nejlepsi volba.

diky za pripadne komentare, O.