Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Tento článek je překlad z LWN.net.
Současné vývojové jádro je 2.6.31-rc8 vydané 27. srpna. Tohle by mělo být poslední -rc a rozhodně se to tu zklidňuje. Je v něm 131 commitů a je poměrně triviální. Linus předpovídá, že konečné vydání 2.6.31 bude 7. září.
Během minulého týdne nevyšly žádné stabilní aktualizace, v době psaní tohoto článku se ani žádné nerevidují.
-- Ted Ts'o
-- Russell King
-- Con Kolivas je zpátky.
Linuxový „zcela férový plánovač“ [completely fair scheduler] funguje tak, že dělí dostupný čas CPU mezi procesy, které chtějí běžet. V mnoha situacích nicméně procesy běžící v systému svůj podíl nakonec nevyužijí; mohou například strávit tolik času čekáním na I/O, že jednoduše nemohou běžet dost dlouho na to, aby spotřebovaly veškerý čas, který je jim přidělen. V takové situaci CFS věnuje přebývající čas procesům, které intenzivněji využívají CPU a které ho tak mohou dobře využít, i když svůj podíl již překročily.
To je normálně dobře; lepší je čas CPU dobře využít a nenechávat ho bez práce, když existují procesy, které chtějí běžet. Zdá se ale, že jsou situace, ve kterých správci systémů nechtějí tímto způsobem přebytečný čas CPU rozdávat. Pokud například procesy patří zákazníkovi, který platí za určité množství času CPU, dávat mu víc není dobrý obchod. Aby k tomu nedocházelo, vytvořil Bharata B Rao sadu patchů pro pevné limity CFS. Pevné limity [hard limits] jsou spravovány s použitím kontrolních skupin; umožňují správci nastavit absolutní limit množství času CPU, který může kontrolní skupina jako celek použít za dané období reálného času. Naúčtování plateb uživatelům, kteří chtějí svůj limit zvýšit, je samozřejmě záležitost politiky v uživatelském prostoru, takže není součástí patche.
Operace „vyřazení“, která informuje blokové úložné zařízení, že se specifické bloky již nepoužívají, by měla pomoci široké škále úložných technologií – včetně úložišť bez rotujících částí a „tence vybavených“ [thin provisioned] polí – dosáhnout vyšších výkonů. Vyřazování samo o sobě má ale výkonnostní potíže; detaily vizte v článku Problém s vyřazováním.
Christoph Hellwig se snaží vylepšit výkonnost vyřazování novou sadou patchů, z níž některé původně přišly od Matthewa Wilcoxe. Tyto změny umožňují vyřazovacím požadavkům pokrýt mnohem větší oblasti úložného zařízení; předtím byla velikost omezena maximální velikostí požadavku pro zařízení. Když se zkombinuje s ioctl() příkazem XFS_IOC_TRIM, umožňuje tato změna uživatelskému prostoru vyslat v příhodné době hromadné vyřazovací operace pro všechny volné části souborového systému. Patche také zlepšují kontrolu nad tím, jestli specifický vyřazovací požadavek má být považován za bariéru a jestli by se měl provést jako blokující operace.
Nespokojen s tím, že přepracoval API síťových ovladačů již jednou (přesunem operací do jejich vlastní struktury), má nyní Stephen Hemminger sadu patchů, která mění API implementované všemi ovladači. Jedná se o funkci ndo_start_xmit(), kterou síťová vrstva používá k předání paketů ovladači k vyslání. Tato funkce by ve skutečnosti měla vracet pouze jednu ze dvou hodnot: NETDEV_TX_OK (paket byl přijat a zařazen do fronty k odeslání) a NETDEV_TX_BUSY (paket nebyl přijat, protože fronta byla plná nebo se objevil podobný problém). Ovladače používající zastaralý režim LLTX mohou také vrátit NETDEV_TX_LOCKED, čímž sdělují, že vysílací zámek je již obsazen.
Problém je v tom, že typ návratové hodnoty ndo_start_xmit() byl definován jako int; někteří autoři ovladačů si proto mysleli, že mohou síťové vrstvě vracet libovolné chybové kódy. Se Stephenovým patchem se tento typ mění na netdev_tx_t, což je enum obsahující pouze definované návratové kódy. To by mělo podchytit všechny autory ovladačů, kteří se pokouší vracet nesmysly – ale za cenu změny mnoha ovladačů.
Je zde nová wiki zaměřená na sbírání informací o rychle se vyvíjející funkci kontrolních bodů/restartu. V současnosti je poměrně prázdná, ale lze předpokládat, že bude brzy zaplněna informacemi.
Skutečná práce na kontrolních bodech/restartu stále zůstává cvičením ze složitosti. Jako příklad vezměme nejnověji zaslané kousky: Funkčnost kontrolního bodu a restartu pro bezpečnostní údaje. Vyžaduje mnoho háčků [hooks] v LSM modulech, aby získala informace o současném stavu zabezpečení, seřadila je a někdy v budoucnu obnovila. Pravděpodobně to vše lze donutit k práci, ale dlouhodobá údržba se může ukázat jako problematická.
Con Kolivas, který v minulosti pracoval na problémech s interaktivitou na desktopu a v roce 2007 znenadání vývojovou komunitu jádra opustil, zaslal nový plánovač nazvaný BFS. Říká k němu:
(S tím spojené vlákno vizte v v původním zaslání na LWN.)
Když vývojáři přemýšlí o vynucení zápisu dat, která zapsali do souboru, na úložné zařízení, obvykle si vzpomenou na systémové volání fsync(). Je ale také možné požadovat synchronní chování pro všechny operace na popisovači souboru buď při open() nebo použitím fcntl(). Podpora pro synchronní příznaky I/O se v 2.6.32 pravděpodobně zlepší, ale tato práce přinesla několik zajímavých otázek, které se týkají současné implementace a dopředné kompatibility.
Pro specifikaci synchronního chování I/O jsou tři standardně definované příznaky:
O_SYNC: Vyžaduje, aby všechny operace zápisu blokovaly, dokud nejsou všechna data a metadata na trvalém úložišti.
O_DSYNC: Podobné O_SYNC kromě toho, že se nepožaduje čekání na změny metadat, které nejsou nutné pro čtení právě zapsaných dat. V praxi O_DSYNC znamená, že aplikace nemusí čekat na zápis pomocných informací (například čas modifikace souboru) na disk. Použití O_DSYNC místo O_SYNC obvykle odstraňuje nutnost zapsat při zápisu inode souboru.
O_RSYNC: Tento příznak, který ovlivňuje pouze čtení, musí být použít zároveň s buď O_SYNC, nebo O_DSYNC. Způsobí, že read() bude blokovat, dokud se čtená data (a možná metadata) nezapíší na disk (je-li to nutné). Tento příznak tedy dává jádru možnost zpozdit zápis dat na disk; může dojít k libovolnému počtu zápisů, ale data není nutné zapsat, dokud je aplikace znovu nečte.
O_DSYNC a O_RSYNC nejsou nové; do relevantních standardů byly přidány během minulých deseti let. Linux je ale nikdy nepodporoval (jsou to volitelné vlastnosti), takže je glibc jednoduše definuje tak, že jsou stejné jako O_SYNC.
Christoph Hellwig pracuje na správné implementaci těchto příznaků se snahou začlenit ji do 2.6.32. V tomto okamžiku by mělo jít o relativně přímočarou změnu; jádro již má nějakou hezkou infrastrukturu pro zapisování dat a metadat. Potenciálně obtížnější je ale provést tuto změnu způsobem, který nejlépe splní očekávání existujících aplikací.
Jsou zde navíc dvě záležitosti, které tento přechod ztěžují víc, než by jeden očekával:
Linux ve skutečnosti nikdy neimplementoval O_SYNC; aplikace místo toho dostávaly O_DSYNC.
Implementace open() v jádře jednoduše ignoruje všechny příznaky, o kterých nic neví. Toto chování lze změnit pouze s rizikem rozbití neznámého počtu aplikací; je to součástí jaderného ABI.
Vzhledem k prvnímu problému uvedenému výše může být jeden v pokušení vytvořit pro O_DSYNC nový příznak a použít ho k získání současného chování, zatímco O_SYNC by získalo sémantiku kompletní synchronizace metadat. Pokud by se to však udělalo takto, aplikace, které budou přeloženy s novou C knihovnou, ale poběží na starém jádře, budou open() předávat neznámý příznak a jádro ho bude poctivě ignorovat. Taková aplikace by potom synchronní chování I/O nezískala vůbec, což téměř určitě není dobře. Je potřeba udělat něco složitějšího.
Také je zde otázka, jakou sémantiku by starší aplikace měly dostat. Jamie Lokier argumentoval, že aplikace požadující O_SYNC chtěly kompletní synchronizaci metadat, i když je jádro podvádělo a neposkytovalo všechno. Když tedy poběží pod novějším jádrem se správnou implementací O_SYNC, měla by stará aplikace obdržet chování O_SYNC. Ulrich Drepper si naopak myslí, že toto chování by se pro staré aplikace měnit nemělo:
Zdá se, že Ulrichův pohled vyhraje z jednoduchého důvodu, že výkonnostní postihy synchronizace dalších metadat se zdají být horší než to, že aplikace dostane sémantiku, se kterou běžela již předtím, i když tato sémantika nebyla taková, jaká byla slíbena.
Christoph naznačil pravděpodobný postup. Interně se z O_SYNC stane O_DSYNC a příznak O_SYNC pro open() bude znamenat O_DSYNC. Systémové volání open() potom bude přijímat nový příznak (neznámé jméno, navrženo bylo O_FULLSYNC a O_ISYNC), který bude před aplikacemi skryt. Na úrovni glibc aplikace uvidí toto:
#define O_SYNC (O_FULLSYNC|O_DSYNC)
Na starších jádrech příznak O_DSYNC (o stejné hodnotě, jakou má nyní O_SYNC) vyvolá stejné chování jako vždycky, zatímco O_FULLSYNC bude ignorováno. Na novějších jádrech tento příznak poskytne kompletní sémantiku O_SYNC. Dokud aplikace nebudou sahat pod kapotu a snažit se manipulovat s příznakem O_FULLSYNC přímo, všechno bude v pořádku.
Jednou z primárních funkcí jakéhokoliv jádra je spravovat výpočetní zdroje hardwaru, na kterém běží. Nedávný patch, jehož autorem je Raz Ben-Yehuda, tento fakt mění tak, že odebere jedno nebo více CPU z kontroly jádra, aby procesy na těchto procesorech mohly běžet nerušeně. „Offline plánovač“, jak Raz svůj patch nazývá, měl poměrně neklidnou plavbu, co se počátečního přijetí týče, ale jak se vlákno na linux-kernel vyvíjelo, jaderní hackeři ustoupili a podívali se na problémy, které se patch snaží řešit – a přišli s jinými potenciálními řešeními.
Základní nápad za offline plánovačem je jednoduchý: Použít možnost odpojení CPU za běhu, aby se procesor odstranil ze systému, ale místo toho, aby byl zastaven, se jinému kódu umožní na něm běžet. Protože se procesor nebude účastnit různých synchronizačních schémat CPU (RCU, spinlocky atd.), ani nebude obsluhovat přerušení, může svou pozornost zcela zaměřit na kód, který na něm běží. Cílem je, aby kód běžící na offline procesoru nikdy netrpěl latencemi zavlečenými jádrem.
Hlavní patch je poměrně malý, poskytuje rozhraní k registraci funkce, která se má zavolat, když se CPU vypne:
int register_offsched(void (*offsched_callback)(void), int cpuid);
To registruje zpětné volání [callback], které se zavolá, když je CPU s daným cpuid vypnuto (tj. odpojeno za běhu). Typicky uživatel bude chtít nahrát modul, který zavolá register_offsched() a následně vypne CPU, což na něm spustí zpětné volání. Když se zpracování dokončí a zpětné volání doběhne, procesor je zastaven. V tomto okamžiku lze CPU opět zapnout a vrátit pod kontrolu jádra.
Toto rozhraní ukazuje na jeden z problémů, na který upozornili potenciální uživatelé offline plánovače: tímto způsobem lze spustit pouze kód běžící v jaderném kontextu, ne v uživatelském prostoru. Protože mnoho z aplikací, které by mohly těžit z toho, že mají CPU jenom pro sebe, jsou existující programy v uživatelském prostoru, změna na jaderný kód je považována za problematickou.
Raz poznamenává, že izolovaný procesor má přístup k celé paměti v systému a jádro má stále přístup k paměti, kterou izolovaný procesor používá. To považuje za výhodu, ale ostatní, hlavně Mike Galbraith, vidí věci jinak:
Jedním z hlavních problémů, které jaderní vývojáři vidí u přístupu offline plánovače, je, že Linux je zcela obcházen. To je samozřejmě cílem patche: Věnovat 100 % CPU konkrétní úloze. Jak to říká Christoph Lameter:
To však Peter Zijlstra považuje za hlavní nevýhodu: Obcházení jádra neprospívá nikomu, tím méně Linuxu. K tomu říká, že existují způsoby, jak udělat to samé, takže přidávat do jádra další nemá význam:
Raz však ví o mnoha uplatněních pro procesory, které by byly vyhrazeny specifickým úlohám. Představuje si jiný druh systému, který nazývá Na službu orientovaný systém [Service Oriented System, SOS], kde je jádro pouze jednou komponentou a pokud vyrušuje specifickou službu, mělo by být odstraněno z cesty:
Odstranění jádra z cesty není mezi mnoha jadernými hackery příliš populární, ale nápad zcela vyhradit procesor specifické úloze je pro některé uživatele důležitý. Ve světě vysoce výkonných výpočtů [high performance computing, HPC] několik procesorů tráví svůj čas jediným úkolem, který obyčejně chroustá čísla. Odstranění i minimálních přerušení, těch, která provádí plánování a další jaderné domácí práce, vede k lepší celkové výkonnosti. Tito uživatelé v podstatě chtějí pohodlí Linuxu běžícího na jednom CPU, zatímco zbytek systému se věnuje jejich konkrétní aplikaci.
Po poněkud rozvášněné odbočce o obecném snížení latencí v jádře Andrew Morton žádal o vyjádření problému: Všechno, co jsem zatím viděl, je ,Chci 100% přístup k CPU‘. To není vyjádření problémů – to je implementace. Ve své odpovědi Chris Friesen popsal jednu možnou aplikaci:
To vedlo Thomase Gleixnera k tomu, že zvážil alternativní přístup. Přeformuloval problém takto: Spustit přesně jedno vlákno na dedikovaném CPU bez jakéhokoliv vyrušování tikem plánovače. Vzhledem k této definici poté navrhl poměrně jednoduchý přístup:
Gregory Haskings poté navrhl změnu plánovací třídy FIFO nebo vytvoření nové třídy s vyšší prioritou tak, že se zakáže tikání plánovače. To by zakomponovalo Thomasův nápad do existujícího frameworku plánování. Jak lze uhodnout, stále je potřeba vyřešit nějaké detaily ohledně provozu procesů bez tiku plánovače, ale Thomas a ostatní si myslí, že jde o něco, co lze udělat.
Offline plánovač sám o sobě v diskuzi poněkud zapadl. Není překvapivé, že Raz stále protlačuje svůj přístup, nicméně v tom je kromě nechuti k obcházení jádra problematická i neschopnost spouštět kód v uživatelském prostoru. Thomas to řekl poměrně stroze:
Nad problémem se zamýšlejí i jiní, nápad podobný Thomasovu nedávno na linux-kernel zaslal Josh Triplett jako RFC. Joshův malinký patch jednoduše zakazuje tikání čítače permanentně jako demonstraci výkonnostního zisku, kterého lze dosáhnout pro procesy vázané na CPU. Poznamenává, že režie tiku časovače může být významná:
Josh varoval, že jeho patch ani omylem nepředstavuje hotové řešení, protože rozbíjí RCU, účtování procesů a další věci. Ale nabootuje a dokáže spustit jeho testy. Pro některé z problémů má Josh rozpracované opravy a stejně tak má i celkový cíl: Rád bych se dopracoval k patchi, který dokáže skutečně zabít tik časovače, aby bylo jádro úplně řízené událostmi a odstranilo se dotazování [polling], ke kterému při tiku časovače dochází. Prohlédl jsem všechno, co tik čítače dělá, a do posledního bitu to může zastat přístup založený na událostech.
Je dost nepravděpodobné, že bychom se někdy dočkali toho, že se offline plánovač dostane do hlavní řady jádra, ale nápad za ním vedl ke vzniku několika zajímavých diskuzí, které možná povedou k řešení pro ty, kteří se pokouší odstranit režii jádra na vybraných CPU. V mnoha ohledech je to další příklad nebezpečí vývoje kódu v izolaci. Kdyby Raz pracoval otevřeně a sháněl komentáře od jaderné komunity, mohl si mnohem dříve uvědomit, že jeho přístup nebude akceptovatelný – přinejmenším pro hlavní řadu.
Technologie jako žurnálování souborového systému (což se používá i u ext3) nebo RAID jsou obecně přijímány za účelem zlepšení celkové spolehlivosti. Někteří správci systémů tedy mohli být poněkud znepokojeni nedávným vláknem na linux-kernel, kde bylo naznačeno, že v některých situacích tyto technologie ve skutečnosti zvyšují riziko ztráty dat. Tento článek se pokouší vyjasnit argumenty a dospět k závěru o tom, jak velké obavy by správci systémů měli mít.
Konverzace ve skutečnosti začala v březnu, kdy Pavel Machek navrhl patch dokumentace popisující předpoklady, které viděl v návrhu souborových systémů pro Linux. Věci na chvíli utichly, ale na konci srpna došlo k oživení. Zdá se, že Pavel narazil na nějaké problémy se ztrátou dat, když používal flash disk s nespolehlivým připojením k počítači; následující testy provedené úmyslným odebíráním aktivních disků potvrdily, že je snadné data takto ztratit. To neočekával:
Ve snaze zabránit nárůstu požadavků o vrácení školného po celém světě se Pavel pokusil vložit do dokumentace jádra nějaké varování. Narazil na překvapující odpor, který považoval (a nejenom on) za pokus zamést nedostatky Linuxu pod koberec. Skutečný příběh je přirozeně o něco složitější.
Technologie žurnálování, jaká se používá v ext3, funguje tak, že se některá data do souborového systému zapisují dvakrát. Kdykoliv musí souborový systém provést změnu metadat, nejprve vytvoří seznam všech potřebných změn na úrovni bloků a zapíše je do speciální oblasti na disku (do žurnálu). Jakmile je známo, že se kompletní popis změny dostal na fyzické úložiště, je zapsán „záznam o vykonání“ [commit record], který oznamuje, že souborový systém změnu provede. Jakmile je bezpečně uložen i záznam o vykonání, kód souborového systému může začít zapisovat změny přímo do souborového systému na fyzickém úložišti. Pokud je tato operace přerušena (selháním napájení, pádem systému nebo náhlým vyjmutím disku), souborový systém může obnovit plán změn z žurnálu a začít odznova. Konečným výsledkem je, že změny metadat probíhají v transakcích; buď doběhnou úplně, nebo vůbec. A to by mělo zabránit poškození struktury souborového systému.
Zde stojí za to poznamenat, že data jako taková do žurnálu zapisována nejsou, takže při nenadálém selhání může dojít ke ztrátě nedávno zapsaných dat. Je možné nakonfigurovat ext3 (a ext4) tak, aby se do žurnálu zapisovala i data, ale vzhledem k významnému poklesu výkonnosti se tato volba příliš nepoužívá. Žurnálování poskytuje nějakou ochranu dat i tak – když se ztratí metadata, nelze najít ani data s nimi spojená – to ale není důvod k jeho existenci.
Není to ale chybějící žurnálování dat, co Pavlovi a dalším způsobilo starosti. Povaha zařízení založených na flash totiž umožňuje další „zajímavý“ způsob selhání. Souborové systémy pracují s bloky pevných velikostí, v Linuxu je to běžně 4096 bytů. Úložná zřízení také používají bloky pevné velikosti; na tradičních rotujících discích jsou tyto bloky tradičně 512 bytů dlouhé, i když větší velikosti bloků jsou již na obzoru. Klíčové je zde to, že na normálním rotujícím disku může souborový systém zapsat blok bez ovlivnění dalších nesouvisejících bloků na disku.
Flashové úložiště také používá bloky pevných velikostí, ale ty bývají větší – typicky od desítek do stovek kilobytů. Bloky na flash úložišti lze přepsat pouze jako celek, takže zápis „bloku“ o velikosti 4096 bytů na úrovni operačního systému znamená uvnitř flash disku větší cyklus čtení-změna-zápis. Pro pečlivého programátora je rozhodně možné vytvořit pro takový disk firmware, který tuto operaci provede bezpečným transakčním způsobem. Je také možné, že výrobce disku mnohem více než pečlivé programování zajímá, jak co nejrychleji dostat na trh levné zařízení. Na trhu běžného hardwaru pro PC se tato druhá možnost stává spíše jistotou.
To vše znamená, že na nekvalitním flash disku přerušená operace zápisu může vést k poškození bloků, které s operací nesouvisejí. Pokud byl přerušen zápis metadat, žurnálovací souborový systém operaci zopakuje při příštím připojení, čímž zajistí, že metadata skončí na svém zamýšleném umístění. Souborový systém ale nemůže vědět nic o blocích, které byly zničeny, takže proti tomuto druhu selhání žurnálování nechrání – i když způsobí poškození metadat, kterému mělo zabránit.
Toto je „chyba“, kterou chtěl Pavel zdokumentovat. K tomu tvrdil, že žurnálovací souborové systémy mohou v takové situaci věci zhoršit. Vzhledem k tomu, že u žurnálovacích souborových systémů nebývá zapotřebí kompletní fsck ani při chybném odpojení, na poškození metadat se nepřijde. To přinejlepším může znamenat, že se uživatel nějakou dobu nemusí dozvědět o ztrátě dat, při nejhorším poškozená metadata způsobí, že kód při dalších operacích poškodí i jiné části souborového systému. Vynechané fsck umožní systému nabootovat rychle, ale za cenu rizika, že poškození přetrvá nebo se bude šířit.
Dalo by se snadno argumentovat, že skutečný problém spočívá ve skrytých překladových vrstvách, díky kterým flash zařízení vypadá jako normální disk. Přesně to udělal David Woodhouse:
Výrobci flash disků jsou nicméně k těmto argumentům hluší.
Byl také diskutován podobný problém u zařízení RAID. Disky lze seskupit do pole RAID5 nebo RAID6 s tím, že pole jako celek může přežít kompletní selhání kteréhokoliv disku v něm. Dokud selže jenom jeden disk, uživatel RAID pole si může být jistý, že kouř vycházející z pole s sebou neodnáší data.
Co když ale selže víc než jeden disk? RAID funguje tak, že seskupuje bloky do pruhů [stripe] a vytváří kontrolní součty těchto pruhů. Aktualizace bloku vyžaduje přepis pruhu, který ho obsahuje, a s ním spojeného bloku kontrolního součtu; pokud tedy zápis bloku může způsobit, že pole ztratí celý pruh, můžeme se dočkat stejné ztráty dat jako na flash disku. Za normálních okolností k tomuto druhu ztráty dat v RAID poli nedojde. Může k němu ale dojít, pokud (1) jeden disk již selhal a pole běží v „degradovaném“ režimu a (2) dojde k druhému selhání (řekněme, že Pavel vytáhne zástrčku), když probíhá zápis.
Pavel z toho vyvodil, že RAID zařízení mohou být ve skutečnosti nebezpečnější, než ukládání dat na jediném disku; založil ohledně toho celé oddělené podvlákno (pod názvem raid je nebezpečný, ale to je tajné). Toto tvrzení způsobilo v konferenci poměrně značné znepokojení; mnozí měli pocit, že to přesvědčí uživatele, aby místo technologií, jako je RAID, používali konfigurace s jediným diskem bez redundance. Uživatelé, kteří by to udělali, by se vyhnuli možnosti ztráty dat kvůli specifickému nepravděpodobnému dvojitému selhání za cenu toho, že by byli naprosto bezbranní vůči mnohem pravděpodobnějšímu jedinému selhání. Konečným výsledkem by bylo mnohem více ztracených dat.
Skutečná lekce z této diskuze je poměrně jednoduchá:
S flash disky zacházejte opatrně, neočekávejte, že jsou spolehlivější, než skutečně jsou, a nevyjímejte je ze systému, dokud se všechny zápisy nedokončí.
RAID pole mohou zvýšit spolehlivost dat, ale pole, které neběží s plným počtem funkčních disků ztrácí redundanci, která tuto spolehlivost poskytuje. Pokud by důsledky dalšího výpadku byly příliš vážné, člověk by se měl vyhnout zápisům na pole běžící v degradovaném režimu.
Jak upozornil Ric Wheeler, nejsnazší způsob, jak v linuxovém systému ztratit data, je používat disky s povolenou zápisovou cache. To je obzvláště pravdivé pro systémy s RAID5/6, kde stále nejsou správně podporovány zápisové bariéry. Mluvilo se o zakázání zápisových cachí disku a povolení bariér ve výchozím nastavení, ale žádné patche zaslány nebyly.
Nic nenahradí dobré zálohy. K tomu by autor článku Jonathan Corbet rád podotkl, že u zálohy, která nebyla nedávno zkontrolována, je značná šance, že to nebude dobrá záloha.
Jak se tato informace odrazí v dokumentaci jádra, se uvidí. Částečně se jedná o ten druh informace pro správu systémů, jejíž začlenění do dokumentace jádra samotného nebývá uznáno za vhodné. Má ale smysl vědět, na jakých předpokladech je vystavěn souborový systém a jaké jsou možné způsoby selhání. Lepší pochopení toho, jak může dojít ke ztrátě dat, nám může jenom pomoci zabránit tomu, aby se tak skutečně stalo.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
prvý apríl? 
Spise si tazatel nevsiml, ze jaderne noviny vzdycky vychazeji se zpozdenim.
> 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.
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.
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.
Dokonce i takovy wokna umoznuji oznacit NTFS jako "dirty" tim si vynutit plnou kontrolu filesystemu po rebootu.
Linuxové distribuce ne?
29.9.2009 20:59
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
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.
... 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!"
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.
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?
2.10.2009 11:55
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
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ší.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
29.9.2009 09:57