Jaderné noviny - 22. 8. 2007

30. 8. 2007 | Robert Krátký

Články - Jaderné noviny - 22. 8. 2007  

Aktuální verze jádra: 2.6.23-rc3. Citáty týdne: Marc Perkel, Al Viro. Distribuované ukládání dat. Dávkování síťových přenosů. Podpora starších GCC.

Obsah

• Aktuální verze jádra: 2.6.23-rc3
• Citáty týdne: Marc Perkel, Al Viro
• Distribuované ukládání dat
• Dávkování síťových přenosů
• Podpora starších GCC

Aktuální verze jádra: 2.6.23-rc3

Aktuální předverze je (k 22. 8. 2007) i nadále 2.6.23-rc3; verze 2.6.23-rc4 má v tuto chvíli už trošku zpoždění. Minulý týden do hlavního git repozitáře proudily další opravy.

Aktuální verze -mm stromu je 2.6.23-rc3-mm1. Mezi nedávné změny patří dlouho očekávaný ovladač ath5k (na mac80211 založená podpora pro bezdrátové adaptéry Atheros 5xxx), spousta patchů pro x86_64 a nový patch s jmennými prostory PID.

Aktuální stabilní verze řady 2.6 je 2.6.22.4, vydaná 20. srpna. Obsahuje jediný patch - bezpečnostní opravu signálové zranitelnosti, která za určitých okolností umožňovala poslání libovolného signálu setuid procesu.

Starší jádra: 2.6.20.16 bylo vydáno 16. srpna s pár desítkami oprav. Na další aktualizaci 2.6.20 se teď pracuje; půjde o velkou sadu patchů s pěknou řádkou oprav.

Citáty týdne: Marc Perkel, Al Viro

Proč dokáže DOS smazat nekonečný počet souborů, ale rm ne? Protože rm byl napsán v editoru "vi", který způsobuje poškození mozku - a proto se rm ani po 20 letech nedaří dohnat del.

-- Marc Perkel má odpověď pro všechno.

Když říkáš, že jsou to kritici, kdo by měl vyplnit mezery v tvojí nepřesvědčivé argumentaci, tak tím na nikoho dojem neuděláš; arogance tu není nedostatek a ta tvoje není ani originální.

-- Al Viro

Distribuované ukládání dat

Jevgenij Poljakov nepatří mezi vývojáře, kteří by se nechali snadno odradit. Napsal pro jádro spoustu zajímavého kódu - včetně implementace síťových kanálů, systému pro asynchronní šifrování, subsystému kevent, vrstvy pro správu paměti "síťový strom" a kódu netlinkového konektoru. Ze všech těchto patchů se do hlavního jádra dostal pouze netlinkový konektor - a to bylo v roce 2005. Přesto teď Jevgenij představil k posouzení další pořádnou sadu patchů. Ani tentokrát nemíří nějak nízko: chtěl by nahradit většinu funkcí poskytovaných mapovačem zařízení, iSCSI a vrstvami síťových blokových zařízení [network block device (NBD)].

Nový subsystém nazývá distribuované ukládání [distributed storage, DST]. Cílem je umožnit spolehlivé a jednoduché vytváření úložných sítí s vysokým výkonem.

Na nejnižší úrovni implementuje DST jednoduchý síťový protokol, který umožňuje export blokových zařízení po síti. Počet podporovaných operací je velmi nízký: blokové čtení a zápis a požadavek "jak velký je tvůj disk?". Ale účelem je, aby byl rychlý, neblokoval a dokázal fungovat bez kopírování dat. Implementace bez kopírování umožňuje provádět I/O operace bez jakýchkoliv alokací paměti - i když síťový subsystém možná provede nějaké alokace pro sebe.

Zabudováno není ani žádné kontrolování integrity dat; spoléhá se na síťovací kód, že se o tyto věci postará. Stejně tak není podporováno žádné zabezpečení. Je-li blokové zařízení exportováno v rámci DST, je exportováno pro každého, kdo má k danému hostiteli přístup. V budoucnu by určitě šly doplnit exportní seznamy, ale prozatím by hostitelé exportující disky přes DST neměly být přístupné odnikud kromě nejbližší lokální sítě.

Vrchní vrstva kódu DST umožňuje vytváření lokálních disků. Obyčejné ioctl() volání vytvoří lokální disk ze vzdáleného, což je vlastně stejná funkčnost, jakou nabízí NBD. Jevgenij však tvrdí, že výkon je lepší než při použití NBD, protože se používá neblokované zpracovávání, nejsou potřeba žádná uživatelská vlákna a žádné busy-wait smyčky. Jednoduchý mechanismus pro obnovení po pádu znovupřipojí vzdálené hostitele.

Kromě toho však může být kód DST využit k propojení několika zařízení - jak lokálních, tak vzdálených - do větších polí. V současné době jsou dispozici dva algoritmy: lineární a zrcadlový. V lineárním poli je každé zařízení přidáno na konec něčeho, co vypadá jako velké blokové zařízení. Zrcadlový algoritmus replikuje data na každé zařízení, aby poskytl redundanci a obecně rychlejší výkon při čtení. Existuje infrastruktura pro sledování toho, které bloky musí být aktualizovány na každé komponentě zrcadleného pole, takže pokud některé zařízení na chvíli vypadne, může být po naběhnutí zase rychle uvedeno do aktuálního stavu. Zajímavé je, že tyto informace nejsou ukládány na každé komponentě; je to prezentováno jako funkce, která umožní odstranit část zrcadleného pole, již lze pak připojit samostatně coby aktuální obraz pole. Blokové informace v této verzi zatím také nejsou nikde nastálo ukládány, takže pád DST serveru by znamenal, že obnova nekonzistentního zrcadleného pole by byla velmi obtížná, spíše nemožná.

Ukládací pole vytvořená pomocí DST mohou být exportována a použita v jiných polích. Takže série disků umístěných na rychlé lokální síti může být zkombinována ve stromové struktuře do jednoho velkého pole redundantních disků. V tuto chvíli ještě není napsána podpora pro vytváření RAID vyšších úrovní. Podpora více algoritmů je také v TODO, i když Jevgenij se vyjádřil v tom smyslu, že Reed-Solomon kódy používané v tradičních RAIDech nejsou pro distribuovaná pole dostatečně rychlá. Místo toho navrhl použít WEAVER kódy.

DST zatím vypadá jako mapovač zařízení a MD vrstvy, což jsou věci, které už Linux podporuje. Jevgenij však říká, že DST kód je lepší v tom, že všechno zpracovávání provádí neblokovacím způsobem, které funguje s více síťovými protokoly, má automatickou konfiguraci, nekopíruje data a umí operace provádět bez alokací paměti. Nulová alokace je důležitá v situacích, kde hrozí zatuhnutí - a to je při používání vzdálených úložných zařízení často. Aby byl celý DST stack zabezpečen proti zatuhnutí při alokacích paměti, byla by potřeba podpora v síťovací vrstvě. Ale, jak se dalo čekat, Jevgenij má pár nápadů, jak to provést.

Tato sada patchů je zjevně ve velmi raném stadiu; než by bylo možné to použít v produkčním prostředí a s daty, na kterých někomu záleží, bude potřeba ještě dost práce. Podobně jako všechny Jevgenijovy patche, i DST obsahuje množství zajímavých nápadů. Pokud se podaří vyřešit zbývající detaily, mohl by se kód DST nakonec dostat do stavu, kdy by to bylo užitečné doplnění linuxového uložného subsystému.

Dávkování síťových přenosů

V jádru většiny síťových ovladačů je metoda hard_start_xmit(), která je volána pro každý přenášený paket. Tato metoda při běžném použití získá potřebné zámky a vloží paket do přenosové fronty adaptéru. Je pravidlem, že se odchozí pakety nehromadí v jádře; když jsou připraveny vyrazit, tak jsou jeden po druhém předány ovladači. Existují však situace, kdy není možné pakety předat okamžitě. Pokud je například přenosová fronta právě plná, podrží paket síťový subsystém, dokud pro něj není místo. Jakmile je ovladač schopen opět pro zařízení přijímat pakety, obnoví se postup "jeden po druhém".

Vývojáři síťového subsystému pořád hledají způsoby, jak z kódu vyždímat trochu lepší výkon. Krišna Kumar se při pohledu na popsané chování zeptal: proč ovladači neposílat seznam nahromaděných paketů v jediném volání? Takové dávkování přenosových operací by mohlo minimalizovat úsilí vynaložené na zamykání a režii přípravy zařízení, takže by byl celý přenos paketů efektivnější. Za tím účelem Krišna poslal několik verzí sady patchů s SKB dávkováním.

Implementace SKB dávkování vyžaduje pár změn ovladačového API - ale jsou malé a potřebují je pouze ovladače s podporou dávkování. Prvním krokem je nastavení bitu NETIF_F_BATCH_SKBS v poli features struktury net_device. Příznak řekne síťovému stacku, že ovladač umí dávkové přenosy.

Prototyp hard_start_xmit() vypadá takto:

    int (*hard_start_xmit)(struct sk_buff *skb, struct net_device *dev);

Tento prototyp se nemění, ale ovladač, který dal najevo, že pro dev akceptuje dávkování, může narazit na to, že bude jeho metoda hard_start_xmit() volána s skb nastaveným na NULL. Hodnota NULL značí, že je k přenosu připravena dávka paketů; ta se nachází v (novém) seznamu dev->skb_blist. Takže (velmi zjednodušená) podoba funkce hard_start_xmit() u ovladače, který umí dávkování, bude vypadat asi takto:

    driver_specific_locking_and_setup();
    if (skb)
	ret = send_a_packet(internal_dev, skb);
    else {
	while ((skb = __skb_dequeue(dev->skb_blist)) != NULL) {
	    ret = send_a_packet(internal_dev, skb);
	    if (ret)
	        break;
        }
    }
    driver_specific_cleanup();

V reálu to může být trochu komplikovanější - zvláště pokud ovladač implementuje optimalizace jako například potlačování přerušení o dokončení, dokud nebyl odeslán poslední paket dávky. Ale jádro změny je tu popsáno - moc toho není.

V tuto chvíli se vývojáři stále snaží určit, jaký výkonnostní dopad by patch měl. Zvláště je zajímá, jak si dávkování vede ve srovnání s TCP segmentation offloading, což je v podstatě také mechanismus pro dávkování přenosu. U patche tohoto druhu budu velmi záležet na výkonnostních testech; pokud budou výsledky dobré, bude patch pravděpodobně začleněn.

---

Následující obsah je © KernelTrap

Podpora starších GCC

21. srp, originál

Nedávné hlášení o chybě vedlo k debatě o případném ukončení podpory verzí GCC starších než 4.0. Adrian Bunk poznamenal: V současné době podporujeme 6 různých stabilních řad gcc a možná už přišel čas uvažovat o tom, že přestaneme podporovat ty starší. Potřebují ještě nějaké architektury gcc < 4.0? Russell King připomněl, že na některých architekturách je GCC 3.x stále vhodnější než 4.x: Rád bych v dohledné budoucnosti udržel podporu pro gcc 3.4.3 na ARM. Z mého pohledu jsou verze 4.x pro ARM vývojovou záležitostí. 3.4.3 je také rychlejší a o dost méně ukecaná než gcc 4.

Na otázku, kolik vývojářů jádra stále ještě používá starší verze, Linus Torvalds odpověděl, že na tom nezáleží: NEJDE tu o 'vývojáře jádra'. Jde o libovolné lidi, kteří jádra testují. Když jim to ztížíme, proděláme na tom. Takže ne, já hlasuji pro zachování podpory starých verzí gcc, pokud by nešlo o něco naprosto fatálního.

Diskuse k tomuto článku

[trekker.dk]

Jevgenij Poljakov z vývojářů, kteří by se nechali snadno odradit.

V téhle větě pravděpodobně chybí sloveso.

[Jiří J.]

Už jsem to tu chtěl napsat

[Luboš Doležel (Doli)]

Díky, opraveno.

[Ritchie]

Prosím, je opravdu nutné psát informace o překlepech do diskuze? Nebylo by vhodnější kontaktovat autora e-mailem? Vždyť takový příspěvek v diskuzi nemá žádného smyslu.

(Prosím, abyste na můj OT příspěvek nereagovali.)

[trekker.dk]

(Prosím, abyste na můj OT příspěvek nereagovali.)

Když jsi položil otázku, dostaneš odpověď. Pokud jsi tak toužil po tom, aby ti nikdo neodpovídal, neměl ses ptát.

Ano, je to nutné.

[Filip Jirsák]

Prosím, je opravdu nutné psát informace o překlepech do diskuze? Nebylo by vhodnější kontaktovat autora e-mailem? Vždyť takový příspěvek v diskuzi nemá žádného smyslu.

A je opravdu nutné, aby se takovýhle příspěvek (jako ten váš) objevil pod každým druhým článkem? Vždy s jediným argumentem – "mne to nezajímá".

Prosím, abyste na můj OT příspěvek nereagovali.

Příspěvek týkající se komentovaného článku vám vadí, a sám napíšete příspěvek, který se článku netýká vůbec? To mi připadá přinejmenším podivné.

[Luboš Doležel (Doli)]

Kontaktovat autora by opravdu nebylo lepší, protože autor článku a zpráviček své dílo upravovat nemůže. A je sice pravda, že Robert může, ale ten je teď na dovolené - takže psát jemu by nepomohlo.

[r]

chtelo by to u clanku/zpravicek link na formular, kde by se to reportovalo a system by to uz predal nekomu kdo to muze zmenit (jednodussi nez psat email a nesvinilo by to diskuzi dole)

[Pavel Dobeš]

Ale zase by to reportovalo hodne lidi, zatimco tady to je pouze jeden, ten prvni

[Michal Kubeček]

A dalších deset se pohádá, jestli to má být v diskusi nebo ne. Takže to vyjde nastejno… :-)

[trekker.dk]

Chceš-li řešit něco o diskuzi na abclinuxu, řeš to na abclinuxu a nespamuj mi na e-mail!

[Honza Balák]

Docela mě pobavil ten první citát .

[MiK[3]Zz]

Mna pobavil ten druhy :)

[Michal Kubeček]

Mně naopak připadá neskutečně hloupý. Ne kvůli prvoplánovému útoku na editor vi, ale kvůli tomu, že je hluboce pomýlený.

[mrkef]

nejíš maso, nepoznáš vtip...

[Michal Kubeček]

Vtipná je jen ta část o vi, ta mi nevadí. Vadí mi část o rm a zpracování příkazové řádky, protože ta svědčí o tom, že autor toho příspěvku kritizuje něco, čemu nerozumí, jen proto, že tomu nerozumí.

[disorder]

tym by som si nebo taky isty, kedze sa stazoval na kernel ml...

[thingie]

Což on to asi ví. Jenom je teda fakt, že to vyznělo trochu trapně, když člověk ví jak se věci mají.

Na druhou stranu, seriózně (to jako že se teď všichni naserou :o)), proč člověk musí používat obezličky, když chce smazat víc souborů?

[Michal Kubeček]

Jak vidno z té diskuse, není to chyba principu, ale implementace… Mimochodem, než někdo začne tvrdit, že v současných Linuxech je problém smazat přes wildcard 10000 souborů, měl by si aspoň zkusit

  mkdir x ; cd x
  touch {0..9}{0..9}{0..9}{0..9}
  rm * && echo OK

aby zjistil, že měl tu konstantu zvolit větší…

[judas]

touch abcdefgh{0..9}{0..9}{0..9}{0..9}

[disorder]

$ touch abcdefgh{0..9}{0..9}{0..9}{0..9}
$ rm abcdefgh*
$ echo $?
0
$

nemalo to byt este o nieco dlhsie?

[judas]

$ touch abcdefgh{0..9}{0..9}{0..9}{0..9}
-bash: /usr/bin/touch: Argument list too long
$ getconf ARG_MAX
131072

[disorder]

$ touch abcdefgh{0..9}{0..9}{0..9}{0..9}
$ touch abcdefghi{0..9}{0..9}{0..9}{0..9}
zsh: argument list too long: touch
$ getconf ARG_MAX
131072
$

zazrak!

[Michal Kubeček]

Nejspíš to zkoušíte každý na jiné platformě.

[disorder]

obavam sa, ze bajt je vsade rovnaky

ked sa niekomu chce, moze zistit ako sa lisi argument list od zsh a bash :)

$ touch abcdefgh{0..9}{0..9}{0..9}{0..9}
bash: /usr/bin/touch: Argument list too long

[happy barney]

žeby zsh nerátalo \0 do dĺžky reťazca ?

[disorder]

zsh moze ratat co chce, aj tak to nezalezi od neho ci dostane od execu E2BIG, alebo nie...

[Michal Kubeček]

Byte je všude sice všude stejně dlouhý, ale 'char *' už třeba ne…

[disorder]

nechapem co s tym maju pointery

[Michal Kubeček]

Viz dřívější diskuse na toto téma - stačí si uvědomit, jak bude pole 'char* argv[]' v paměti uloženo.

[disorder]

suborov je tu len 10k, mam x86_64 jadro a zsh to dokaze, bash nie

k tej diskusii -- nemyslim si, ze sa tam musia zmestit pointery, argv je obycajne pole pointerov na char* a da sa teda velmi jenoducho dopocitat z jedineho pointeru na samotny blok pamate (o velkosti ARG_MAX)

ale bola by to zaujimave vediet preco jedno ide a druhe nie (zeby bash zle pocital?)

[disorder]

teda, nie zas tak obycajne -- pole pointerov zakoncene (void *) NULL

[Michal Kubeček]

nemyslim si, ze sa tam musia zmestit pointery, argv je obycajne pole pointerov na char* a da sa teda velmi jenoducho dopocitat z jedineho pointeru na samotny blok pamate (o velkosti ARG_MAX)

To by mne zajímalo jak. Musel byste dát nějaký horní limit na velikost jednoho parametru a jednotlivé řetězce ukládat s příslušným odstupem. Pokud by byl ten limit dostatečně velký, aby neomezoval reálnou použitelnost systému, byl by takový způsob uložení ještě výrazně neefektivnější než ten, který se skutečně používá (samostatné pole pointerů).

[Michal Kubeček]

A také by mne zajímalo, jak byste bez toho pole pointerů chtěl zajistit, že bude fungovat klasické

  while (argc > 0) {
    ...
    argc--; argv++;
  }

[disorder]

pri konstrukcii argv by sa samozrejme pocitalo argc, pretoze main() ho potrebuje

[Michal Kubeček]

Jde mi o to procházení pomocí argv++. Vzhledem k tomu, jak funguje pointerová aritmetika, tam to pole pointerů prostě mít musíte.

[disorder]

ale kto hovori, ze argv musi byt sucastou toho bloku pamate? ja nie. nechajme to

[Michal Kubeček]

Opravdu si zkuste pořádně rozmyslet, co přesně znamená deklarace 'char* argv[]' a jak se pak vyhodnocuje 'argv[n]'.

[disorder]

a vy zase skuste najst ten dovod kvoli ktoremu so toto vymyslel -- argv je konstruovane v uplne samostatnom bloku pamate a teda nemusi byt v bloku vyhradenom argumentom.

mne netreba vysvetlovat co je char **argv...

[Michal Kubeček]

Možná jsem to dostatečně nezdůraznil, ale ten limit 128 KB se vztahuje jednak na celkovou velikost těch řetězců, jednak na pole pointerů na ně. Můžete si to buď ověřit empiricky nebo se podívat do zdrojáků.

[disorder]

ano, to je mozno sucasna implementacia, ale ja som len vyjadril nazor, ze nie je nemozne to spravit inak...

[Michal Kubeček]

Neviděl bych moc smyslu v odstranění jednoho z těch limitů, pokud by druhý zůstal.

[disorder]

samozrejme, je lepsie to spravit uplne nezavisle od limitov

[disorder]

pravda, s dostatocne velkym limitom je to neefektivne. ale inac je to mozne -- prvy argument je program, posledny moze byt prazdny retazec (ziadne odstupy medzi retazcami netreba) a da sa to vsetko velmi lahko dopocitat

[Michal Kubeček]

Uvědomte si, co podle specifikace C znamená 'argv[2]': je to pointer, který najdete o 2*sizeof(char*) dál, než začíná pole. Navíc i kdybyste nějakým zvráceným způsobem zařídil, že to bude fungovat, znamenalo by to, že časová náročnost vyhodnocení argv[n] bude záviset na velikosti toho pole.

[disorder]

ano, samozrejme, je to pole pointerov. odpoved na to iste vyssie. bol to len napad, na ziadne zdrojaky som nepozeral.

[zde]

$ getconf ARG_MAX
131072

$ more config.sys
shell=c:\dos\command.com /p /e:3000

Same shit.

[xsubway]

tak jsem si ty dva pany (Marc, Al) progooglil a podle fotek by (mozna) spolu (asi) nesli ani na koblihu ...

(ps: ale oba vyroky jsou, svym zpusobem, zajimave )

[MiK[3]Zz]

Adrian Bunk si snad robi srandu nie? Asi ocividne nevidi kolko roznych ci uz linuxovych distribucii alebo *BSD systemov prave vyuziva GCC 3.x, pretoze GCC 4.x je proste problemove pre nelinuxove systemy a rozne architektury.

[disorder]

"Asi ocividne nevidi kolko roznych ci uz linuxovych distribucii vyuziva GCC 3.x, pretoze GCC 4.x je proste problemove pre nelinuxove systemy"

a to je argument preco vyvojari linuxu nemaju nadalej podporovat 6 verzii gcc, pretoze BSD pouziva tie verzie?

a co sa ti zda take srandovne na jeho otazke?

[MiK[3]Zz]

http://undeadly.org/cgi?action=article&sid=20070829001634

Aktuální verze -mm stromu je 2.6.23-rc3-mm1. Mezi nedávné změny patří dlouho očekávaný ovladač ath5k (na mac80211 založená podpora pro bezdrátové adaptéry Atheros 5xxx), spousta patchů pro x86_64 a nový patch s jmennými prostory PID.

Krasa ako ukradli kod a zmenili licenciu, zevraj tomuto sa vravi open source.

[Zdenek]

http://linux.slashdot.org/linux/07/08/29/0241234.shtml

We are GNU! Resistance is futile! Prepare for asimilation!

[michich]

1. Ten patch, který licenci mění na "pouze GPLv2" nebyl vůbec aplikován.
2. Zdrojáky původního ovladače mají všechny v hlavičce kromě BSD licence uvedeno:

   Alternatively, this software may be distributed under the terms of the GNU General Public License ("GPL") version 2 as published by the Free Software Foundation.

[pharook]

Přečti si ten thread celý, když už na něj odkazuješ.

- Jiří Slabý je jeden z vývojářů.

- Většina kódu je dual licencována, Jiří si vybral GPL.

- Ano, problém je, že většina, ale ne všechen, několik souborů je jen pod BSD licencí, což ale naznačuje spíš na Jiřího přehlédnutí, než záměr.

- Jedná se o pouhý Jiřího post do konference, který byl notabene poměrně rychle umravněn. Nikdo nic neukradl, natož neukradli.

- Že tahle kauza vyvolala vcelku neopodstatněný oheň a síru party Theo de Raadta na veřejném webu, přestože když před pár měsíci došlo k opačné situaci (linuxoví vývojáři civilně, byť veřejně, upozornili na GPL kód, který opravdu skončil v CVS BSD - tedy ne jen v konferenci), byli Theem zpruzeni nade všechny meze, že to řeší zbytečně hlasitě a "nelidsky", a linuxová strana by si od Thea možná zasloužila už druhou omluvu, je druhá věc.

[MiK[3]Zz]

Takze ten GPL kod ako vravis nebol zobraty a nebola tam prepisana len cast o licencii...

Co sa tyka Jiriho Slabeho, tak upravoval subory, ktore neboli licencovane dualne, ale len pod BSD licenciou a on si surovo dovolil odtranit licenciu a pridat GPL, to sa mi zda ako drzost.

[pharook]

Takze ten GPL kod ako vravis nebol zobraty a nebola tam prepisana len cast o licencii...

Nevím, zda rozumím správně (může to být mojí špatnou slovenštinou), ale GPL kód skončil v CVS BSD pod BSD licencí bez souhlasu autorů.

Co sa tyka Jiriho Slabeho, tak upravoval subory, ktore neboli licencovane dualne, ale len pod BSD licenciou a on si surovo dovolil odtranit licenciu a pridat GPL, to sa mi zda ako drzost.

Ano. Drzost - nebo přehlédnutí, dle mého pravděpodobnější. Důvod jsem zmínil. To může ale zřejmě objasnit jen autor.