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

[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)