Jaderné noviny – 2. 9. 2009 (diskuse)

[kotrcka]

prvý apríl?

[Sleep_Walker]

Nejspis preklep na ciferniku stroje casu.

[Leoš Literák]

Spise si tazatel nevsiml, ze jaderne noviny vzdycky vychazeji se zpozdenim.

[Atom321]

Tak teď jsem poněkud rozčarován. Jestli jsem to dobře pochopil:

1) Flag O_SYNC v současných verzích jádra nesynchronizuje metaddata. Čili pokud připíšu na konec souboru otevřeného s O_SYNC, write() vrátí OK a pak systém lehne, data tam pravděpodoně nebudou. 2) Toto chování je naprosto špatné, v rozporu s normou POSIX a není popsáno v dokumentaci. 3) Je dost pravděpodobné, že spousta současných aplikací spoléhá na správné chování a od Linuxu ho nedostává. 4) Je to tam už léta a nikoho to nesere. 5) A navrch si někteří z hlavních vývojářů si dokonce myslí, že je to tak správně, protože větší rychlost.

Ujistěte mě, že je to chyba v překladu, nebo jsem něčemu špatně porozumněl.

[michich]

U O_DSYNC se mluví výslovně pouze o těch metadatech, která nejsou nutná pro přečtení dat, takže to, co uvádíš v 1) by hrozit nemělo.

[Atom321]

Aha. Podle popisu O_DSYNC to tak vypadá. Snad jsem se tedy vyděsil zbytečně.

http://www.opengroup.org/onlinepubs/007908799/xsh/open.html http://www.opengroup.org/onlinepubs/007908799/xbd/glossary.html#tag_004_000_292

Ovšem přístup "necháme to blbě jak to je, v zájmu rychlosti" se mi nelíbí ani trochu.

[michich]

Ale přístup "je to tak už spoustu let, nikomu to nevadilo, a když to teď spravíme, tak způsobíme výkonnostní regresi" náhodou není úplně špatný

[Atom321]

Jenže my nevíme, jestli to někomu vadilo. Zatím ale nikdo neodhalil, že za to můžeme my, tak to zkusíme ututlat. Výkonová regrese po opravě by nás mohla prozradit, tak to zaflikujeme jen u věcí kompilovaných s novým jádrem a novou glibc. Pak se to projeví až později, to už nás nebude nikdo podezřívat.

[michich]

Nikdo se to nesnaží ututlat. Ta debata spíš ukazuje to, že praktické dopady mají při rozhodování vývojářů větší váhu než přesné dodržování specifikace.

[Atom321]

To je právě jedna z bolestí Linuxu - okamžité praktické dopady dostávají přednost před výhledem do budoucnosti.

[Andrej Herceg]

Čo je zlé na tom, že sa to opraví tak, že staré aplikáciu budú fungovať presne tak ako doteraz a nové už môžu fungovať správne (a teda v budúcnosti to bude fungovať správne)?

[Atom321]

Špatné je na tom to, že ta chyba je tam dlouho a vědělo o ní jen pár vyvolených, mezi které nepatřili ani autoři GLIBC. Staré aplikace občas fungují špatně, jen nikdo neví proč a není schopen příčinu najít. Skvělá zpráva je, že přesně stejně špatně budou fungovat dál i s novým jádrem.

Aby nová aplikace mohla fungovat správně, nestačí opravit jádro, musí se upravit i headery C knihovny. Naopak starší aplikace fungující s nesprávným O_SYNC začnou být pomalejší až po kompilaci s novou glibc.

Takže způsobené problémy budou ve výsledku větší, jen trošku odložené v čase a pravá příčina se bude hůř hledat.

[cronin]

Vdaka tomu je Linux kernel tam, kde je. Ak chces opacny priklad, pozri Hurd.

[Atom321]

Nemáte pravdu. Linux je dále než Hurd, protože na něm bylo odvedeno mnohem víc práce více lidmi a je větší silou tlačený do světa. Špatný návrh se dá protlačit silou. S lepším návrhem se ale stejnou silou dostanete dál. Pokud chcete opačný příklad, podívejte se na MacOS.

[Ondrej 'SanTiago' Zajicek]

> 1) Flag O_SYNC v současných verzích jádra nesynchronizuje metaddata. Čili pokud připíšu na konec souboru otevřeného s O_SYNC, write() vrátí OK a pak systém lehne, data tam pravděpodoně nebudou.

On O_SYNC na Linuxu funguje s normalnimi soubory? Ja ziju v predstave, ze funguje jen s blokovymi zarizenimi.

[Ondrej 'SanTiago' Zajicek]

Funguje. To jsem si jen spletl O_SYNC s O_DIRECT.

[Ivan]

 JJ. Zurnalovani je naprd. Ono to vytvari falesny dojem ze vas to ochrani pred vsemi typy selhani HW - to ale neni pravda. Pokud mate vadnou pamet ve SCSI/FC adapteru anebo mate problemy s terminaci SCSI tak muzete snadno prijit o vsechna data prave diky zurnalovani.

 

[trekker.dk]

Když máš vadnou paměť v adaptéru nebo jiný HW problém, tak je to problém hardwaru - je nesmysl z toho vyvozovat závěr, že žurnálování je naprd. (Nebo snad při hardwarové chybě na fs bez žurnálování ztráta dat nehrozí?)

[Ivan]

Zurnalovani, tak jak je implementovano na linuxu vede k tomu, ze se nespousti fsck ani v pripadech kdy se mela provest plna kontrola filesystemu. Treba JFS na AIXu je taky zurnalovaci FS, ale presto v mnoha pripadech OS usoudi, ze server byl rebootovan kvuli HW chybe a provede se plne fsck. Pokud na linuxu pri stovce rebootu 100x prehrajete zurnal tak se vam muze stat ze na disku uz zadna data mit nebudete. Dokonce i takovy wokna umoznuji oznacit NTFS jako "dirty" tim si vynutit plnou kontrolu filesystemu po rebootu.

 

 

[Andrej Herceg]

To je vec nastavenia systému. Mne sa napr. pri nesprávnom vypnutí ponúkne aj kontrola úplná disku (a pri tom AIX aj sám píšeš, že o tom, či je potrebná úplná kontrola rozhoduje OS a nie samotný JFS).

[pharook]

Dokonce i takovy wokna umoznuji oznacit NTFS jako "dirty" tim si vynutit plnou kontrolu filesystemu po rebootu.

Linuxové distribuce ne?  

[TomCat1]

Dokonce i takovy wokna umoznuji oznacit NTFS jako "dirty" tim si vynutit plnou kontrolu filesystemu po rebootu.
Něco jako "shutdown -F"?

[R]

Uz som parkrat videl autoamticky spusteny fsck na ext3 particii po HW alebo SW chybe (prepisal som nejake nahodne miesto v pamati).

[Heron]

Fakt nechápu o co Pavlovi jde.

Na obhajobu svých poznatků si vezme obskurní HW a dělá s tím věci, které jsou nebezpečné už z principu a hrozně se diví, že dojde ke ztrátě dat. A opět se místo příčiny (nevhodné chování k HW) řeší následek (journal zhoršuje situaci). Ten degradovaný raid a druhé selhání lze brát snad už jedině jako špatný vtip. Dostat se toto do kernelu (dokumentace) je snad ještě horší než Ts'oův patch do jádra na detekci debilně napsaných aplikací a úpravu chování ext4.

Pak se Linus nemá divit, že je kernel obrovský a přeplněný.

[trekker.dk]

je snad ještě horší než Ts'oův patch do jádra na detekci debilně napsaných aplikací a úpravu chování ext4.

Přesně - patche zajišťující, aby nepřicházel o data ten, kdo na počítači dělá kraviny a padá mu to, nemají v jádře co dělat. A nebo když už, tak jako volitelná možnost, kterou půjde vyhodit.

[cronin]

Pojem

... na počítači dělá kraviny ...

je velmi relativny. Jeden priklad:

Panej nefungoval na pocitaci zvuk. Po kratkom zistovani priciny som jej podal vysvetlenie: "[Pocitac] nevie najst Tvoju zvukovu kartu." A kedze to bola velmi bystra pani, na chvilu sa zamyslela a dala mi odpoved, po ktorej som pochopil, aki sme my developeri lameri a ako tazko chapeme "obycajnych" pouzivatelov: "Aka moja zvukova karta? Je to predsa JEHO zvukova karta!"

[trekker.dk]

Ten příklad je naprosto nesouvisející - zrovna tahle paní na počitači pravděpodobně bude schopná udělat jenom jedinou věc, která může vést ke ztrátě dat na FS - reset tlačítkem na bedně.

Kraviny, o kterých mluvím já, jsou záležitosti typu zkusím z toho stroje vymačkat o 2% výkonu navíc tím, že přetaktuju procesor o 10%, a uvidím, co to udělá.

[Jiri]

No... Flashku vidi jako disk a bezne se uvadi, ze ext3 je blbuvzdorny. Jenze on prave ve flashkach (poskozene RAIDy mi prijde hloupe komentovat, rozbite zarizeni je rozbite a nikdo s tim nic nenadela) neni. Vubec se mu nedivim, ze to chtel dopsat do dokumentace (jestli jsem to pochopil spravne, vubec nechtel zvetsovat kernel). Pro me je to taky novinka a budu si muset na flashky davat vetsi pozor.

[Andrej Herceg]

Lenže aj pri iných súborových systémoch sa pri prepise nejakého sektora v skutočnosti na tej flash pamäti prepisuje oveľa väčší úsek, takže to nie je problém súborového systému ext3.

[Ivan]

 Ona to neni primo chyba ext3, ale podobne pripady se uz staly. Nektere disky (napr. WD) chybne reportovaly skutecnost, ze data byla zapsana na disk. Tyhle disky poslaly potvrzeni uz kdyz byla data zapsana do cache na disku. Pri vypadku napajeni nebyl filesystem konzistentni a dochazelo ke ztratam dat. Zajimava vec je, ze to postihovalo temer vyhradne XFS. A ted se nabizi otazka je XFS horsi FS nez EXT3, kdyz nedokaze ochranit vase data na nekvalitnim HW?

 

[eoj]

vezme obskurní HW a dělá s tím věci
K chybě může dojít, je jedno na čem a jak ji vynucuje.
a hrozně se diví
Chtěl to jen zdokumentovat.

[Atom321]

On ale nic neřeší, jen to chování zdokumentoval. Na světě jsou lidi, které to prostě nenapadne. Teď si to můžou přečíst v dokumentaci.

Ted Ts'o jen opravil svou chybu. Aplikace byly psané tak, aby fungovaly dobře na ext3. Tam totiž samotný Ted Ts'o poněkud odflákl implementaci fsync(), která tak trvala nepoužitelně dlouho a programátoři ji museli z aplikací vyhodit. U ext4 zase vymyslel opačný extrém - po uzavření souboru bez fsync() pozdržel uložení až do nejbližšího pádu systému. Údajně chtěl urychlit práci s dočasnými soubory, nebo tak něco. Akorát si při tom neuvědomil, že narozdíl od jeho pokusů jsou soubory ostatních lidí většinou trvalého charakteru a mají být uloženy na disk. Třeba ne hned, stačí za sekundu, dvě. Pět už je hodně a Ts'ouových třicet příliš. On totiž i dočasný soubor se maže obvykle hned po uzavření, nebo nikdy. Čekat třicet sekund je bezesmyslné riskování s uživatelskými daty. Takže chyba byla zcela správně opravena tam, kde vznikla - tedy v implementaci ext4.

[Heron]

Tam totiž samotný Ted Ts'o poněkud odflákl implementaci fsync(), která tak trvala nepoužitelně dlouho a programátoři ji museli z aplikací vyhodit.

Ano, toto jsou přesně ty "debilně napsané aplikace" o kterých jsem psal. Linux poskytuje volání, které zaručeně uloží data na disk. Pokud aplikace potřebuje mít data na disku, musí použít toto volání. Vše ostatní je výmluva. Databáze používají své soubory běžně s O_DIRECT/fsync a přesto jsou rychlé.

Jestli je to volání někde nepoužitelně pomalé, má se opravit implementace v systému souborů. Nikoliv se na to vykašlat a spoléhat nezamýšlenou pozitivní vlastnost defaultního nastavení jednoho systému souborů. Protože nikde jinde to nebude fungovat. Vykašlat se je hodně nebezpečné, protože se to projeví za hodně dlouho a nikdo nemusí vědět o co jde. To za hodně dlouho se stalo teď, kdy některá distra vytvářejí ext4 během instalace.

Interval commitu lze někde nastavit někde ne. O tom, jaká je správná hodnota by se mohli vést dlouhé diskuse. ext3 v ordered měla 5s, ext4 má 30s, já nastavuji na 120s, XFS nemá pravidelný commit a zapisuje až se mu zachce. A teď co je správně? Správně je systém souborů čistě odmountovat. Jestli zmizí data za 1s nebo 10 minut je už tak trochu jedno, protože objem dat za 1s může být klidně větší.

[Atom321]

Linux poskytuje volání, které zaručeně uloží data na disk. Pokud aplikace potřebuje mít data na disku, musí použít toto volání. Vše ostatní je výmluva.

Ano, máte pravdu. Problém je v tom že každá aplikace potřebuje mít data na disku. Tedy, každá aplikace má volat fsync() před close(), aby potlačila cacheování na úrovní filesystému. Cacheování si má tedy dělat sama (jako ty databáze), nebo žít s pomalým přístupem na disk. V tom případě si veškeré cache filesystému a celé žurnálování můžete strčit za klobouk.

Ty aplikace lze napsat dobře, jedině pokud budou mít k dispozici jednoznačně definované, spolehlivé a dostatečně rychlé rozhraní k souborovému systému. Nic takového ale v Linuxu neexistuje. Ty aplikace napsané tak, aby fungovaly s debilně navrženým API a jeho nejčastější mizernou implementací.

Aplikace jsou napsané debilně z jediného důvodu - protože jejich autoři nedostali od vývojářů filesystémů žádnou jinou možnost.

[Ivan]

>Ano, toto jsou přesně ty "debilně napsané aplikace" o kterých jsem psal. Linux poskytuje volání, které zaručeně uloží data na disk. >Pokud aplikace potřebuje mít data na disku, musí použít t oto volání. Vše ostatní je výmluva. Databáze používají své soubory běžně s O_DIRECT/fsync a přesto jsou rychlé.

Databaze jsou rychle prave proto, ze fsync nepouzivaji. Jeste ze existuje mmap a msync.

[geebranz]

polebarnsboise.com