12.12.2011 00:45
Bluebear | skóre: 30
| blog: Bluebearův samožerblog
| Praha
Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 12. 2011: Novinky mířící do ext4
Portál AbcLinuxu, 5. května 2025 19:08
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.
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ší.
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.
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 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.
Č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í.
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.
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.
Ú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.
12.12.2011 00:45
Bluebear | skóre: 30
| blog: Bluebearův samožerblog
| Praha
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
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?
12.12.2011 12:54
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
12.12.2011 13:44
Jendа | skóre: 78
| blog: Jenda
| JO70FB
12.12.2011 14:29
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
12.12.2011 19:17
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
12.12.2011 20:15
D.A.Tiger | skóre: 8
| Brno
12.12.2011 20:48
Bilbo | skóre: 29
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.
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.
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ě.
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.
13.12.2011 08:55
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
12.12.2011 20:30
D.A.Tiger | skóre: 8
| Brno
12.12.2011 22:00
Nikola Ciprich | skóre: 23
| blog: NiX_blog
| Palkovice
12.12.2011 22:56
Jendа | skóre: 78
| blog: Jenda
| JO70FB
13.12.2011 00:08
pavlix | skóre: 54
| blog: pavlix
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.
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.
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.
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ý.
13.12.2011 13:32
Jendа | skóre: 78
| blog: Jenda
| JO70FB
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.