Portál AbcLinuxu, 7. května 2025 22:17
Jaderné noviny - 33-37/2008
Články
-
Jaderné noviny - 33-37/2008
2.6.27-rc3, věci se skutečně zklidnily. Hierarchická struktura Tux3. Výkonnost 64bitových aplikací při vytváření vláken. AXFS, pokročilý souborový systém s vykonáním na místě. 2.6.27-rc4, "Náhodné záležitosti všude". 2.6.27-rc5, "Opravování regresí". Tux3 se chová jako souborový systém. 2.6.27-rc6, "Věci se zklidňují".
Obsah
Následující obsah je © KernelTrap.
Citát: Bezpečnost není absolutní
Bezpečnost není absolutní. Stejně jako teroristé zvítězí, když donutí Bílý dům roztrhat ústavu a nás žít v neustálém strachu, je zbytečné nutit lidi, aby instalovali software, který jejich server zpomalí tak otřesně, že nebude možné nic udělat.
Theodore Ts'o, zpráva z 8. srpna 2008 na Linux kernel mailing list.
2.6.27-rc3, věci se skutečně zklidnily
link
13. srpna, originál
Věci se skutečně zklidnily a snad jsme v -rc3 vyřešili spoustu regresí, začal Linus Torvalds oznámení linuxového jádra 2.6.27-rc3. Napsal, že značná část velikosti patche pochází ze začlenění nového bezdrátového ovladače ath9k, mnoho ze zbytku je kvůli přejmenování mnoha include souborů architektur ARM, AVR32 a m68lnommu. Linus dále napsal:
Všechny malé změny jsou tam, kde se opravovaly regrese a kde jsou další náhodná vylepšení. A jsou všude.
Citát: Benchmark souborového systému
Jakýkoliv benchmark bude benchmarkem OS stejně tak, jako bude benchmarkem souborového systému. Je dost těžké tyto dva oddělit. ZFS se nejlépe testuje na OpenSolarisu. UFS se nejlépe testuje na FreeBSD, EXT3 na Linuxu a HAMMER se samozřejmě nejlépe testuje na DragonFly.
Matthew Dillon, zpráva z 13. srpna 2008 na Dragonfly BSD kernel mailing list.
Hierarchická struktura Tux3
link
14. srpna, originál
Je čas udělat krok zpátky a popsat, co jsem implementoval, informoval Daniel Phillips o svém souborovém systému Tux3. Poskytl jednoduchý ASCII diagram, který detailně ukazuje hierarchickou strukturu souborového systému a popisuje každý z jeho prvků. O jednom z nich poznamenal: Tabulka svazku je nový přídavek, nepatří mezi hlavní cíle Tux3, ale je to hezká vlastnost vzhledem k tomu, že je v podstatě zadarmo. V jednom svazku Tux3 může být napěchován libovolný počet oddělených souborových systémů, které jsou indexovány jednoduše celočíselným parametrem v době připojování. Lidé říkají, že se jim tento nápad líbí a nezavádí žádnou významnou komplexitu, takže jde dovnitř. Daniel pokračoval.
Každý svazek má metablok, který ukazuje na řetěz dopředných záznamů [forward log chain] svazku, tabulku verzí, která popisuje hierarchický vztah mezi verzemi (snapshoty), tabulku atime, která se stará o tuto strašnou prastarou vlastnost Unixu, a tabulku inodů, která obsahuje soubory a jejich atributy. ...
Verzování se provádí na třech místech - verzované ukazatele na b-strom atime, verzované rozsahy v b-stromě dat souborů a verzované atributy v tabulce inodů [...] Všimněte si nepřítomnosti žurnálu, jeho funkce je poskytována prvky dopředných záznamů, které jsem popsal ve vlákně o Hammeru (a o kterých napíšu oddělený článek).
Citát: Linux bude mít podobné problémy
Jestliže webové prohlížeče, kancelářské balíky a poštovní klienty pro Windows mají určitý druh slabin, dá se bezpečně předpokládat, že stejné programy budou mít v Linuxu podobné problémy.
Rik van Riel, zpráva z 17. srpna 2008 na Linux kernel mailing list.
Výkonnost 64bitových aplikací při vytváření vláken
link
18. srpna, originál
Nedávná diskuze na mailové konferenci Linux Kernel se zabývá tím, že vícevláknové 64bitové aplikace trpí drastickým zpomalením v pthread_create, když zásobníky vlákna vyčerpají 4 GB. Ingo Molnár přišel s vysvětlením problému: Použití MAP_32BIT pro zásobníky v 64bitových programech bylo bohužel vytvořeno bez předvídání toho, co by se stalo ve správě paměti, když zásobník vlákna vyčerpá 4 GB. Problém je v tom, že MAP_32BIT se používá jak jako hack pro výkonnost 64bitových aplikací, tak jako mechanismus pro ABI kompatibilitu 32bitových aplikací. Nemůžeme tedy jenom v jádře MAP_32BIT nebrat na vědomí - znefunkčnili bychom 32bitové aplikace a/nebo 32bitové knihovny v kompatibilním režimu.
Původní hlášení uvádělo, že jakmile sdílený zásobník překročí velikost 4 GB, vytváření vláken může trvat až 10 milisekund, což je zpomalení popsané jako zcela neakceptovatelné.
Ingo vytvořil patch zavádějící nový příznak MAP_STACK pro glibc, který lze použít místo MAP_32BIT a vyhnout se tak zavádění 32bitových omezení do 64bitových programů. Poznamenal, že glibc se může na tento nový příznak přepnout okamžitě - jádro ho bude ignorovat. Nový příznak byl rychle začleněn do upstreamu a pro glibc se plánují změny.
Citát: Možná jsem příliš pesimistický
C standard bude nakonec podporovat souběžnost (pracují na tom) a téměř nevyhnutelně to bude hromada smrdících ho*en a my místo toho budeme dál používat inline asm v gcc, ale potom budou lidé od gcc ignorovat naše stížnosti, když rozbijí překladač, a budou říkat, že bychom měli používat smrdící hromadu ho*en, která je zabudovaná.
Ne, návrh jsem neviděl a možná jsem příliš pesimistický, ale jsem si docela jistý, že tohle je oblast, kde (a) jádro potřebuje víc podpory než většina běžných pthread modelů a (b) kde jakýkoliv návrh od komise jednoduše nebude moc dobrý, protože budou muset uspokojit každého. Ach jo.
Linus Torvalds, zpráva z 21. srpna 2008 na Linux kernel mailing list.
AXFS, pokročilý souborový systém s vykonáním na místě
link
21. srpna, originál
Rád bych požádal o první kolo revizí svého souborového systému AXFS, začal Jared Hulbert a popsal svůj nový Pokročilý XIP souborový systém pro Linux. XIP je zkratka pro eXecute-In-Place (vykonat na místě). Souborový systém obdržel docela dost pozitivní zpětné vazby. Jared nabídl následující popis:
Je to jednoduchý komprimovaný souborový systém pouze pro čtení jako Squashfs a cramfs. AXFS je zvláštní tím, že také umožňuje aplikacím vykonání na místě. Je to velké zlepšení oproti XIP patchům pro cramfs, které tu poletují už léta. Největší zlepšení je způsob, jakým AXFS umožňuje každé stránce, aby byla nebo nebyla XIP.
Uživatel nejprve shromáždí informace o tom, ke kterým stránkám v komprimovaném obrazu se přistupuje v každé mmap()ované oblasti z /proc/axfs/volume0. Tento 'profil' je potom použit jako vstup pro vytvářeč obrazů. Výsledný obraz obsahuje relevantní stránky nekomprimované a XIP. Výsledkem je menší paměťová náročnost a rychlejší starty.
Citát: Dost dobré není nikdy dost dobré
"Dost dobré" není nikdy dost dobré ;). Jaká je ideální implementace? Pojďme implementovat tu.
Andrew Morton, zpráva z 24. srpna 2008 na Linux kernel mailing list.
2.6.27-rc4, "Náhodné záležitosti všude"
link
25. srpna, originál
Další týden, další -rc, začal Linus Torvalds oznámení jádra Linuxu 2.6.27-rc4 a pokračoval, tentokrát dirstatu téměř vévodí přidání ovladače musb, který řídí MUSB a TUSB řadiče integrované do omap2430 a davinci. To společně s odstraněním USB ovladače auerswald (nahrazen libusb verzí) tvoří více než polovinu velikosti patche a většina uživatelů si toho zjevně nevšimne. Linus dodal:
Kromě těchto velkých aktualizací USB jsou zde nějaké aktualizace architektur (blackfin a ia64), aktualizace síťových a vstupních ovladačů, aktualizace ovladačů pro XFS a UBIFS. Většina jsou jenom náhodné záležitosti všude možně, nejlépe je pravděpodobně popisuje přiložený zkrácený log. Mnoho regresí by mělo být smeteno ze stolu, ale více jich zůstává...
Citát: Každý den, pro zábavu
Ze slabého programátora se stane dobrý čtením kódu a psaním kódu - každý den, pro zábavu.
Daniel Phillips, zpráva z 31. srpna 2008 na Tux3 mailing list.
2.6.27-rc5, "Opravování regresí"
link
1. září, originál
Linus Torvalds oznámil jádro 2.6.27-rc5 s poznámkou, že jeho "vydání jednou týdně" přichází obvykle každých osm dní. Dodal, že jádrem toho všeho jsou aktualizace configu, společně s arm a powerpc jsou na čelních příčkách této skupiny. Pak dodal:
Aktualizace configu se na diffu podílí ze tří čtvrtin a pokud nepoužíváte detekci přejmenování, přesouvání include souborů pro blackfin je v podstatě zbytek. Za těmito triviálními (ale velkými) změnami se schovává spousta malých změn, které snad opravují mnoho regresí.
Nejvíc vzrušující (no, aspoň pro mě osobně - můj život je zjevně pěkně nudný) bylo to, jak jsme odchytili nějaká přetečení zásobníku, která totálně poškodila některé základní datové struktury vláken. Vzrušující je to proto, že tohle se nám už dlouho nestalo. Příčinou se ukázalo být poněkud příliš optimistické zvýšení maximální hodnoty NR_CPUS, ale také jsme se díky tomu podívali na spotřebu zásobníku obecně. To zahrnuje věci jako patch pro gcc, aby se opravilo šílené užívání zásobníku pro vararg funkce na x86-64. Tahle chyba by ale zasáhla jen někoho, kdo by byl příliš velký dobrodruh a nastavil velkou 4096 CPU konfiguraci. Zbytek opravených regresí je poněkud suchopárnější.
Citát: Pečlivá analýza
Některé zabezpečené protokoly jako SSH posílají zašifrované stisky kláves tak, jak jsou stisknuty. Analýzou časování lze přijít na to, které klávesy uživatel pravděpodobně stiskl (klávesy, které jsou fyzicky blízko u sebe lze na klávesnici psát rychleji). Pečlivá analýza může odhalit délku hesla a pravděpodobně část hesla samotného.
Kevin Neff, zpráva z 10. září 2008 na OPenBSD -misc mailing list.
Tux3 se chová jako souborový systém
link
4. září, originál
Daniel Phillips psal, že jeho nový souborový systém Tux3 nyní funguje jako souborový systém: Poslední dávka začlenění dostala Tux3 do bodu, kde se nepopiratelně chová jako souborový systém: lze do něj zapsat soubory, odejít, později se vrátit a číst je podle jména. Již můžeme vidět, jak se objevují některé jeho přitažlivé stránky: Tux3 zjevně škáluje od velmi malých po velmi velké. Máme exabytový soubor s velikosti bloku 4k a můžeme vytvořit 64petabytové soubory používající 256bytové bloky. Pokračoval zmíněním některých dalších vlastností, které mají být ještě implementovány, včetně atomických commitů, verzování, slučování při výmazu, verze souborového systému zapsané v jádře, rozsahů, zamykání a rozšířených atributů.
Při procházení seznamu výše se Daniel rozhodl, že teď bude pracovat na funkci slučování při výmazu s poznámkou, že bez toho sice můžeme soubory vymazat, ale nemůžeme obnovit bloky indexu souborů, jenom je vymazat, což není moc dobré. K tomu dodal, že prozatím se zaměří pouze na zkracování souborů: Jakmile se do testovací směsi přidá zkracování souborů, uvidíme u bitmapového alokátoru mnohem zajímavější chování a objevíme několik skvělých způsobů, jak vytvořit otřesné záležitosti s fragmentací. Ňam.
Daniel dále upozornil na to, že Tux3 je open source projekt a jako takový se těší na další přispěvatele: Kdokoliv chce do toho, co začíná vypadat jako opravdový linuxový souborový systém, vytesat svoje iniciály, nyní je skvělý čas vyzvednout si přihlášku. Kódová základna je stále malá, překládá se rychle, má spoustu interaktivní zpětné vazby a snadno se s ní pracuje. A svoji e-mailovou adresu dostanete na začátek seznamu, takže jí zajistíte cestu do historie open source. Pravděpodobně.
2.6.27-rc6, "Věci se zklidňují"
link
12. září, originál
Patche, které snad zajímají většinu lidí, se většinou týkají malých detailů, psal Linus Torvalds v oznámení jádra 2.6.27-rc6, a tak by nyní mělo být uzavřeno více regresí, některé prostým odebráním commitů, které regresi způsobily. Nemyslím si, že si něco z toho zasluhuje zvláštní komentář, náhled můžete získat prozkoumáním přiloženého zkráceného logu. V první části e-mailu s oznámením Linus zmínil specifické údaje o tom, které ovladače se z největší části na patchi podílí:
Pořád to samé - kromě toho, že od -rc5 uplynuly téměř dva týdny. Diff je ale přibližně stejně velký, takže hádám, že to znamená, že věci se zklidňují. Většina diffu (drtivá většina) jsou aktualizace nového ovladače gspca (standardní USB webkamera), část tvoří odstranění mrtvého ovladače miropcm20*.
Související články
Odkazy a zdroje
Další články z této rubriky
Diskuse k tomuto článku
9.10.2008 10:18
josko
Re: Jaderné noviny - 33-37/2008
9.10.2008 11:10
DNA
Re: Jaderné noviny - 33-37/2008
9.10.2008 14:01
YYY | skóre: 29
| blog:
martinek
Re: Jaderné noviny - 33-37/2008
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
. Co je v počítačové učebně? Tencí klienti, nebo tenké klienty? Jsou matematičtí operátoři, nebo matematické operátory? Manažeři, nebo manažery souborů?
Viz názor ÚJČ: http://www.ujc.cas.cz/poradna/odpo.html#operator
9.10.2008 11:20