Jaderné noviny – 1. 12. 2011: Novinky mířící do ext4

12. 12. 2011 | Luboš Doležel | Jaderné noviny | 4164×

Aktuální verze jádra: 3.2-rc3. Citáty týdne: Linus Torvalds, Jon Masters. DM-Steg. Vylepšení v ext4: bigalloc, inline data a kontrolní součty metadat.

Obsah

• Aktuální verze jádra: 3.2-rc3
• Citáty týdne: Linus Torvalds, Jon Masters
• DM-Steg
• Vylepšení v ext4: bigalloc, inline data a kontrolní součty metadat
  • Bigalloc
  • Inline data
  • Kontrolní součty metadat

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

Aktuální vývojová verze jádra je 3.2-rc3 vydaná 23. listopadu. Každopádně, ať už se zítra krocanem cpát budete, nebo ne, vyšlo nové -rc. Rád bych řekl, že se věci uklidnily a počet commitů neustále klesá, ale to bych lhal. -rc3 je totiž větší než -rc2, hlavně kvůli aktualizaci síťování (v -rc2 nebylo nic) a Gregovi, který dělá své obvyklé věci kolem usb/kódu ovladačů/tty/staging. Vypadá to, že se Linus vrátil k vydávání ve středu, takže můžete očekávat -rc4 někdy krátce po zveřejnění této stránky [jejího originálu, pozn. red.].

Stabilní aktualizace: 28. listopadu vyšly verze 2.6.32.49, 3.0.11 a 3.1.3; obsahovaly dlouhý seznam oprav a (u 3.x) také trošku porouchání USB ovladače. Aktualizace 3.0.12 a 3.1.4 vyšly krátce na to s jedním patchem, který problém řeší.

Citáty týdne: Linus Torvalds, Jon Masters

Moduly jsou zlo. Představují bezpečnostní problém a podporují přístup „distribučního jádra“, kdy kompilace trvá celou věčnost. Řekněte jasné ne. Postavte si odlehčené jádro, které má, co potřebujete, a nic víc. A přestaňte trávit čas kompilací modulů, které nebudete potřebovat.

-- Linus Torvalds

Někdy poslouchám písničky jako „Believe“ od Cher. Ve své hlavě to vnímám jako píseň o osamělém životě NMI watchdog handleru (doopravdy). To jest, kdyby NMI watchdog handler mohl vyjádřit naprostou a vyloženou osamělost svého bytí.

-- Jon Masters

DM-Steg

DM-Steg je jaderný modul, který přidává podporu steganografického šifrování do mapovače zařízení [device mapper]. „Steganografického“ znamená, že šifrovaná data jsou ukryta do míry, kdy lze zapřít jejich samotnou existenci. Steg pracuje s podkladem [substrate] (zařízení obsahující šifrovaný text) pro export blokových zařízení s prostým textem, známých jako aspekty, uživateli. Pokud nemáte klíč(e), není možné určit, kolik aspektů podklad obsahuje nebo zda vůbec nějaké aspekty obsahuje. Počáteční verze tohoto modulu byla právě oznámena. Kód byl zatím testován jen na mém PC, ale mně funguje moc pěkně a přestal mi požírat data, takže bych řekl, že je připraven k veřejnému užívání! Přečtěte si tento dokument v PDF pro podrobnosti.

Vylepšení v ext4: bigalloc, inline data a kontrolní součty metadat

Člověka to může svádět k tomu vnímat ext4 jako překonaný souborový systém. Je solidní a spolehlivý, ale je založený na starém návrhu; všechno vzrůšo najdeme u souborových systémů příští generace jako Btrfs. Ale než si Btrfs získá potřebnou úroveň důvěry v širší komunitě uživatelů, to chvíli potrvá; mezitím rostoucí uživatelská základna ext4 neztratila chuť na vylepšení. Několik nedávno zaslaných patchů ukazuje, že přidávání novinek do ext4 neustalo, i když se tento souborový systém usazuje k dlouhému období stabilních nasazení.

Bigalloc

V dřevních dobách Linuxu se kapacita disků stále počítala na megabajty a souborové systémy pracovaly s bloky o velikosti mezi 1 KB a 4 KB. V době psaní tohoto článku nejsou terabajtové disky tak levné jak byly nedávno, ale fakt zůstává neotřesen: disky se zvětšily, stejně jako soubory na nich uložené. Jenže souborový systém ext4 neustále přiděluje bloky dat po 4 KB. Následkem toho je nutné evidovat spousty bloků, související bitmapy alokace nabyly na velikosti a režie spojená se správou těchto bloků je významná.

Zvětšení velikosti bloku souborového systému je děsivě náročný úkol zahrnující velké změny ve správě paměti, cachí stránek a dalších věcech. Není to něco, co by někdo očekával v blízké době. Ale nic nebrání implementacím souborových systémů v tom, aby na disku používaly větší bloky. V jádře 3.2 právě toto ext4 dokáže. Sada patchů „bigalloc“ přináší do souborového systému koncept „shluků bloků“ [block clusters]; namísto alokování samostatných bloků se budou alokovat ve větších skupinách. Mapování mezi většími bloky a 4KB bloky, které vidí vnitřek jádra, je kompletně řešeno na úrovni souborového systému.

Nastavení velikosti shluku dělá správce systému při vytváření souborového systému (použitím vývojové verze e2fsprogs), ale musí jít o mocninu dvou. Velikost shluku 64 KB může dávat smysl v mnoha situacích; velikost shluku 1 MB může být správnou volbou pro souborový systém, na kterém budou samé velké soubory. Není třeba říkat, že vybráním velké velikosti shluku u souborového systému, kde převládají malé soubory, může vést ke značnému plýtvání místem.

Shlukování zmenšuje místo, které zabírá bitmapa bloků a další struktury pro správu. Ale, jak Ted Ts'o popisoval v červenci, může také zvýšit výkon v řadě situací, kdy dochází k používání velkých souborů. Časy alokace bloků se značně snižují, ale výkon I/O se obecně zvyšuje následkem nižší fragmentace na disku. Očekávejte velký zájem o tuto funkci, jakmile se jádro 3.2 (a e2fsprogs 1.42) dostanou k uživatelům.

Inline data

inode je datová struktura popisující jeden soubor uvnitř souborového systému. U většiny souborových systémů jsou dva typy inodů: na souborovém systému nezávislá jaderná varianta (vyjádřená pomocí struct inode) a varianta specifická pro souborový systém uložená na disku. Obecně platí, že jádro nemůže pracovat se souborem, dokud nemá kopii inodu, takže kolem inodů se pochopitelně točí hodně blokového I/O.

U souborového systému ext4 může být velikost inodů na disku určena při vytváření souborového systému. Výchozí velikost je 256 bajtů, ale struktura na disku (struct ext4_inode) potřebuje jen přibližně polovinu tohoto prostoru. Zbylý prostor po struktuře ext4_inode je obvykle použit pro rozšířené atributy. Proto zde lze například najít popisky [labels] SELinuxu. U systémů, kde se aktivně nepoužívají rozšířené atributy, zůstává zbytek místa zpravidla nevyužit.

Prostor pro data se mezitím alokuje po blocích, odděleně od inodů. Pokud je soubor velmi malý (a dokonce i na současných systémech je spousta malých souborů), většina bloku pro soubor bude nevyužita. Pokud souborový systém používá shlukování, množství ztraceného místa bude ještě více narůstat, což může vyvolat stížnosti od uživatelů.

Patche pro inline data na ext4 od Tao Ma mohou tuto situaci změnit. Myšlenka je docela jednoduchá: velmi malé soubory je možné uložit v prostoru mezi inody bez potřeby alokovat jakýkoliv oddělený blok pro data. Na souborových systémech s 256bajtovými diskovými inody bude veškerý zbylý meziprostor použit k uložení malých souborů. Pokud je souborový systém vyroben s většími diskovými inody, bude takto použita jen polovina zbylého místa, což ponechá prostor pro pozdější rozšířené atributy, které by jinak byly vyhnány mimo inode.

Tao říká, že s tímto patchem se potřebná kapacita pro uložení jaderného stromu zmenšila o přibližně 1 % a /usr se zmenšilo o přibližně 3 %. Úspory na souborových systémech, kde je povoleno shlukování, by měly být o něco větší, ale toto ještě nebylo změřeno. Je nutné vyřešit řadu věcí – včetně podpory e2fsck a možných nákladů spojených s vyhnáním rozšířeních atributů z inodů – takže není pravděpodobné, že tato funkce bude připravena pro začlenění před 3.4.

Kontrolní součty metadat

Úložná zařízení nejsou vždy tak spolehlivá, jak bychom si přáli; příběhy o datech poškozených hardwarem nejsou neobvyklé. Z tohoto důvodu starostliví lidé používají technologie jako RAID nebo souborové systémy jako Btrfs, které mohou spravovat kontrolní součty dat a ujišťovat se, že se disk s daty nic neudělal. Jenže souborový systém ext4 tuto schopnost postrádá.

Sada patchů pro kontrolní součty od Darricka Wonga neřeší celý problém. Dokonce může způsobit oprášení starého žertu, že se vývojáři souborových systémů nezajímají o data, která ukládají, dokud jsou metadata v pořádku. Tento patch se snaží pohlídat právě metadata připojením kontrolních součtů k různým datovým strukturám na ext4 – k superbloku, bitmapě, inodům, indexům adresářů, stromům extentů apod. – a následně jejich ověřováním, jestli jsou načtená data v pořádku. Chybný kontrolní součet může znamenat to, že se souborový systém nepřipojí nebo, pokud se to stane na již připojeném souborovém systému, dojde k přepnutí do režimu jen ke čtení a žádostem o pomoc v systémovém logu.

Darrick se nezmiňuje o kontrolních součtech pro data. V několika ohledech by šlo o větší sadu změn; je docela snadné přidat kontrolní součty k existujícím strukturám metadat, ale pro kontrolní součty bloků dat by musela být přidána datová struktura úplně nová. Počítání kontrolních součtů všech dat by také mělo vyšší dopad na výkon. Takže i když se na to někdo může někdy vrhnout, nevypadá to, že by to teď měl někdo na seznamu úkolů.

Zásah do souborového systému je značný i u kontrolních součtů metadat, ale nejvíc práce mířilo hlavně do e2fsprogs. E2fsck pak zejména získalo schopnost všechny kontrolní součty ověřovat a občas, když nesedí, věci opravovat. Kontrolní součty lze povolit u mke2fs a přepínat pomocí tune2fs. Suma sumárum to je spousta práce, ale mělo by to zvýšit důvěru ve strukturu souborového systému. Podle Darricka není režie spojená s výpočtem a ověřováním kontrolních součtů ve většině situací měřitelná. Tato funkce zatím nevyvolala mnoho komentářů a může mít blízko k začlenění, ale nikdo ještě neřekl, kdy by k tomu mohlo dojít.

       

Komentáře

[Bluebear]

Pro pohodlí kolegů, zde je úryvek z písně "Believe" (ne, že bych úplně chápal, proč by to byl zrovna NMI watchdog, ale...)

No matter how hard I try
You keep pushing me aside
And I can't break through
There's no talking to you
It's so sad that you're leaving
It takes time to believe it
But after all is said and done
You're gonna be the lonely one

Celý text například zde: http://www.lyricsdepot.com/cher/believe.html.

[David Jaša]

Velikost shluku 64 KB může dávat smysl v mnoha situacích; velikost shluku 1 MB může být správnou volbou pro souborový systém, na kterém budou samé velké soubory. Není třeba říkat, že vybráním velké velikosti shluku u souborového systému, kde převládají malé soubory, může vést ke značnému plýtvání místem.

Dvě věci mě k tomuhle napadly - jednak jak se shluk bloků liší od extentů a druhak, co SSD, nepomůže jim takováto velikost shluku bloků blížící se velikosti erase blocku?

[petr_p]

Rozsahy pouze šetří strom nepřímých i-uzlů. Každý blok však musí být veden v bitmapě volných bloků. Jestli jsem článek pochopil dobře, tak shluky v podstatě nahradí bloky, takže i bitmapy se smrsknou. Zvolit si velikost bloku můžete již nyní, ale jen při vytváření systému. Shluky by snad mělo být možné měnit i po té. Osobně v tom ale převratný přínos také nevidím.

[jdsulin]

"Moduly jsou zlo. ..... A přestaňte trávit čas kompilací modulů, které nebudete potřebovat." --- proc mit moduly: 1) vymenim nejakou soucast a musim rekompilovat znova ? - to neni takova hruza jako: 2) modul je na h***o (vetsionou wifi ovladace) a podari se mu dostat se do stavu, kdy pomuze jenom "modprobe -r". Vi tady nekdo, jak by se tohle dalo udelat v pripade, ze to zakompiluju do jadra ?

velikost bloku: nejde proste pouzit promennou velikost bloku ?

[disorder]

zabudol dodat, ze si od jeziska treba vypytat kristalovu gulu, ktora ti povie, co budes a co nebudes potrebovat

[Bedňa]

Krišťáľová guľa sa volá lsmod.

[Jendа]

Kdo by čekal, že budu ke storage serveru s ReiserFS potřebovat připojit externí USB disk s ext4? No, stalo se.

[Bedňa]

Štandartné FS nechávam v jadre, ale keby aj nie skompilovať jeden modul a loadnuť ho na chvíľu keď ho potrebujem, hoci zdrží, ale nieje to také hrozné.

[tomo]

Kernel bez modulov nema obvikle podporu pre zavadzanie modulov, takze ee

[Bedňa]

V configu si zvolíš či chceš, alebo nechceš možnosť loadnutia modulov. Inak Ext kompilujem vždy hoci ho nepoužívam, človek nikdy nevie, je to predsa na Linuxe najpoužívanejší FS.

[D.A.Tiger]

K čemu lsmod, když nebudou moduly?

[Michal Kubeček]

Pokoušet se řešit problémy s hardwarem odloadováním modulu je dost nešťastné a nezřídka to nadělá víc škody než užitku.

[Bilbo]

Není to optimální řešení, ale jednak to není řešení špatného HW ale špatného modulu (kdyby ho tak někdo napsal pořádně ...), jednak pokud modul po zavedení zresetuje HW do nějakého "rozumného výchozího stavu", tak tohle pošťouchnutí může pomoci.

[Michal Kubeček]

Teroreticky ano. V praxi se ale na to, že pokud rmmod modul odloaduje bez zjevné chyby, je všechno v pořádu, nemůžete zdaleka vždy spolehnout. V situaci, kdy se v driveru stane něco, s čím se nepočítalo, to platí dvojnásob.

[Sten]

Já bych to řekl naopak. Teoreticky se na to nedá spolehnout, protože ten modul mohl udělat cokoliv. V praxi je to však docela běžný a spolehlivý způsob resetování modulu pro WiFi karty s čipem od Atherosu.

[Michal Kubeček]

No, když myslíte… Já už viděl pár bugů, které spočívaly právě v tom, že když všechno nešlo hladce, modul po sobě nedokázal čistě uklidit, což vedlo v lepším případě k různým oopsům, v horším až ke kernel panic.

Že si uživatelé myslí, že odloadování modulu je "běžný a spolehlivý způsob" řešení problémů, to samozřejmě vím (a také jsem si to dřív myslel). Na druhou stranu už jsem se několikrát setkal i s radikálním tvrzením "module unloading is an unsupported operation", a to od lidí, kteří toho o jádře a driverech vědí o hodně víc než já (a ti první). Podle toho, co jsem ve zdrojácích viděl, je pravda někde mezi, ale rozhodně už si nemyslím, že unload modulu, který se dostal do problémů, je dobrý nápad.

[trekker.dk]

Slyšel jsem o případu - tuším, že to byla nějaká síťovka od Marvellu - kdy pravidelné odstranění a opětovné nahrání modulu byl jediný způsob, jak tu síťovku "spolehlivě" provozovat. Když se to nedělalo, tak ta síťovka prostě přestala fungovat a musel se resetovat celý server, protože v takovém stavu už reload modulu nepomohl.

[Michal Kubeček]

To už mi přijde jednodušší tu kartu vyměnit za jinou (resp. deaktivovat, pokud byla integrovaná na základní desce). Provozovat tímhle způsobem server bych rozhodně nechtěl…

[Sten]

A co když takovou kartu máte v netbooku?

[Michal Kubeček]

Tak ten netbook nebudu používat jako server. :-)

[Ondrej 'SanTiago' Zajicek]

Tipoval bych, ze stejne jako skoro vsude jinde jsou i v netboocich wifi karty typicky oddelene (miniPCI/miniPCIe) a neni problem je vymenit. Ja mam v netbooku Eee PC 901 take neoriginalni kartu (vymena puvodni tusim od Ralinku za inteli wifinu).

[Ondrej 'SanTiago' Zajicek]

Samozrejme, pokud slo o ethernet a ne wifi sitovku, tak tam by to byl vetsi problem :–)

[Hynek (Pichi) Vychodil]

Ono to není jen tak teoretický problém. Například pro

Network controller: Realtek Semiconductor Co., Ltd. RTL8191SEvB Wireless LAN Controller (rev 10)

výrobce protlačil ovladač do jádra 3.0 a od té doby na něj ... V současné době, když se používá s WPA2 Entreprise a migruje z jedné AP na druhou, tak dokáže ztratit autentizaci takovým způsobem, že pomůže jen odstranění a načtení. Aby toho nebylo málo, tak je ovladač v takovém stavu, že dokáže zatuhnout jádro (ne panic) a protože mám šifrovaný komplet disk kromě bootu, tak ani kexec k odchycení chyby a reportu moc nepomůže. Většinou se to moc nestane, když bych byl zároveň přes kabel, takže ani po síti nic a vůbec kdo by se s tím s..l. Karta od jiného výrobce je už na cestě.

[Michal Kubeček]

Samozřejmě se může stát, že to v konkrétním případě opravdu fungovat bude a zařízení se správně reinicializuje a bude zase fungovat. Jenže jednak to tak není zdaleka vždy, jednak i když to na první pohled vypadá, že všechno hladce funguje, problémy mohou nastat později. Setkal jsem se třeba s tím, že zákazník se pokoušel řešit problémy s USB zařízením tím, že odloadoval všechny moduly, které měly něco společného s USB. Na první pohled to sice pomohlo, ale pak systém zhavaroval při spuštění supportconfigu. Důvodem bylo to, že modul uhci_hcd po sobě neuklidil slab cache (protože nebyla prázdná), pointer name v příslušné struktuře odkazoval na řetězec v tom modulu, tj. do stránky, která už nebyla namapovaná. A podobných příkladů jsem už viděl víc.

V ideálním světě by mělo platit, že pokud se modul úspěšně odloaduje bez použití Síly, tak po sobě korektně uklidí je všechno v naprostém pořádku. V takovém světě ale bohužel nežijeme - a to se v této diskusi snažím vysvětlit.

[Bedňa]

To si ešte nemal poriadny kus HW v ruke. Ako by si riešil keď sa ti komp vysmeje že tvoj výrobca ušetril 5c za EEPROM a nedá sa určiť presný typ. Tak zisťuješ ako na to. Zistíš že sa dá loadnuť modul s nejakou hodnotou ktorá môže byť od 0 do 255. Tak som urobil skript ktorý loadol modul s hodnotou, odobral zvýšil hodnotu a loadol ... nenapadá ma žiadny iný spôsob.

[Michal Kubeček]

Jenže to je úplně jiná situace, než o které jsme se bavili.

[D.A.Tiger]

Já na jednu stranu Linuse i chápu. Taky se mi líbí představa malého velice rychlého kompaktního jádra. Ale zas na stranu druhou se mi přítomnost modulů už párkrát osvědčila třeba v případě, kdy mi odešel nějaký kus železa. Mohl jsem jej vyměnit a hned fungovat dál bez toho aniž bych musel sahat na jádro (přenastavovat a rekompilovat jej). Osobně při kompilaci jádra spoustu modulů vyházím, ale snažím se to dělat s rozumem, třeba právě proto, že sám vím jak jednoduše se může občas odporoučet např. grafická karta. Tahle Linusova myšlenka se možná hodí na monolitické stroje, které se prostě jednou sestaví a dokud jej neslisují v odpadu tak se na hardware prostě šahat nebude...

[Nikola Ciprich]

a nebo proste mit jedno failsafe jadro se vsim a pro bezny provoz pouzivat optimalizovane minimalisticke :)

[Jendа]

A opravdu se vyházení nepotřebných věcí projeví nějak znatelně na výkonu? Maximálně tím uspoříš pár MB paměti, což je na dnešních počítačích méně než 1 %.

[pavlix]

Při těch dnešních je to dokonce méně než 1 ‰.

[Sten]

Na výkonu se to dokáže projevit i v řádu procent, protože všechny symboly se u monolitického jádra volají přímo a ne přes tabulky. Proto i distribuční jádra mají některé věci zakompilované. Ale mnohem větší výkonnostní nárůst získáte, když spustíte všechny procesy v ringu 0 (kernel mode).

[Michal Kubeček]

Na výkonu se to dokáže projevit i v řádu procent

Dělal jste nějaké benchmarky nebo si to prostě jen myslíte?

protože všechny symboly se u monolitického jádra volají přímo a ne přes tabulky

Volání exportovaného symbolu z jiného modulu vypadá úplně stejně, ať je ten modul zakompilován přímo do jádra nebo je natažen pomocí insmod/modprobe. Takhle třeba vypadá disassemblovaná funkce nfnetlink_queue_fini() z modulu nefnetlink_queue, která volá nejdřív funkci remove_proc_entry z fs/proc/generic.c, která je přímo v image jádra, a potom netlink_unregister_notifier() z modulu netlink nataženého ručně pomocí modprobe.

crash> dis nfnetlink_queue_fini
0xffffffffa0488548 <cleanup_module>:    push   %rsi
0xffffffffa0488549 <nfnetlink_queue_fini+1>:    mov    $0xffffffffa04892e0,%rdi
0xffffffffa0488550 <nfnetlink_queue_fini+8>:    callq  0xffffffff814a9ac0 <nf_unregister_queue_handlers>
0xffffffffa0488555 <nfnetlink_queue_fini+13>:   mov    $0xffffffffa048a020,%rdi
0xffffffffa048855c <nfnetlink_queue_fini+20>:   callq  0xffffffff8147bf20 <unregister_netdevice_notifier>
0xffffffffa0488561 <nfnetlink_queue_fini+25>:   mov    -0x1e4d2be8(%rip),%rsi        # 0xffffffff81fb5980
0xffffffffa0488568 <nfnetlink_queue_fini+32>:   mov    $0xffffffffa048903f,%rdi
0xffffffffa048856f <nfnetlink_queue_fini+39>:   callq  0xffffffff811b5860 <remove_proc_entry>
0xffffffffa0488574 <nfnetlink_queue_fini+44>:   mov    $0xffffffffa04891c0,%rdi
0xffffffffa048857b <nfnetlink_queue_fini+51>:   callq  0xffffffffa043a3a0 <nfnetlink_subsys_unregister>
0xffffffffa0488580 <nfnetlink_queue_fini+56>:   mov    $0xffffffffa048a000,%rdi
0xffffffffa0488587 <nfnetlink_queue_fini+63>:   callq  0xffffffff814a4490 <netlink_unregister_notifier>
0xffffffffa048858c <nfnetlink_queue_fini+68>:   pop    %rdi
0xffffffffa048858d <nfnetlink_queue_fini+69>:   jmpq   0xffffffff810c9920 <rcu_barrier>
crash> rd -8 0xffffffffa048856f 5
ffffffffa048856f:  e8 ec d2 d2 e0                                    .....
crash> rd -8 0xffffffffa0488587 5
ffffffffa0488587:  e8 04 bf 01 e1                                    .....

Ale i kdyby to tak nebylo, několik procent rozdílu byste z toho rozhodně nedostal. Jednak rozdíl mezi direct a indirect call není nějak propastný, jednak volání funkcí jiných modulů není až tak moc (a v časově kritickém kódu už vůbec ne), často navíc stejně probíhá přes nějakou tabulku typu foo_ops.

[Sten]

Benchmarky přímo jádra jsem nedělal, ale mám zkušenosti s nepřímími voláními v C++ (virtuální funkce), kde to funguje podobně. Těch pár procent je worst case scenario, všechno záleží na tom, jak dobře si s tím poradí L2/L3 cache.

Některá volání zůstavají nepřímá (kvůli různým háčkům nebo třeba Kperf), ale naprostá většina se při zakompilování do jádra změní na přímá. Když vypnete podporu dynamického načítání modulů, tak se žádné symboly neexportují (EXPORT_SYMBOL je prázdné makro), takže by to nepřímo ani nešlo.

To, co tam máte disassemblované, je načtený modul, ne? Ten volá všechno nepřímo.

[Michal Kubeček]

Benchmarky přímo jádra jsem nedělal, ale mám zkušenosti s nepřímími voláními v C++ (virtuální funkce), kde to funguje podobně.

To není ani zdaleka podobné. Obdobou virtuálních funkcí z C++ jsou různé *_ops struktury, u kterých je opět jedno, jestli je příslušný modul nalinkován přímo do image nebo ne.

To, co tam máte disassemblované, je načtený modul, ne? Ten volá všechno nepřímo.

Na tom vůbec nezáleží. Tady máte pro úplnost volání funkce strlen() (přímo v image) z remove_proc_entry() (přímo v image):

crash> dis remove_proc_entry
...
0xffffffff811b58ad <remove_proc_entry+77>:      callq  0xffffffff812b9e40 <strlen>
...
crash> rd -8 0xffffffff811b58ad 5
ffffffff811b58ad:  e8 8e 45 10 00                                    ..E..

Vidíte tam nějaký rozdíl oproti tomu, co je nahoře? Podle mne je to naprosto stejná instrukce (call %rip+imm32). Poslední možnost, tj. funkce z image volající funkci z nataženého modulu, nemá smysl řešit, protože to je v principu možné jen přes nějaký callback, takže tam to bude zase jedno.

[Miloslav Ponkrác]

Já to věděl, že používání Linuxu pro mobilní účely je hrubý omyl. Linuxová komunita si stále myslí, že vyvíjí pro servery a bude za chvíli počítat s terabajty paměti. A pak nějaký idiot přijde a chce z toho dělat mobilní systém.

P.S.: Uspoření pár MB paměti na řadě mobilních věcech je velmi mnoho procent paměti. Někde i stovky procent.

Když bude Linux stále rozežranější, bude muset dřív nebo později zmizet z jiných použití, než nadupadný server nebo nadupaný desktop.

[Michal Kubeček]

Linuxová komunita si stále myslí, že vyvíjí pro servery a bude za chvíli počítat s terabajty paměti.

Jakou linuxovou komunitu to máte na mysli? Jestli vývojáře jádra, tak o těch to rozhodně neplatí. Jestli vývojáře desktopových aplikací, tak u těch by bylo při ceně kolem 1000 Kč za 8 GB předpoklad, že nemá smysl kvůli pár MB omezovat funkčnost nebo snižovat výkon, celkem oprávněný.

[PetrHL]

Možná byste si to mohl první přečíst. Předpokládám, že v mobilu můžete mít klidně moduly zakompilované v jádru natvrdo. Tam se nepředpokládá, že si na desce vyměníte jednoho švába a budete chtít aby to fungovalo.

V případě desktopu je to něco jiného. Když si přinesu domů flasku, externí disk, nebo mi něco v počítači chcípne, vrazím tam jinou desku a jedu dál. Určitě kvůli tomu nechci kompilovat kernel. Když mám nějakých 6GB RAM, úspora 10MB RAM se mi nevyplatí.

[Jendа]

Myslel jsem, že se bavíme o desktopu/serveru. Na openWRT routříku mám samozřejmě také minimalistické jádro.

[m;)]

hm.. "Zvětšení velikosti bloku souborového systému je děsivě náročný úkol zahrnující velké změny ve správě paměti, cachí stránek a dalších věcech. Není to něco, co by někdo očekával v blízké době."

zvlastne .. neprijemne prekvapive .. vzhladom na to, ze UFS v *BSD to vie odjakziva (minimalne cez dekadu) a NTFS to vie odjakziva tiez (nevraviac o dalsich viac profi FS)