Jaderné noviny – 23. 6. 2010

15. 7. 2010 | Jirka Bourek | Jaderné noviny | 3083×

Aktuální verze jádra: 2.6.35-rc3. Citáty týdne: Hans Verkuil, Edward Shishkin, Alan Cox. Jediný knoflík pro nastavení napájení. Omezení souběžných výpisů paměti. Další mechanismus pro probouzecí události. Skládání LSM (zase). Btrfs: Chybně navržený? Souběžností řízené fronty a priority vláken.

Obsah

• Aktuální verze jádra: 2.6.35-rc3
• Citáty týdne: Hans Verkuil, Edward Shishkin, Alan Cox
• Jediný knoflík pro nastavení napájení
• Omezení souběžných výpisů paměti
• Další mechanismus pro probouzecí události
• Skládání LSM (zase)
• Btrfs: Chybně navržený?
• Souběžností řízené fronty a priority vláken

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

Současné vývojové jádro je stále 2.6.35-rc3; Linus je na dovolené, takže proud patchů do hlavní řady je momentálně zastaven.

Žádné aktualizace stabilních jader nevyšly od 2.6.32.15 z 1. června.

Citáty týdne: Hans Verkuil, Edward Shishkin, Alan Cox

Takže v 2.6.37 V4L1 konečně zmizí! V Jaderných novinách by o tom měl vyjít článek, takže se o tom všichni (snad) dozví včas.

-- Hans Verkuil (počítá se tohle?)

Jestliže se rozhodneš svůj souborový systém založit na nějakých algoritmech, tak prosím použij původní založené na opravdových akademických pracích. NEMODIFIKUJ tyto algoritmy v izolaci: Jsou velmi křehké! Všechny takové modifikace by měli revidovat specialisté na teorii algoritmů. Takové revize mohou proběhnout v různých vědeckých časopisech na odpovídající úrovni.

-- Edward Shishkin

Před nějakým časem jsem to zvažoval, když jsem se z této cesty pokoušel BKL odstranit. Po spoustě ran do hlavy a nepřekonatelné touze jít se místo toho opít jsem toho nechal s tím, že analýzou to nelze zjistit.

Takže dávám patchi ack – je to jediný způsob, jak to zjistit.

-- Alan Cox

Jediný knoflík pro nastavení napájení

napsal Jonathan Corbet, 23. června 2010

Správa napájení se v Linuxu zesložiťuje s tím, jak přibývá schopností jádra. Nyní je možné řídit spotřebu energie pomocí politik plánovače, správou stavů nečinnosti, stavů zařízení a tak dál. Bohužel některé volby při správě napájení mají dopad na výkonnost; a podle využívání systému tyto důsledky nemusí být vítané, správci tedy musí mít způsob, jak správu napájení řídit.

V současnosti toto řízení probíhá nastavením mnoha samostatných parametrů. Jeden řídí, jestli se plánovač bude pokoušet nahromadit procesy pouze na část procesorů s tím, že ostatní budou moci spát. Jiný knoflík říká správci nečinnosti [idle governor], které stavy spánku může využít. Další řídí frekvenci CPU a napětí. Vědět o všech dostupných parametrech je těžké; všechny je správně vyladit je ještě těžší.

Len Brown navrhl přidat jednotný řídící parametr pro správu napájení, který by byl k nalezení v /sys/power/policy_preference. Tento knoflík by měl pět nastavení v rozsahu „neustále maximální výkonnost“ po „ušetři tolik energie, kolik to jenom jde bez vypnutí systému“. S takovým řízením by správci systému mohli nastavit správu napájení bez toho, aby si museli nastudovat všechny relevantní parametry; politiky by bylo možné nastavit i pro nové parametry správy napájení, které budou přidány v budoucnu.

Tento nápad však všeobecně nebyl přijat s nadšením. Někteří komentátoři požadovali víc než pět nastavení, ale Len argumentoval, že pokud někdo potřebuje složitější konfigurace, měl by dál používat samostatné parametry. Další mají obavy, že jedinou politiku by různé ovladače mohly interpretovat různě, což by vedlo k nekonzistentním výsledkům; podle nich by bylo lepší, kdyby se dál používaly samostatné parametry, které přesně popisují požadované chování. Ke skutečné diskuzi nicméně nemůže dojít, dokud nebude zaslán nějaký kód, pokud se tak vůbec stane.

Omezení souběžných výpisů paměti

napsal Jonathan Corbet, 23. června 2010

Je přirozené, že systémy, na kterých běží PHP, jsou od počátku sužovány více než obvyklým počtem potíží. V některých případech to ale může být ještě horší; vezměme například tento příběh Edwarda Allcutta:

Například běžná konfigurace webserverů s PHP zahrnuje MPM prefork Apache, mod_php a cache opkódů PHP ve sdílené paměti. V některých režimech selhání všechny požadavky obsluhované PHP vedou k segfaultu. Povolení výpisů paměti [core dump] vede k 10-20 výpisům za sekundu, přičemž všechny se pokouší zapsat 150-200 MB velký soubor. To vede k tomu, že celý systém několik minut naprosto nereaguje.

Edwardovo řešení této neveselé situace je patch, který limituje maximální počet výpisů jádra, které lze simultánně vytvářet; výpisy, které překročí limit, budou jednoduše přeskočeny.

Panuje obecná shoda, že by bylo lepší omezit propustnost I/O u provinilých procesů, když je souběžnost příliš velká. Takový přístup ale není možné přímočaře implementovat, obzvláště vzhledem k tomu, že jsou výpisy paměti považovány za zvláštnost a nepodléhají běžnému řízení propustnosti. Pravděpodobně tedy dojde na variaci Edwardova patche, ve které procesy snažící se vypsat paměť jednoduše budou čekat, pokud se příliš mnoho dalších pokouší o totéž.

Další mechanismus pro probouzecí události

napsal Jonathan Corbet, 23. června 2010

Diskuze o blokování uspání prozatím odezněla – což je stav, na který si jenom málokdo stěžuje. Vývojáři nicméně stále přemýšlejí o problémech, které blokování uspání řeší, což lze vidět i z tohoto patche od Rafaela Wysockiho. Rafael se snaží vyřešit problém „probouzecích událostí“ ([wakeup event] událost, která uspané zařízení probudí), které se ztratí, když se objeví ve chvíli, kdy se systém uspává.

Rafaelův přístup zavádí nový sysfs atribut nazvaný /sys/power/wakeup_count; ten by měl obsahovat počet probouzecích událostí, které systém zatím zažil. Jakýkoliv proces může kdykoliv tuto hodnotu číst; privilegované procesy mohou do tohoto souboru i zapisovat. Zde je ale háček: Jestliže hodnota zapsaná do souboru nesouhlasí s hodnotou, kterou by bylo možné ze souboru přečíst, zápis selže. Zápis také spustí mechanismus, který zařídí, že všechny další probouzecí události zastaví pokusy o uspání.

Jako u dalších případů, které byly zaslány, Rafael počítá s existencí démona správy napájení v uživatelském prostoru, který by rozhodoval o uspání systému. K takovému rozhodnutí by došlo, pokud by démon věděl, že není žádný důležitý program v uživatelském prostoru, který by měl něco na práci. Pokud však nepřijde pomoc odjinud, vznikne okno mezi okamžikem, kdy se démon rozhodne uspat systém a kdy se systém skutečně uspí; probouzecí událost, která by dorazila v tomto okně, by se mohla ztratit nebo přinejmenším zpozdit do doby, kdy se systém zase probudí. S mechanismem wakeup_count by si jádro všimlo, že k takovému souběhu došlo, a proces uspání by se přerušil, což by uživatelskému prostoru umožnilo novou událost zpracovat.

Aby tento mechanismus fungoval, musí být jádro schopné počítat probouzecí události; to vyžaduje rozházet volání nové funkce pm_wakeup_event() do ovladačů, které takové události mohou vygenerovat. Interně se to tedy příliš neliší od blokování uspání. Někteří to komentovali tak, že toto schéma je poměrně podobné blokování uspání v uživatelském prostoru, Rafael nicméně věří, že se vyhýbá aspektům API, které vyvolaly největší kritiku. Bez ohledu na to byly názory revidovatelů smíšené a vývojář Androidu Arve Hjønnevåg si myslí, že tento přístup nesplní potřeby projektu. Tato diskuze tedy pravděpodobně bude mít někdy v budoucnu další kolo.

Skládání LSM (zase)

napsal Jake Edge, 23. června 2010

Kees Cook je zpátky s dalším návrhem změny jádra, která by alespoň podle něj měla poskytnout lepší bezpečnost, tentokrát omezuje systémové volání ptrace(). Nicméně stejně jako u jeho dřívějšího patche pro symbolické odkazy nebyla ani tato změna na linux-kernel přijata příliš dobře. Zažehla však diskuzi na téma, které se zde objevuje poměrně pravidelně: Skládání [stacking] linuxových bezpečnostních modulů (Linux security module, LSM).

Keesův patch je relativně přímočarý; vytváří sysctl nazvané ptrace_scope, jehož výchozí hodnota je nula nastavující současné chování. Jestliže je ale nastaveno na jedna, umožňuje volat ptrace() pouze na potomky sledujícího procesu. Cílem je zde zabránit zneužití slabiny v jednom programu (řekněme v Pidginu) ke sledování jiného programu (třeba Firefoxu či GPG-agentu), což by umožnilo vyčíst přihlašovací údaje nebo jiné citlivé údaje. Stejně jako u předchozího patche i tento je založen na patchi, který již dlouho existuje v jádře: grsecurity.

A stejně jako u předchozího návrhu Alan Cox rychle řekl, že by to mělo být vloženo do LSM:

Takže NAK. Jestliže chcete používat kousky grsecurity, pak si prosím prostě napište jaderný modul grsecurity, který bude správně používat bezpečnostní háčky, a přestaňte dělat bordel ve vnitřním kódu. Je to opravdu jednoduché, infrastruktura tu je, tak ji použijte.

Problém tohoto plánu ale je, že LSM se nedají skládat. Lze mít v jádře povolen SELinux, Smack i TOMOYO, ale jenom jeden z nich – volí se při bootu – může být aktivní. Co se týče skládání LSM, objevily se diskuze a návrhy pro skládání (nebo řetězení) LSM, ale začleněno nebylo nic. Dva „specializované“ LSM tedy nemohou v jádře působit současně a uživatelé si mezi nimi musí vybrat.

Pro „kompletní“ řešení jako SELinux to není problém, protože uživatelé mohou najít nebo vytvořit politiky, které budou splňovat jejich potřeby. Krom toho James Morrison upozornil, že SELinux má pravdivostní hodnotu allow_ptrace, která dělá to, o co se pokouší Kees: Nepotřebuješ napsat žádnou politiku, jenom to [allow_ptrace] nastavíš na 0. Jenže pro ty, kdo SELinux používat nechtějí, to není řešení. Jak to řekl Ted Ts'o:

Myslím si, že opravdu potřebujeme skládatelné LSM, protože je tu velká část lidí, kteří SELinux nikdy používat nebudou. Každých pár let se znovu dívám na SELinux, hlava mi vybuchne kvůli (IMHO zbytečné) složitosti a zase jdu od toho…

Rád bych však měl mnoho možností, jako je tento nápad v rozsahu ptrace – o kterém si myslím, že je to užitečná věc. A možná že skládání je jediná možnost, jak tuto debatu vyřešit. Lidé od SELinuxu nikdy neuvěří, že je jejich systém příliš komplikovaný, a já nerad používám věci, které je pro mě nemožné pochopit nebo nastavit, což se podle všeho v blízké budoucnosti nijak nezmění.

I další byli nakloněni možnosti LSM kombinovat, i když konsenzus se spíš než ke skládání kloní k řetězení LSM v kódu pro zabezpečení, stejně jako to bylo provedeno pro SELinux a kvalifikace [capabilities] v Linuxu (tj. security/commoncap.c). V modelu skládání je každý LSM zodpovědný za zavolání každého dalšího sekundárního LSM pro každou operaci související s bezpečností, kdežto řetězení znamená jenom projít seznam security_operations, přičemž by se z jádra volala verze každého LSM, což popsal Eric W. Biederman. To ale není tak jednoduché, jak by se na první pohled zdálo, na což upozornil Serge E. Hallyn, který roku 2004 navrhl mechanismus skládání.

Obecně se říká, že „obecné skládání nefunguje, LSM o sobě navzájem musí vědět“. I to ale není tak jednoduché (což dokazuje zkušenost se skládáním selinuxu a commoncap) a co hůř, pravděpodobně to nebude dobře škálovat, když budeme mít 5-10 malých LSM. Například LSM 1 chce zabránit nějaké akci, zatímco LSM 2 potřebuje, aby tato akce uspěla, aby mohl správně zabránit jiné. Konkrétní příklady jsou pohřbeny v diskuzích o skládání v konferenci lsm z let 2004-2005.

Zdá se, že nějaká diskuze o skládání/řetězení LSM by mohla proběhnout na Linux security summitu, kde by mohla být součástí Keesovy prezentace na téma bezpečnostní řešení „široce používaná, ale mimo strom“; Sarge navrhuje „pivní BOF“, na kterém by tato záležitost mohla být projednána také.

LSM se zdá být cestou kupředu pro oba Keesovy nedávné návrhy; za tímto účelem tedy zaslal Yama LSM, který obsahuje ochrany symbolických odkazů i omezení ptrace() z předchozích patchů. Krom toho přidává možnost omezit pevné odkazy [hard link] tak, aby je nebylo možné vytvořit pro soubory, které jsou buď citlivé (tj. setuid), nebo je ten, kdo odkaz vytváří, nemůže číst ani zapisovat do nich. Každé z těchto opatření lze samostatně zapnout pomocí sysctl v /proc/sys/kernel/yama.

Přestože „Yama“ by mohlo někoho vést k tomu, aby hledal zbytek akronymu („Yet Another…“), ve skutečnosti je modul pojmenován po božstvu: Yama je podle Buddhistů a Hinduistů přibližně ,pánem smrti/podsvětí‘, dohlíží na rehabilitaci nečistých entit, řekl Kees. Vzhledem k tomu, kolik NAK nedávné Keesovy návrhy nasbíraly, nazývat Yama zkratkou NAC [NAKed Access Control system] naznačuje ohledně této situace smysl pro humor. DAC, MAC, RBAC a další by nyní byly s NAC spojeny, kdyby byl Yama začleněn.

Zatím byla diskuze o Yama poměrně malá a bez větších stížností. I když jsou někteří poměrně skeptičtí vzhledem k ochranám, které Kees navrhuje, pravděpodobně se o ně nebudou příliš starat, dokud budou v LSM a ne náhodně rozházeny všude do stromu, jak to řekl Alan.

Morris řekl, že jakmile budou tyto jednodušší úlohy zabaleny do LSM, jaderní hackeři mohou projednat, jestli je zapotřebí nějaké skládání nebo API pro bezpečnostní knihovnu, které by těmto opatřením dovolily existovat společně s SELinuxem, AppArmorem a dalšími. Vzhledem k tomu, že přístup pomocí LSM má poměrně širokou podporu, zdá se, že Yama nebo nějaký jeho potomek by se mohl dostat do hlavní řady. Jestli z toho vzejde nějaký mechanismus pro kombinování LSM zajímavými způsoby, se ještě uvidí – bude ale stát za to vývoj pozorovat, takže zůstaňte na příjmu.

Btrfs: Chybně navržený?

napsal Jonathan Corbet, 22. června 2010

Souborový systém Btrfs mnoho lidí považuje za primární linuxový souborový systém pro příští desetiletí. Přináší návrh nové generace a velký rozsah vlastností (snímky, kontrolní součty dat, interní RAID atd.), na které uživatelé čekají. Přestože byl začleněn do 2.6.29, zůstává Btrfs experimentální, některé dobrodružnější distribuce ale nabízejí instalaci na Btrfs a Meego bude Btrfs používat jako výchozí souborový systém. Když tedy vývojář souborových systémů začal říkat, že je Btrfs „chybně navržený“, lidé zpozorněli.

Edward Shishkin, který je možná lépe znám pro svou snahu udržet naživu vývoj reiser4, poprvé popsal některé své obavy 3. června. Zdá se, že udělal jednoduchý test: Vytvořil nový souborový systém Btrfs a pak vytvářel 2048 B velké soubory, dokud nedošlo místo. O suboptimální efektivitě využívání místa mluvili jiní už dříve, ale Edward byl i tak překvapen, když zjistil, že bylo možné využít jenom 17 % nominálního prostoru v souborovém systému, než začal hlásit, že je plný. Tak špatná efektivita je podle Edwarda důkazem, že Btrfs je špatně navržený a neměl by se používat:

První zjevná věc je, že takový souborový systém nelze nasadit do produkčního prostředí. Prostě protože našim uživatelům neposkytne žádné záruky ohledně využívání prostoru na disku… K současnému kódu Btrfs: NOT ACK!!! Myslím si, že takové „souborové systémy“ nepotřebujeme.

Část problému se týká používání vnořených rozsahů [inline extents] v Btrfs. Základní datovou strukturou souborového systému Btrfs je B-strom, který poskytuje přístup ke všem objektům uloženým v souborovém systému. U větších souborů jsou data uložena v rozsazích [extent], na které se ukazuje ze stromu. Malé rozsahy lze však uložit v samotném stromě, což by mělo poskytovat lepší využití místa i výkonnost. Pokud tyto rozsahy ale nemají vhodnou velikost, mohou způsobit velké plýtvání místem. V jednom uzlu B-stromu je místo jenom pro jeden 2048 B velký vnořený rozsah, takže zbývá 1800 B nevyužitého místa. To je velká interní fragmentace a spousta vyplýtvaného prostoru.

Jak se píše v reakci Chrise Masona (vývojáře Btrfs), tento problém lze zmírnit dvěma přístupy. Jeden je úplně vypnout vnořené rozsahy; Btrfs má připojovací volbu max_inline, kterou lze přesně k tomu využít. Další přístup je umožnit dělení vnořených rozsahů mezi uzly stromu, takže by velikost jednotlivých kousků bylo možné nastavit tak, aby byly dané uzly přesně využity. Btrfs to neumí a pravděpodobně ani brzy umět nebude.

Dělení jsem nepřidal jednoduše proto, že složitost byla vysoká a zisky nízké (v porovnání s jednoduchým vypnutím vnořených rozsahů).

Chris také poznamenal, že většinu dalších položek proměnné velikosti, které se ukládají v B-stromě – například rozšířené atributy – lze v případě potřeby dělit mezi uzly. Tyto položky by tedy neměly působit problémy s fragmentací; na vině jsou zde hlavně vnořené rozsahy.

Jak ale zdůraznil Edward, tento problém jde za vnořené rozsahy. Při svých výzkumech našel mnoho míst, kde existovaly skupiny téměř prázdných uzlů; některé byly využity méně než z jednoho procenta. To je nejpravděpodobněji skutečný zdroj největších problémů s využíváním místa. Podle Edwarda je toto chování dalším důkazem, že algoritmy používané v Btrfs jsou naprosto chybné a potřebují předělat.

Chris nicméně věci vidí trochu jinak:

Současný kód se zjevně rozhodl nesloučit dva listy, které by měly být sloučeny, což je prostě a jednoduše chyba.

Slíbil, že tuto chybu dohledá a zašle opravu. Doufá se, že po opravě této chyby a vypnutí vnořených rozsahů (nebo přinejmenším omezení jejich maximální velikosti) nejhorší problémy s využíváním místa v Btrfs zmizí.

V době psaní tohoto článku daná oprava zaslána nebyla, takže její efekt nelze posoudit. Je ale pravděpodobné, že se zde nejedná o případ souborového systému, který by potřeboval základní úpravy návrhu. To, co potřebuje, je více rozsáhlého testování, ladění výkonu a nevyhnutelně opravy chyb. Dobrá zpráva je, že tento proces podle všeho funguje tak, jak by měl: Problémy byly odhaleny před širším nasazením tohoto velmi nového souborového systému.

Souběžností řízené fronty a priority vláken

napsal Jonathan Corbet, 22. června 2010

Původní kód pracovních front se do hlavní řady dostal bez velkých diskuzí nebo debat; oproti tomu, co bylo dříve, šlo o zjevné zlepšení. Souběžností řízené pracovní fronty [concurrency-managed workqueues, CMWQ] tento kód přepracovávají a mají potenciál stát se dalším významným zlepšením, ale jejich cesta k začlenění nebyla tak hladká. Aktuálně se diskutuje pátá iterace této sady patchů. I když bylo mnoho problémů vyřešeno, ze soukolí systému se vynořilo mnoho dalších, které zaujaly jejich místo.

Práce na CMWQ má řešit mnoho problémů současných jaderných pracovních front. Na špici seznamu je šíření jaderných vláken; současné pracovní fronty mohou na velkém systému vyčerpat ID procesů předtím, než uživatelský prostor vůbec dostane šanci se rozběhnout. A přes tolik vláken nejsou současné pracovní fronty příliš dobré v tom, aby udržovaly systém zaměstnaný; pracovní fronty mohou obsahovat seznam práce, kterou je potřeba udělat, ale CPU přitom nečinně sedí. Také se v nich snadno mohou objevit deadlocky, pokud není zamykání řešeno velice opatrně. Výsledkem je, že v jádře se objevilo mnoho kódu, který tyto problémy obchází, a také několik konkurenčních mechanismů pro odloženou práci.

Aby tyto problémy vyřešil, udržuje kód CMWQ sadu pracovních vláken na každém procesoru; tato vlákna jsou mezi pracovními frontami sdílena, takže systém není zaplaven vlákny specifickými pro pracovní frontu. Samostatná třída plánovače, kterou CMWQ kdysi používal, je dávno pryč, ale kód stále obsahuje háčky v plánovači, které může použít ke sledování toho, které pracovní vlákno v danou dobu opravdu pracuje. Jestliže jsou všechna vlákna pracovních front na daném CPU zablokována a na něco čekají a zároveň je naplánována další práce, kód CMWQ nastartuje další vlákno, které tuto práci začne vykonávat. Kód CMWQ může spustit několik úloh na jednom CPU souběžně – to je něco, co současný kód pracovních front neudělá. Tímto způsobem je CPU vždy zaměstnáno, dokud zbývá nějaká práce.

První stížnost, která se objevila tentokrát, souvisela s faktem, že mnoho vývojářů dávno zapomnělo, o čem že CMWQ vlastně jsou, a Tejun tuto informaci do série patchů nepřidal. To vynahradil vytvořením dokumentu se základními informacemi o kódu. To rychle vedlo k další stížnosti: Chybí-li dedikovaná pracovní vlákna, není již možné pro specifické pracovní fronty měnit chování při plánování.

Tato stížnost měla dvě varianty. Daniel Walker lamentoval, že se tím ztrácí možnost změnit prioritu vláken pracovní fronty z uživatelského prostoru. Tejun rezolutně popřel, že by tohle bylo k něčemu užitečné, a Daniel ještě nepřišel s příkladem, kde by něco takového bylo vhodné. Andrew Morton má naopak obavu o možnost měnit chování plánování z jádra; to je něco, co nyní dělá přinejmenším jeden ovladač. Možná bude ochoten tuto vlastnost nechat projít, ale šťastný z toho není:

Ok, fajn. Jaderná vlákna by stejně neměla běžet s RT politikou. RT je vlastnost pro uživatelský prostor a kdykoliv jaderné vlákno používá RT, degraduje RT qos pro uživatelský prostor. Řekl bych ale, že používání RT v jaderných vláknech bude občas ta nejlepší varianta, takže nepředstírejme, že tady dostáváme něco za nic!

Tejunova odpověď na tento problém má několik podob. Jedna je, že pracovní fronty mají sloužit pro obecnou asynchronní práci a tak ji většina volajících používá. Podle něj by bylo lepší, kdyby existovaly speciální mechanismy pro případy, kdy je opravdu zapotřebí pracovní vlákna pro zvláštní účely. Za tímto účelem zaslal jednoduché kthread_worker API, které lze pro vytvoření takových pracovních front využít. V podstatě se začne nastavením struktury kthread_worker:

DEFINE_KTHREAD_WORKER(worker);
/* … nebo … */
struct kthread_worker worker;
init_kthread_worker(∓worker);

Pak by mělo být pomocí (existujících) nástrojů kthread_create() či kthread_run() nastaveno jaderné vlákno, kterému se ale ke spuštění předá kthread_worker_fn():

struct task_struct thread;

thread = kthread_run(kthread_worker_fn, &worker, "name" …);

Poté už se jedná o jednoduchou záležitost vyplnění struktur kthread_work skutečnou prací a jejich naplánováním:

bool queue_kthread_work(struct kthread_worker *worker,
                        struct kthread_work *work);

Tento patch zatím nebyl komentován.

Další věc, kterou by bylo možné udělat, je spojit atributy jako priorita a příchylnost [affinity] k CPU s prací, která má být odvedena, a ne s vláknem, které ji provede. To by vyžadovalo rozšířit API pracovních front tak, aby bylo možné tuto informaci specifikovat; kód CMWQ by poté odpovídajícím způsobem vyladil pracovní vlákna v momentě, kdy by jim předával práci. V současnosti ale není jisté, jestli je tato vlastnost zapotřebí natolik, aby to ospravedlnilo zesložitění, které by to obnášelo.

Kód CMWQ rozhodně zesložiťuje jádro již tak, ale vyrovnává to nahrazením mechanismů pomalé práce a asynchronního volání funkcí. Tejun doufá, že ho bude moci brzy vhodit do linux-next a snad i začlenit do 2.6.36. Jestli se tak stane, se ještě uvidí; změny ve vnitřním kódu jádra jsou obtížné a tato možná ještě nepřeskočila poslední překážku.

       

Komentáře

[Mrkva]

Jediný knoflík pro nastavení napájení

Proč mi to jen přijde jako nesmysl? Uživatel který to nechce řešit se stejně do /sys koukat nemusí (nastaví to za něj distribuce) a ten, který chce rozhodně "jeden knoflík" využívat nebude.

[Roman]

a ten, který chce rozhodně "jeden knoflík" využívat nebude.

Proč ne?

[kralyk z abclinuxu]

nastaví to za něj distribuce

Tady je právě problém. Výsledek tohohle řešení je, že to buď v distribuci nefunguje pořádně, anebo to funguje ve sytlu "každý pes jiná ves".

[ext3fs]

Jsem pro knoflik. Osobne si radeji napisu maly skript na obsluhu napajeni (a nebo to budu prepinat rucne) nez pouzivat treba Spravce napajeni v KDE ktery si alokuje pres 100MB pameti (dost dobre netusim k cemu).

[frr]

Souhlasím, že 100 MB a závislost na knihovnách KDE je hrozně moc. Jinak mám ale pocit, že nastavení několika dílčích kernelových knoflíků podle nějakého jednorozměrného vstupního čísla je docela rozumná úloha pro triviální user-space prográmek nebo skript (pár desítek kB).

[Bedňa]

Btrfs dostal na prdel, kua tak z toho som ...

[frr]

No... dostal... zastánce ReiserFS překvapivě otestoval Btrfs maličkými soubory o konkrétní velikosti, a je z toho děsnej problém. Kdyby otestoval, jak je oddíl využit MPtrojkama, filmama nebo nějakým mirrorem FTP, došel by k úplně jinému číslu. A v praktickém nasazení bych čekal spíš tenhle typ dat. Mě by daleko víc zajímalo, kolik to generuje "režijních seeků" při sekvenčním čtení dlouhých souborů - tohle je v Linuxu problém.

[frEon]

kdyby disk osadil beznejma mptrojkama, filmama nebo nejakym mirrorem ftp, tak by tenhle bug nenasel. A zabugovanej filesystem nechce mit nikdo. Nebo ty jo?

[Aleš Kapica]

Edward Šiškin není žádný zastánce ReiserFS, ale Reiser4. Asi by tak "neřval" kdyby nebyl na rozdíl od Btrfs nebyl Reiser4 mimo jádro.

Pokud jde o mne, Reiser4 jsem nějaký čas k plné spokojenosti používal, ovšem přešel jsem právě na Btrfs. Důvody? Je v jádře. Je rychlejší a úspornější. Na mnoho prťavých souborů je možná Reiser4 lepší, ale při zaplnění disku nad 80% šel rapidně dolů jeho výkon, což u Btrfs problém není.

[Heron]

Jak psal frr.

+ ten FS je stále ve vývoji, takže vývojáři mohou poděkovat za nalezenou chybu (i když oznámenou takovým způsobem...) a mohou ji opravit. Do produkčního nasazení btrfs ještě pár let zbývá a u FS není kam spěchat (maximálně tak pro zálohu).

[al-Quaknaa]

Já mám btrfs na /, používám gentoo, takže tam je portage strom a další místa se spoustou malých souborů a už jsem na podobnou situaci narazil (že btrfs byl plný při ~65% využití). Ano, je stále ve vývoji, ale reiser4 se v tomhle ohledu choval vážně mnohem lépe... Samozřejmě se tyhle FS nedají porovnávat (jiné featury, návrh atd.), ale argument, že nejčastější užití bude jiné, než spousta malých souborů, mi přijde dost mimo.

[Heron]

byl plný při ~65% využití

To se ale stane velmi snadno. Většina FS (výjimkou je třeba Reiser) má nejmenší jednotku blok o velikosti 4kB (nebo i jinou -- zpravidla násobně větší). Tedy, pokud tam máš soubor o velikosti třeba 5kB, tak to zabere na disku dva bloky, tedy 8kB (jeden bok plný a ve druhém 1kB, 3kB jsou tedy "ztracené místo"). Pro 2kB dat je pak potřeba velikost 4kB. Tedy takový FS by byl plný při zaplnění 2kB soubory o celkové velikosti 50% velikosti FS (resp ještě méně než 50%, protože je potřeba další místo na adresářové struktury, a obecně metadata). To je prostě vlastnost, nikoliv chyba.

FS obecně umožňují velmi malé soubory uložit úsporně přímo v adresářové struktuře (to se ale netýká velikost větší jak blok). Reiser (volba tail) jde dál (jako imho jediný), umí využít místo z nezcela zaplněného bloku. Tím sice šetří místem, ale append na takové soubory je pomalejší.

ale argument, že nejčastější užití bude jiné, než spousta malých souborů, mi přijde dost mimo.

No jenže tak to prostě je. Pokud chceš ukládat data o velikosti cca 4kB (obecně velikost bloku na FS), tak to ukládat jako jednotlivé soubory na FS není vůbec nejlepší řešení (naopak je to jedno z nejhorších).

[frEon]

reiser defaultne spojuje konce souboru k sobe do jednoho bloku, takze timto problemem trpet nemusi. druha strana mince je, ze to mirne zpomaluje praci fs. Nastesti, kdyz clovek vi, ze mu vyhody prevazi nevyhody, tak to proste vypne

[Heron]

Nespletl sis komentář k reakci?

[frEon]

nj, mel bych se poradne vyspat... ber to jako OT

[al-Quaknaa]

To je prostě vlastnost, nikoliv chyba.

Aha - v tom případě mi tyhle věci nedocházejí proto, že už od svých linuxových začátků (~6 let zpátky, nepamatuju se) používám reiser3 a reiser4 a až nedávno jsem přešel na btrfs.

No jenže tak to prostě je. Pokud chceš ukládat data o velikosti cca 4kB (obecně velikost bloku na FS), tak to ukládat jako jednotlivé soubory na FS není vůbec nejlepší řešení (naopak je to jedno z nejhorších).

No, tohle je myslím věc názoru - sám Hans viděl databáze jako řešení problémů filesystémů a chtěl, aby se to tak dělat nemuselo (proto taky pluginy pro reiser4, které měly rozšiřovat schopnosti FS na něco, co se dnes v "sémantickém desktopu" řeší kombinací FS a databáze). Nemyslím si, že pokusy o zrychlení portage přehozením metadat do sqlite jsou důkazem toho, že se FS pro tento účel nehodí, ale že se většina současných FS pro tento účel nehodí. V praxi ten rozdíl asi moc velký není (protože kdo ví, kde reiser4 skončí), ale neviděl bych správu malých souborů jako něco, co pod FS nespadá.

Nakonec ale uznávám, že FS rozumíš o dost víc - já tu jen tlumočím své dojmy z toho, co jsem kdysi od Hanse četl a taky to, že se reisery na malých souborech chovaly o dost lépe (a u těch velkých jsem nějaký velký rozdíl neviděl. Pravda, nebyly to soubory o desítkách GB na oddílech velkých v TB).

[Heron]

No, tohle je myslím věc názoru...

Jasně, mezi DB a FS není žádná ostrá hranice (jak by mohla být, obojí slouží k ukládání dat).

Nemyslím si, že pokusy o zrychlení portage přehozením metadat do sqlite jsou důkazem toho, že se FS pro tento účel nehodí, ale že se většina současných FS pro tento účel nehodí.

Neznám portage ani jeho potřeby. Relační DB (sqlite je relační) obecně poskytuje pohled na data z mnoha uhlů (where přes x sloupců, join přes y tabulek) a k tomu vyžaduje spoustu režijních struktur (indexy, transakční logy, mvcc). Zatímco FS prostě vrátí data tak, jak se válí na disku, na základě jednoho identifikátoru (v relační DB bychom si pouze s primárním klíčem nevystačili). Takže na jednu stranu ano, bylo by fajn mít "DBFS" a použít jej tam, kde to má smysl, na druhou stranu ta nutná režie navíc by byla obecně neakceptovatelná. Pokud si pro portage vybrali sqlite (místo nějaké jiné a rychlejší db typu key-value), tak k tomu asi měli lepší důvod než jen jako skladiště malých souborů.

[Huiii]

Ale to Shishkin dobre vi, ve svem postu pise ze idelani vyuziti je max 0,5. On ale tvrdi, je vyuziti 0,17 je prilis male, ze ext4 a xfs jsou mnohem lepsi (ani jeden tail packing neumi).

A protoze se o Btrfs tvrdi, ze je to next-gen FS, tak by mel byt minimalne stejne dobry, jinak je to experimentalni vec nevhodna pro produkcni nasazeni. (A s tim plne souhlasim.)

[Heron]

Já také nepolemizuji s Shishkinem. Pouze jsem vysvětloval jak je možné mít plný disk při velikosti dat 63%.

17% je možná chyba (velikost bloku 12kB tam asi pro btrfs nastavenou neměl) a mělo by se upravit. Je to FS ve vývoji, chyb tam bude ještě dost.

[Bedňa]

Pokud chceš ukládat data o velikosti cca 4kB (obecně velikost bloku na FS), tak to ukládat jako jednotlivé soubory na FS není vůbec nejlepší řešení (naopak je to jedno z nejhorších).

Podľa toho názoru je vidieť že sa dožijeme aj šmejdu ext999 a všetko lepšie zadupeme. Kde si myslíš že sa DB ukladá tie prťavé dáta?

[Martin Mareš]

Ale vždyť ona je to pravda. Rozhraní souborového systému vůbec není stavěné na operace typu "přečti mi obsah všech těchto souborů v takovém pořadí, v jakém to bude nejrychlejší", což je jedna z nejtypičtějších databázových operací.

Hans Reiser měl zajímavou vizi o spojení sémantiky souborů a databází, ale bohužel k ní vymyslel pouze prostorově efektivní uložení malých fragmentů dat a ne už způsob, jak s nimi zacházet rychle.

[Bedňa]

Reiser s nimi vie robiť fakt rýchlo, bohužiaľ ďalší vývoj už nebude jednoduchý. Všetci veľký ľudia sú šialenci, uhladený programátor možno naklepe časť pekného kódu, ale nikdy nič prielomové. Samo že sa teším na stable btrfs inšpirovanú Reiserom, alebo na zmenu licencie k ZFS.

[kralyk z abclinuxu]

Spousta lidí vynalezla průlomové věci, a přitom byli duševně naprosto v pořádku...

[Bedňa]

Poznám kľučových hráčov, ale o normálnom neviem, napr.?

[kralyk z abclinuxu]

Teď rychle z rukávu mě napadá např. Wichterle. (předpokládám, že se nebavíme jen o IT sféře).

[Bedňa]

Samo že som nemyslel len IT, o tom človeku som si teraz prečítal prvý krát, normálne pôsobí len preto že možno nikto nerozpitval jeho súkromie. Ale pokiaľ poznáš človeka ktorého naozaj niečo nie že baví, ale úplne to žere, je to niečo ako heroin, kokain, automaty a bez dávky ...

[Bedňa]

A prd teraz som si spomenul že mi ho tatko spomínal, v súvislosti so Silónom.

[kralyk z abclinuxu]

normálne pôsobí len preto že možno nikto nerozpitval jeho súkromie

Když rozpitváš soukromí téměř kohokoli, tak nebude "normální". Já teda bych si netrouf říct, že včetně soukromí jsem naprosto "normální", ty jo?

Ale pokiaľ poznáš človeka ktorého naozaj niečo nie že baví, ale úplne to žere, je to niečo ako heroin, kokain, automaty a bez dávky ...

Ne, o tom jsem nemluvil, reagoval jsem na to, že duševně zdravý člověk nevynalezne něco průlomového... A čočky a silon jsou imho značně průlomové...

[Bedňa]

NO COMENT.

[Ash]

Prosím nechte toho, z paradoxních komentářů jako "bez komentáře" a podobně se mi točí hlava a je mi špatně :D

[kralyk z abclinuxu]

Ale on afaik nenapsal "bez komentáře", to se totiž řekne anglicky "no comment", čili co napsal zatím nevíme

[Bedňa]

Keď sa do niečoho zažerieš, tak ostatné veci sa ti zdajú nepodstatné, napríklad aj život tvojej manželky :)

[stativ]

Je přece evidentní, že to mělo být „no cement.“

[Ash]

NA BETON.

[Martin Mareš]

Reiser s nimi vie robiť fakt rýchlo

Ne, neumí. Zkuste si založit řekněme 100 milionů 10-bajtových souborů s náhodnými názvy a pak je všechny přečíst. Pak to porovnejte s přečtením stejných dat uložených pohromadě v jednom 1GB souboru. Rozdíl několik řádů.

[m;)]

a co UFS (FFS) rodina ? blok moze byt deleny na fragmenty. napr UFS2 ma blok 16 KB a fragment 2KB. na tieto veci sa myslelo uz davno. a ak ma niekto potrebu zaplnit disk 1KB subormi moze si tak nastavit velkost bloku (aj u 20 rocneho NTFS). 17% je proste "proklate" malo.

[Heron]

na tieto veci sa myslelo uz davno. a ak ma niekto potrebu zaplnit disk 1KB subormi moze si tak nastavit velkost bloku (aj u 20 rocneho NTFS).

Velikost bloku si můžeš nastavit u většiny FS. To ale na principu věci (tedy zápis souborů o velikosti přibližně velikosti bloku) nic nemění. Pro soubory do velikosti bloku bude vždy průměrná ztráta 50%. Malé bloky ale způsobují velkou režii pro FS, těch bloků je zkrátka moc*, bitmapa volného místa je pak příliš velká, nalezení volného rozsahu trvá déle apod.

17% je proste "proklate" malo.

To nijak nerozporuji.

*) Záměrně nepíšu kolik je moc. Pokud se bych měl říct, kolik je moc souborů, tak na běžném desktopovém disku jsem dosáhl použitelného (opět to záměrně nechám tako mlhavě definované -- prostě "to" bylo pomalé) limitu cca 700 000 souborů na ntfs a velmi podobného 600 000 limitu na ext3. Na 3.75TiB diskovém poli s xfs těch souborů mám cca 8 900 000 a už to začíná být takové všelijaké (zejména xfs_fsr má problém najít souvislý rozsah o dostatečné velikosti, nové 20GB soubory mají běžně 1200 fragmentů, což je cca 17MB/s, což už zpomaluje kontinuální čtení). Na mailling listu xfs se lze dočíst, že rozumné maximum je 10 mil souborů (nějaký šašek chtěl na jeden FS chtěl výhledově ukládat až 500 mil. souborů, na počátku "jen" 100 mil.). Vývojáři XFS ho poslali do ... DB (tím nemyslím nutně SQL relační).

[cronin]

Pro soubory do velikosti bloku bude vždy průměrná ztráta 50%.

Prave ze nie. Minimalne UFS/FFS deli bloky na tzv. fragmenty, ktore pouziva na kratke subory a "chvosty" dlhych suborov, cim vyznamne redukuje zmieneny problem plytvania miestom v poloprazdnych blokoch, a to zaroven pri zachovani dostatocne velkych blokov (typicky 8-16kB). Zil som v domneni, ze vsetky post-minix FS toto (alebo nejaku obdobu) robia - ak tomu tak nie je, je to pre mna dost velke prekvapenie.

Uznavam, ze testovaci pripad s uniformnou starostlivo vypocitanou velkostou suboru je znacne umely. Zaroven vsak treba uznat, ze efektivita vyuzitia miesta 17%, ku ktorej tym FS dotlacil, je pre general-purpose FS neospravedlnitelna; a IMHO ospravedlnitelnych nie je ani tych 65%. Keby sa jednalo o na nieco specializovany FS a zmieneny testovaci pripad by bol proste zamerny "misuse", tak to by bolo mozne autora poslat kade lahsie. V tomto pripade to ale vyzera ako chyba. Kazdopadne tvrdit, ze BTRFS je kvoli tomu zle dizajnovany per-se je - jemne povedane - prehnane. Ako dlho trva vyladenie komplexneho FS je dobre vidiet na ZFS. BTRFS je velmi mlady a bez ohladu na slubne vyhliadky ma pred sebou este velmi dlhu cestu.

[frr]

Jazykozpytná poznámka: nemám to podloženo nějakým autoritativním pramenem, ale pod pojmem "head banging" si osobně představuji figurku, která z čirého zoufalství buší hlavou do zdi, do desky stolu apod... Znáte takový ten vtipný obrázek formátu "A4", na kterém je terč a nápis "zde udeřit hlavou" ? A teď si s tím překladateli poraď :-b

[bubak]

head bangers jsou metalisti co na koncerte trepou hlavama.

[Bedňa]

Motorhead bangers.

[geebranz]

Have you solved this

fence companies green bay