Jaderné noviny - 21. 5. 2008

8. 7. 2008 | Jirka Bourek | Jaderné noviny | 3046×

Aktuální verze jádra: 2.6.26-rc3. Citáty týdne: Linus Torvalds, Andrew Morton, Eric Sandeen. Vhodné zdroje entropie. Zabijte BKL, část druhá. Bariéry a žurnálovací souborové systémy.

Obsah

• Aktuální verze jádra: 2.6.26-rc3
• Citáty týdne: Linus Torvalds, Andrew Morton, Eric Sandeen
• Vhodné zdroje entropie
• Zabijte BKL, část druhá
• Bariéry a žurnálovací souborové systémy

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

Současné vývojové jádro 2.6 je 2.6.26-rc3, které Linus vydal 18. května. Samozřejmě spousta oprav a věci se stabilizují (i když seznam regresí je stále dlouhý). Linus také poukázal na to, že vývojáři jádra nyní používají git tak dlouho, jako používali BitKeeper - nicméně nyní je mnohem více vývojářů. Jako vždy hledejte detaily v dlouhém changelogu.

V době psaní tohoto článku bylo od 2.6.26-rc3 do gitového repozitáře hlavní řady jádra začleněno téměř 300 sad změn. Ty zahrnují nový testovací ovladač pro paměťové karty MMC, novou funkci device_create_drvdata() (určenou k opravení souběhu [race condition] způsobeného předchozím oddělením device_create() a device_set_drvdata()), ovladač pro správu bezdrátových USB zařízení a spoustu oprav.

Současná verze stabilního jádra je 2.6.25.4 vydaná 15. května. Obsahuje celkem dlouhý seznam chyb, z nichž pár je spojeno s bezpečností.

Citáty týdne: Linus Torvalds, Andrew Morton, Eric Sandeen

Buď se můžeš pokusit pít z požární hadice a nevyhnutelně dostat vynadáno, protože něco zdržuješ nebo něčemu nevěnuješ dostatečnou pozornost, kterou si to zasluhuje. Nebo se můžeš pokusit zajistit, aby ti mohli pomoci ostatní. A raději by sis měl vybrat 'nechat ostatní, aby ti pomohli', protože jinak se určitě spálíš. Není to otázka 'jestli', ale 'kdy'.

-- Linus Torvalds o toku práce v gitu (stojí za to přečíst si to celé).

Mluvil jsem jak se samostatnými techniky, tak se zaměstnanci firem, kteří vyvíjeli a kteří plánují vyvíjet podstatné jaderné vlastnosti. Věčně lidem vysvětluji, že by měli pracovat na tom, aby ten kód byl začleněn. Jeden z důvodů, proč to neudělali, je ten, který se objevuje znova a znova - obava z toho, jakého se dočkají přijetí. Veřejně. Tenhle problém se zdá být obzvláště významný v asijských zemích. Ty jsi situaci právě zhoršil.

A tohle není jenom věc osobního zájmu. Je to nutně a nevyhnutelně ten případ, že když jeden z jaderných vývojářů jedná jako arogantní nepřátelský hajzl, nás všechny budou čím dál tím více považovat za arogantní a nepřátelské hajzly.

-- Andrew Morton

Řekl bych, že alternativně bych mohl poslat další patch, který by odstranil "pamatujte, že ext3/4 ve výchozím stavu poskytuje větší záruky integrity dat než jiné" z Documentation/filesystems/ext4.txt ;)

-- Eric Sandeen

Vhodné zdroje entropie

Do jádra přitéká plynulý proud náhodných událostí, které udržují zásobník entropie [entropy pool] naplněný, což procesům umožňuje použít nejsilnější náhodná čísla, která Linux umí poskytnout. Které události se přesně považují za náhodné - a jak moc náhodnosti poskytují - je občas obtížné rozhodnout. Nedávná snaha eliminovat zdroje přispívající do tohoto zásobníku způsobila obavy hlavně v komunitě okolo zabudovaných [embedded] zařízení.

Jádro vzorkuje nepředvídatelné události pro použití při generování náhodných čísel a ukládá je v zásobníku entropie. Entropie je hodnota, která udává nepředvídatelnost či náhodnost množiny dat, takže jádro odhaduje množství entropie, kterou tyto události přispívají do zásobníku. Mnoho jader běží na hardwaru, který postrádá některé z tradičních zdrojů entropie - v takových případech je jako zdroj entropie použito časování přerušení ze síťových zařízení, nicméně to bylo vždy kontroverzní a nedávno byl podán návrh na odstranění.

Dva nejlepší zdroje náhodných dat pro zásobník entropie - interakce s uživatelem pomocí klávesnice nebo myši a přerušení od disků - nejsou na embedded zařízeních často přítomné. Navíc některá disková rozhraní, hlavně ATA, entropii nepřidávají, což problém rozšiřuje i na některé "bezhlavé" [headless] servery. Přerušení ze sítě jsou ale považována za pochybný zdroj entropie, protože mohou být pozorována či manipulována útočníkem. Navíc, když provoz na síti roste, mnoho síťových ovladačů vypíná hardwarem posílaná přerušení při přijetí, čímž jádru umožňují se periodicky dotazovat na příchozí pakety. To omezí sběr entropie právě ve chvíli, kdy by mohla být potřeba pro šifrování provozu.

Není to poprvé, kdy se mluví o eliminaci příznaku IRQF_SAMPLE_RANDOM ze síťových ovladačů; to samé jsme viděli před dvěma lety (i když v té době se příznak nazýval SA_SAMPLE_RANDOM). Nyní je tento návrh opět na stole, začal ho dotaz Chrise Petersona na linux-kernel: Mělo by být síťovým zařízením dovoleno přispívat entropií do /dev/random? Jeff Garzik, správce jaderných síťových ovladačů, odpověděl: Snažím se lidi tlačit k tomu, aby nepřidávali IRQF_SAMPLE_RANDOM do nových ovladačů, ale nemám zájem pořádat pogrom proti existujícímu kódu.

Pro každého, kdo má zájem takový pogrom udělat, navrhl Peterson patch eliminující tento příznak z dvanácti ovladačů, které ho stále používají. To zahájilo dlouhou diskuzi o tom, jak poskytnout entropii těm zařízením, která nemají nic, co by mohla použít. I když se dá zpochybnit, jestli síťová zařízení přispívají k entropii, přidání jejich dat do zásoby nezpůsobí žádnou škodu, pokud jim není přidělen kredit entropie - současný odhad entropie zásobníku. Alan Cox navrhl nový příznak, který by takové zdroje sledoval:

Zajímavější alternativou by mohlo být označit věci, jako jsou síťové ovladače, novým příznakem, řekněme IRQF_SAMPLE_DUBIOUS, aby uživatelům šlo dát přepínač, kterým by se jejich použití zapnulo/vypnulo podle prostředí.

Někteří byli tomuto přístupu nakloněni, ale Adrian Bunk poznamenává, že:

Kdo může žít s pochybnými daty, může jednoduše použít /dev/urandom.

Jestliže chce zákazník použít /dev/random a požaduje odtud pochybná data, pokud není k dispozici nic lepšího, tak splnění jeho přání akorát přesouvá bezpečnostní chybu v jeho špatné aplikaci do jádra.

Část problému pochází z mylné představy o náhodných číslech pocházejících z /dev/random a z těch, která jsou načtena z /dev/urandom, kterou jsme popsali loni v prosinci v článku v oddíle Security Page. Obecně by aplikace měly číst z /dev/urandom, jenom ta nejcitlivější použití náhodných čísel - například generování klíče pro GPG - potřebují garanci entropie, kterou poskytuje /dev/random. Na systému, který dostává pravidelné aktualizace entropie, je kvalita obou zdrojů náhodných čísel stejná.

Pro některé systémy je tu stále inicializační problém, ačkoliv, jak zdůraznil Ted Ts'o:

Proto, pokud si nemyslíš, že systém běžel dost dlouho na to, aby nasbíral dostatečnou entropii, potřebuješ rozlišit mezi "běžel dost dlouho na nasbírání entropie, která způsobí, že kredit entropie používající poněkud odhadující systém, ve kterém se snažíme být konzervativní, umožní extrahovat z /dev/random tolik bitů, kolik potřebujeme" a "běžel dostatečně dlouho na to, aby byla nepředvídatelná útočníkem z vnějšku tak, že hostitelské klíče generované z /dev/urandom jsou skutečně bezpečné".

Potenciálním zdrojem entropie je i pro embedded systémy vzorkování dalších jaderných a systémových parametrů, které nejsou předvídatelné zvnějšku. Jeff navrhuje:

Toto demonstruje EGD, například: http://egd.sourceforge.net/. Dívá se na snmp, w, lst, uptime, iostats, vmstats atd.

A i dál je mnoho zdrojů entropie, které se nepoužívají, například čtení teplotních senzorů, senzorů rychlosti ventilátorů na ventilátorech s proměnnou rychlostí, atd.

Pche, "smartctl -d ata -a /dev/FOO" produkuje výstup, který lze hashovat a přidat jako entropii.

Dalším zdrojem jsou hardwarové generátory náhodných čísel. Jádro již pro některé má podporu, patří mezi ně i VIA Padlock, který je považován za velmi dobrý. Ne všechny procesory ale tuto podporu mají. Modul důvěryhodné platformy [Trusted Platform Module, TPM] podporuje generování náhodných čísel a postupně se rozšiřuje obzvlášť v noteboocích, ale jádro pro TPM nemá žádný hw_random ovladač.

Jeff je pro přidání jaderného ovladače pro to, co nazývá "Modul zrádné platformy", ale jak upozornili ostatní, lze ho používat v uživatelském prostoru pomocí knihovny TrouSerS. Ani pro hardwarové generátory náhodných čísel, které jsou v jádře podporovány, neexistuje žádný automatický sběr entropie - je na uživatelském prostoru, aby rozhodl, jestli to udělat. Tak je to proto, aby bylo možné udržet rozhodování o kvalitě náhodných dat mimo jaderný kód.

Systémy, které tato data chtějí vzorkovat, by měly k naplnění jaderného zásobníku entropie použít rngd. rngd použije testy FIPS 140-2 k ověření náhodnosti dat předtím, než je jádru předá. Andi Kleen není tomuto přístupu nakloněn:

Trochu se zamysli: systém nemá žádný zdroj náhodnosti kromě hardwarového RNG. Ty uděláš své podivné ověření náhodnosti. Co uděláš, když selže? Do svého zásobníku entropie nenaplníš nic a veškerý náhodný výstup je predikovatelný (jenom čas bootu). Když přidáš cokoliv predikovatelného z jiného zdroje, je to stále predikovatelné - žádný rozdíl.

Existuje obava, že některé hardwarové generátory náhodných čísel jsou implementované špatně nebo mohou selhat, takže by bylo nebezpečné automaticky přidat jejich data do zásobníku. Provádění FIPS testů v jádře není možné, takže se toto rozhodnutí nechává na aplikacích v uživatelském prostoru. Není nic, co by superuživatelskému procesu zabránilo přidat bity do zásobníku entropie - bez ohledu na to, jak jsou slabé - ale konsenzus je, že jádro samo musí používat zdroje, o kterých ví, že se jim dá věřit.

Další případ tohoto problému - i když v jiném převleku - se objevuje v v diskuzi o náhodných číslech pro virtualizované I/O, kde se Jeff ptal: Už někdo napsal "hw" RNG modul pro virt, který čte zásobník náhodných čísel hostitele? Rusty Russell odpověděl patchem pro virtio "hardwarový" generátor náhodných čísel a také jedním, který ho přidává do jeho lguest hypervizoru. Lguest patch čte data z hostitelova /dev/urandom, H. Peter Anvin si myslí, že odtud by se brát neměla:

Není důvod poskytovat hostovi /dev/urandom hostitele (kromě zavedení počáteční hodnoty, což lze provést jinými způsoby); host si stejně provede své vlastní míchání. Jediný důvod, proč vůbec poskytovat něco od hostitele, je předat "zlaté" bity entropie.

Implementace virtio poskytuje pouze hw_random, takže potřebuje pomoc z uživatelského prostoru, aby mohla dostat data entropie do jádra. Stejně jako každý proces, který může číst /dev/random, lguest může vypotřebovat zásobu entropie hostitele, takže se objevila diskuze o limitu, kolik náhodných dat mohou hosté ze zařízení požadovat. Implementace hosta by potom mohla použít malý zásobník entropie přečtený od hostitele pro simulované hardwarové zařízení jako základní hodnotu [seed] vlastního generátoru náhodných čísel.

Odstranění posledních zbývajících použití IRQF_SAMPLE_RANDOM ze sítových ovladačů vypadá pravděpodobně, i když nějaký způsob, jak tato data zamíchat do zásobníku entropie, aniž by jim byl přidělen kredit, zůstává ve hře. S trochou štěstí to podpoří snahu zahrnout nové zdroje entropie použitím nástrojů, jako je EGD nebo, na systémech, kde jsou k dispozici, hardwarové generátory náhodných čísel. U systémů, které postrádají tradiční zdroje entropie, by to mělo vést k lépe inicializovanému a plnějšímu zásobníku a zároveň eliminovat potenciální útoky manipulací síťových paketů.

Zabijte BKL, část druhá

Článek z minulého týdne se zabýval s BKL spojenou regresí výkonnosti a závěrem bylo, že bychom byli rádi, kdyby se o eliminaci BKL lidé zase začali zajímat. V uplynulém týdnu se tento zájem skutečně dostal do popředí, objevilo se několik různých snah zbavit se tohoto dlouhotrvajícího zámku.

Někdo by se docela dobře mohl divit, proč se BKL tak drží. Během posledních (přibližně) patnácti let byly do jádra přidány tisíce zámků, které BKL odsouvají do stále obskurnějších rohů. Jenže těchto rohů je hodně, včetně velkého množství přímých volání lock_kernel() v metodě open() pro každé znakové zařízení, většině implementací ioctl(), všech implementací fasync() a dalších. BKL lze v jádře najít všude možně a nezdá se, že je připraven zmizet bez boje.

Část problému je jednoduše v tom, že zamykání je těžké. Takže sebrat se a jít měnit zamykání v nějakém zrádném starém ovladači není na vrcholu seznamu mnoha vývojářů, protože ti by raději vytvářeli zrádné nové ovladače. Kromě toho je BKL zvláštní. Původně byl vytvořen jako více než zamykací primitivum; jeho účelem je umožnit kódu, který BKL pokrývá, předstírat, že stále běží na starém jednoprocesorovém systému. Takže jeho sémantika se od všech ostatních zámků v jádře Linuxu liší.

Pro příklad - BKL se vnořuje, takže programátoři mohou přidávat lock_kernel() volání bez obav o to, že BKL mohl být předtím získán někde jinde. Jako u mutexu může kód držící BKL spát; plánovač nicméně magicky uvolní BKL do doby, než se vlákno, které ho drží, zase probudí. Takže v jaderném prostoru může být několik různých vláken, z nichž všechny si myslí, že drží BKL, ale jenom jedno z nich v daný čas skutečně poběží. Konečným důsledkem je to, že je těžké zjistit, co se s BKL v daném čase děje; kód na něm může záviset a nebýt si přitom vědom jeho existence.

Jak to řekl Ingo Molnár v oznámení stromu Zabijte BKL:

Navíc lockdep BKL nepokrývá, takže jeho závislosti jsou většinou neznámé a neviditelné a všechny jsou ztraceny v bludišti přibližně patnáct let starých změn v kódu. Tohle všechno kolem BKL vybudovalo druh strachu, nejistoty a pochyb: nikdo ho skutečně nezná, nikdo se ho skutečně neodváží dotknout a kód se může rozbít potichu a nenápadně, když BKL zamyká špatně.

To neznamená, že to lidé nechtějí zkusit; Ingův strom - ke kterému se zakrátko vrátíme - je v tomto směru hlavní snahou. Ale nejdřív vezměme do úvahy jinou iniciativu, která poněkud omylem ukázala příklad, jak nenápadné mohou být záležitosti spojené s BKL. Jak bylo zmíněno výše, jádro zabere BKL pokaždé, když proces otevírá znakové zařízení; zámek je držen, zatímco běží funkce open() spojená s ovladačem. Aby bylo možné BKL eliminovat, je potřeba odstranit jeho konkrétní použití; jenže není možné prostě ho odstranit bez rozbití všech ovladačů, které vnitřně nemají správné zamykání. Takže ve skutečnosti toto volání lock_kernel() nelze odstranit, dokud funkce open() všech ovladačů nebude prohlédnuta a, pokud bude potřeba, opravena. V ten den je možné vyvěsit vlajky.

Alternativou, do které se autor článku poněkud unáhleně pustil, je zatlačit získání BKL o úroveň níže. Každá funkce open() je přinucena chovat se správně přidáním explicitních volání lock_kernel() a unlock_kernel(); jakmile budou všechny ovladače ve stromě tímto způsobem opraveny, volání na vyšší úrovni v chrdev_open() může být odstraněno. Tato práce může vypadat jako krok zpátky, protože nahrazuje jedno volání lock_kernel() přibližně 100 jinými, ale ve skutečnosti je to krok kupředu, protože každý ovladač poté může být zkontrolován a opraven nezávisle. Tato práce probíhá, výsledný strom je v linux-next a pokud všechno půjde dobře, měl by být připraven do 2.6.27.

Během této práce si autor článku všiml nemála ovladačů, jejichž funkce open jsou buď zcela prázdné (jediné, co dělají, je "return 0") nebo dělají něco relativně triviálního. Tyto funkce, jak by někoho mohlo napadnout, nepotřebují získat BKL; nedotýkají se žádných globálních zdrojů a nemohou se dostat do souběhu s jinou části jádra. Ve skutečnosti, jak bylo navrženo jinými, by prázdné funkce open() mohly být úplně odstraněny.

Byl to Alan Cox, kdo upozornil na to, že život není tak jednoduchý. V současném stavu věcí se funkce open, která vypadá takto:

static int empty_open(struct inode *inode, struct file *filp)
{
    return 0;
}

ve skutečnosti dá lépe modelovat takto:

static int empty_open(struct inode *inode, struct file *filp)
{
    lock_kernel();
    unlock_kernel();
    return 0;
}

Tyto dvě mohou někomu připadat jako stejné, ale je v nich kritický rozdíl: druhá forma empty_open() se nevrátí do doby, než získá BKL. Jinými slovy poté, co empty_open() doběhne, víme, že BKL byl alespoň jednou k dispozici. A na tom záleží: klasickou chybou v ovladačích zařízení je (1) registrovat zařízení v jádře a pak (2) inicializovat všechny interní datové struktury potřebné pro správu tohoto zařízení. Pokud se nějaký jiný proces pokusí otevřít a použít zařízení mezi těmito dvěma kroky, mohou se stát nepříjemné věci. Volání lock_kernel() ve funkci open(), přestože nechrání žádnou kritickou sekci přímo, seřadí otevření zařízení a inicializaci ovladače a tím zabrání zmatku. Takže, říká Alan,

Myslím, že by bylo nejlepší je nechat v prvním průchodu zamknout/odemknout jádro a pak se jimi probrat. BKL může být lstivý a zlý, ale protože na svět jsem ho přivedl já, hádám, že ho musím také zapudit.

Alan v této snaze nicméně nebude sám a strom "Zabte BKL" Inga Molnára této práci pravděpodobně významně pomůže. Ingův přístup je zbavit se většiny vlastnosti, kvůli kterým je BKL výjimečný. Takže s jeho patchi se BKL mění na další mutex, který může být sledován validátorem zámků. Již není uvolněn, když vlákno zavolá schedule(), což je změna, která si vynutila přidání několika explicitních "uvolnit, plánovat a znovuzískat" změn v kódu, který BKL držel a který by bez nich skončil v deadlocku. Je přidáno mnoho varování, která mají zvýraznit volání, když je BKL držen a není to správně. A tak dál.

Tato sada patchů zjednodušeně zcela odstraňuje BKL a nahrazuje ho jiným velkým zámkem, který se (shodou okolností) také umí vnořovat. A toto vnořování může časem také zmizet. Tak je BKL viditelnější a jednodušeji pochopitelný. A, doufejme, jednodušeji eliminovatelný.

Linusovi se tento přístup líbí, ačkoliv by ho rád viděl přepracovaný tak, aby ho bylo možné relativně brzo začlenit do hlavní řady. To by vyžadovalo nacpat většinu změn do konfigurační volby ozdobené dostatečným množstvím děsivých varování; potom by lidé, kteří chtějí kód testovat, mohli tuto volbu zapnout a zjistit, co vybuchne. Počet explozí bude pravděpodobně relativně malý, ale asi ne nulový.

Tato sada změn, společně s další prací, která probíhá, naznačuje významný posun směrem k eliminaci BKL, který můžeme očekávat během několika následujících vývojových cyklů. Jakmile bude pryč, budeme mít jádro bez starých problémů se zamykáním a bez nepříjemných problémů s výkonem, které může BKL způsobovat. To bude ale nějakou dobu trvat; jednoduše není možné se vyhnout opravdové kontrole kódu, který BKL pokrývá, aby se zajistilo, že poběží dobře i bez přítomnosti této ochrany. To je pečlivá práce, která vyžaduje schopnosti na střední úrovni a kterou nelze příliš uspěchat.

Bariéry a žurnálovací souborové systémy

Žurnálovací souborové systémy přicházejí s velkým slibem: zbavují správce systému obav o poškození dat na disku kvůli pádu systému. Ve skutečnosti dokonce ani není nutné po takové situaci spouštět kontrolu integrity souborového systému. Skutečný svět je samozřejmě o něco ošklivější. A jak ukazuje nedávná diskuze, je možná ještě o něco ošklivější, než si mnozí z nás mysleli, když je slibovaná intergrita žurnálovacího FS vyměněna za výkonnost.

Souborový systém jako ext3 udržuje žurnál na vyhrazené části disku. Kdykoliv má být provedena sada změn metadat souborového systému, jsou tyto změny nejprve zapsány do žurnálu beze změny zbytku souborového systému. Jakmile jsou do žurnálu zapsány všechny změny, je do něj přidán "záznam vykonání" [commit record], který indikuje, že všechno ostatní v žurnálu je platné. Jenom poté, co je takto dokončena tato transakce, může jádro provést skutečný zápis metadat tak, jak se mu hodí; kdyby systém uprostřed operace zhavaroval, informace k bezpečnému dokončení práce jsou k nalezení v žurnálu. Nedojde k žádnému poškození souborového systému způsobenému částečnou aktualizací metadat.

Je tu ale háček: kód souborového systému si musí před zápisem záznamu vykonání být absolutně jistý, že všechny informace o transakci se již dostaly do žurnálu. Pouhé provedení zápisů ve správném pořadí není dostatečné; současné disky mají velké interní cache a pro lepší výkonnost mění pořadí operací, takže souborový systém musí explicitně nařídit disku, aby zapsal všechna data žurnálu na fyzické médium před samotným zapsáním vykonávacího záznamu; kdyby byl vykonávací záznam zapsán dřív, žurnál by mohl být poškozen. Jaderný subsystém blokového I/O to umožňuje pomocí bariér; v krátkosti, bariéra zakáže zapsání jakýchkoliv bloků poté, co byla umístěna, do doby, než jsou všechny bloky před ní zapsány na fyzické médium. Použitím bariér mohou souborové systémy zajistit, že jejich struktury na disku zůstanou neustále konzistentní.

A zde je další háček: ve výchozím stavu souborové systémy ext3 a ext4 bariéry nepoužívají. Je možné je zapnout, ale pokud je správce vyloženě nepožaduje, tyto souborové systémy fungují bez nich - i když některé distribuce (například SUSE) tento výchozí stav mění. Eric Sandeen se nedávno rozhodl, že to není ta nejlepší situace, a proto poslal patch, který mění výchozí nastavení na ext3 a ext4. Tady začala diskuze.

Odpověď Andrewa Mortona nám říká, proč je výchozí volba nastavena tak, jak je nastavena:

Minule, když se o tom diskutovalo, zpomalilo mnoho zátěží o 30 %, takže jsem ty patche s hrůzou zahodil. Prostě si nemyslím, že můžeme jen tak v tichosti o tolik zpomalit všechny stroje...

Neexistuje bezbolestné řešení a jsem nakloněn tomu nechat tohoto psa spát a o výchozím nastavení ať rozhodnout distributoři.

Takže bariéry jsou ve výchozím stavu zakázané, protože mají vážný dopad na výkonnost. A fakt je ten, že lidem používání souborového systému bez bariér prochází. Hlášení o poškozeních ext3 se neobjevuje mnoho.

Ukazuje se, že to "procházení" není jenom štěstí. Ted Ts'o vysvětluje, k čemu dochází: žurnál je u souborových systémů ext3 a ext4 na fyzickém médiu obvykle spojitý. Souborový systém se snaží ho takto vytvořit a vzhledem k tomu, že normálně je žurnál vytvářen ve stejnou dobu jako samotný souborový systém, není problém najít souvislé místo. Držet žurnál pohromadě je dobré pro výkonnost, ale zároveň to pomáhá bránit změnám pořadí. Při běžném používání záznam vykonání přistane na blok těsně za daty žurnálu, takže disk nemá důvod měnit pořadí. Záznam vykonání je tedy zapsán těsně poté, co se na médium dostala i ostatní data záznamu.

Z toho vyplývá, že nikdo není dostatečně hloupý na to, aby tvrdil, že takto se věci budou dít pořád. Diskové jednotky mají určitou dobře zdokumentovanou tendenci přestat spolupracovat v nevhodném čase. Krom toho je žurnál v podstatě kruhový buffer; když se transakce zalomí na konci, záznam vykonání může být na nižším bloku než některá z dat žurnálu. A tak dál, takže potenciál pro poškození je tu vždy; skutečnost je taková, že Chris Mason má program pro torture-test, který poškození dat vyvolá vcelku spolehlivě. Není pochyb o tom, že běh bez bariér je méně bezpečný než s nimi.

Kdokoliv může bariéry zapnout, pokud je ochoten přijmout ztrátu výkonu. Samozřejmě tedy v případě, že jeho souborový systém není na LVM svazku (což některé distribuce dělají ve výchozím nastavení); ukazuje se, že kód mapovače zařízení [device mapper] bariéry nepředává dál a nedodržuje je. Pro všechny ostatní by ale bylo hezké, kdyby se ztráta výkonu dala nějak omezit. A zdá se, že to je možné.

Současný kód ext3 - když jsou bariéry zapnuté - provede při každé transakci tuto sekvenci operací:

1. Bloky záznamů jsou zapsány do žurnálu.
2. Je provedena bariérová operace.
3. Je zapsán záznam vykonání.
4. Je vykonána další bariéra.
5. Zápis metadat začne později.

Na ext4 lze první bariéru (krok 2) vynechat, protože tento souborový systém podporuje kontrolní součty žurnálu. Jestliže je přerovnán zápis dat žurnálu a záznamu vykonání a operace je přerušena pádem, kontrolní součet žurnálu nebude souhlasit s tím, který je uložen v záznamu vykonání a transakce bude vypuštěna. Chris Mason navrhl, že by bylo "většinou bezpečné" vynechat tuto bariéru i u ext3 s možnou výjimkou v situaci, kdy se žurnál zalamuje [wraps around].

Další nápad, jak věci zrychlit, je oddálit bariérové operace tam, kde je to možné. Pokud nic netlačí na to, aby věci byly provedeny [flush], v žurnálu lze shromáždit několik transakcí a všechny je zakončit jednou bariérou. Je tu také určitý potenciál pro zlepšení opatrnou změnou pořadí operací tak, aby bariéry (které jsou obvykle implementovány jako "proveď všechny zbývající operace na médiu") nevynutily zápis bloků, které nemají specifické požadavky na pořadí.

Ve zkratce: zdá se, že přišel čas zjistit, jak to udělat, aby cena za bariéry byla stravitelná. Zdá se, že Ted Ts'o to cítí stejně:

Myslím si, že bychom měli povolit bariéry na ext3/4 a potom pracovat na zlepšení overheadu v ext4/jbd2. Je asi pravda, že většina systémů neběží za podmínek podobných těm, které Chris použil k předvedení problému, ale výchozí by měla být bezpečnost souborového systému.

Autor článku má dojem, že tenhle konkrétní pes je teď zcela vzhůru a bude nějaký čas štěkat. To může některé sousedy rušit, ale je to lepší, než kdyby někdo byl později pokousán.

       

Komentáře

[Nikola Ciprich]

mala chybka

Chris Mason navrhl, že by bylo "většinou bezpečné" vynechat tuto bariéru i u ext4 s možnou výjimkou v situaci, kdy se žurnál zalamuje [wraps around].

navrhoval to pro ext3, ne ext4

[trekker.dk]

Hups, překlep. Omlouvám se.

[zde]

.. vypíná přerušení při přijetí, čímž jádru umožňuje periodicky se dotazovat ..

To "čímž umožňuje" je nesmysl, jádro se přece může periodicky dotazovat vždy, akorát při povoleném přerušení je to zbytečné.

[trekker.dk]

OK, speciálně pro tebe: ...čímž jádru umožňuje se v situacích, kdy to má smysl, periodicky dotazovat...

Spokojen?

[zde]

Nechápu proč hned reaguješ tak podrážděně. Normálně bych jen napsal ..ovladač může vypnout přerušení a (místo obsluhy přerušení) začít se periodicky dotazovat... Není tam žádná příčinnost, proto je "a díky tomu" nepatřičné. Taky nepíšeš "jedu na kole díky tomu že nesedím v autě"...

[Robert Krátký]

Jenže v originále je:

... many network drivers turn off receive interrupts from the hardware, allowing the kernel to poll periodically ...

Takže tam příčinnost je: "ovladače vypnou, což jádru umožní" nebo "a díky tomu jádro může". Podle originálu to vypadá, že jádro se dotazovat nemůže, dokud to ovladač neumožní.

[zde]

Aha, máš pravdu, jde o přesný překlad originálu (imho blbě formulovaného). Podle mě autorovi před tím "allowing" zřejmě vypadlo "and", a tím se smysl posunul.