Jaderné noviny – 9. 6. 2010

30. 6. 2010 | Jirka Bourek | Jaderné noviny | 3182×

Aktuální verze jádra: 2.6.35-rc2. Citáty týdne: Linus Torvalds, Andrew Morton. Nativní port ZFS pro Linux (OSNews). Epizoda „Zoufalých Androidů“ z tohoto týdne. Další přepis OOM zabijáka.

Obsah

• Aktuální verze jádra: 2.6.35-rc2
• Citáty týdne: Linus Torvalds, Andrew Morton
• Nativní port ZFS pro Linux (OSNews)
• Epizoda „Zoufalých Androidů“ z tohoto týdne
• Další přepis OOM zabijáka

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

Současné vývojové jádro je 2.6.35-rc2 vydané 5. června. Tak, -rc2 je venku a doufejme, že opravuje víc problémů než zavádí. Trochu se mi nelíbí jeho velikost – uznávám, že není tak velké jako rc2 v minulém vývojovém cyklu, ale tam to také bylo neobvykle velké rc2. A tentokrát jsem opravdu doufal, že vývojový cyklus bude klidnější. Přibylo několik nových ovladačů a spousta oprav; zkrácený changelog je v oznámení, všechny detaily najdete v kompletním changelogu.

Stabilní aktualizace: Během minulého týdne žádné stabilní aktualizace nevyšly.

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

Takže uvidíme, jak bude nakonec vývojový cyklus 2.6.35 vypadat. Pokud by přísnější zkracování věci zjednodušilo a vývojový cyklus díky tomu fungoval lépe, rozhodně mi nebude činit problémy být ještě tvrdohlavější.

A řekl bych, že to ani nebude tak problematické, až si lidé zvyknou. A jestli to opravdu pomůže podsprávcům („To udělat nemůžu, protože Linus by výsledek stejně nezačlenil“), pak to pro mě bude docela dobrý důvod být ohledně pravidel ještě striktnější.

-- Linus Torvalds

Linus by to začlenil.

> Kubys

Ale jeho zlé dvojče mu sebralo klávesnici.

-- Andrew Morton (díky Valerii Auroře)

Protiargument, který podle všeho nikdo nevznesl, je, že blokování uspání existuje, je to skutečný kód a dodává se v mnoha strojích.

To je velký argument ve prospěch blokování uspání. Rozhodně větší než argument pro alternativu, která vůbec nebyla testována a která je založena na nějakých tvrzeních o složitosti.

Jinými slovy jsem rozhodně doufal, že tato diskuze se víc týká kódu, který existuje a který dělá to, co lidé potřebují. Podle všeho zdegenerovala do něčeho jiného.

-- Linus Torvalds

Nativní port ZFS pro Linux (OSNews)

OSNews hlásí, že zaměstnanci americké Národní laboratoře Lawrence Livermorea [Lawrence Livermore National Laboratory] portovali souborový systém ZFS Sunu/Oraclu na Linux. Jaderný modul je distribuován ve formě zdrojových kódů, aby se obešla nekompatibilita licencí CDDL a GPL. Hlavní vývojář Brian Behlendorf také řekl, že LLNL opakovaně žádala Oracle, aby se situací ohledně licence něco udělal a ZFS se mohlo stát součástí jádra. ,Pracujeme na tom již nějaký čas a snažíme se přesvědčit Sun/Oracle, aby změnili licenci,‘ vysvětluje, ,bohužel musím říci, že jsme zatím neměli štěstí.‘ […] Stále ještě zbývá dokončit významný kus práce, takže se kód nehodí pro produkční nasazení. Ještě nebyla implementována posixová vrstva ZFS, takže připojení souborového systému zatím není možné; již je ale možný přímý databázový přístup.

Epizoda „Zoufalých Androidů“ z tohoto týdne

napsal Jonathan Corbet, 7. června 2010

V poslední epizodě tohoto nekončícího seriálu jsme popsali kritiku, která blokovala začlenění blokování uspání, a nárys řešení, které se vynořilo z ruin. Oznámit, že tento příběh končí, je ale vždycky risk; nyní se zdá, že by diskuze o blokování uspání mohla vydržet ještě jeden či dva vývojové cykly.

4. června Ingo Molnár zaslal navrhované řešení, které bylo variantou přístupu založeného na kvalitě služby, který jsme popsali minulý týden. Vypadalo použitelně, dokud Linus (poprvé) nezabloudil do diskuze a neřekl:

Upřímně to vypadá naprosto nefunkčně. Vem v úvahu deadlocky. Úloha s vysokou latencí získala zámek a ty ji nyní vynecháváš, protože ji plánovač odstraňuje.

A diskuze začala nanovo. Linus tlačil na řešení, které se vyhýbá vnitřním částem jádra (a konkrétně plánovači), jak jenom je to možné – což je cíl, který původní implementace blokování uspání sdílela. Také nastolil otázku vícejádrových procesorů, kterou současný kód neřeší. Mohlo by být užitečné vypnout jednotlivá jádra, když zátěž systému poklesne, a uspat systém, když nemá co na práci ani poslední CPU. Dalo by se předpokládat, že vícejádrová zařízení do ruky nejsou záležitost tak vzdálené budoucnosti, takže připravit se na ně vypadá rozumně.

Situace se tedy zkomplikovala – také se ale zdá, že narostla vůle ji vyřešit. Je zjevné, že skutečné řešení se asi neobjeví rychle, takže v mezičase možná dojde na dočasné řešení, které bylo navrženo v počátku diskuze: Přidat omezenou verzi API blokování uspání, aby bylo možné začlenit ovladače Androidu beze změn. To by mělo pomoci hlavní řadě i jádrům Androidu přiblížit se a přitom poskytnout čas na globálně akceptovatelné řešení problému blokování uspání. Tato omezená verze bude pravděpodobně začleněna s tím, že doba spotřeby vyprší v 2.6.27; spornější věci přijdou poté.

Další přepis OOM zabijáka

napsal Jonathan Corbet, 7. června 2010

Nikdo nemá rád zabijáka při nedostatku paměti [OOM killer]. Jeho úkolem je skrývat se mimo dohled do toho nešťastného dne, kdy systému dojde paměť a nebude moci nic dělat; OOM zabiják poté musí vybrat proces, který obětuje ve jménu nepřetržitého běhu. Je to ošklivá práce, o které si mnozí myslí, že by ji nemělo být zapotřebí. Ale přestože OOM zabiják není populární, stále ho máme po ruce; považujeme ho za jaderný ekvivalent právníků nebo výběrčích daní. Jednou za čas je užitečný.

Reputaci OOM zabijáka moc nepomohl fakt, že často vybírá špatnou oběť. Fakt, že byl běžící systém zachráněn, je jenom malá útěcha, když byly zabity užitečné procesy a ztraceny výsledky práce. Během let se mnoho vývojářů pokoušelo zlepšit sadu heuristik, kterou OOM zabiják používá, podle všeho s určitými úspěchy; stížností na špatný výběr je méně než dříve. OOM zabiják ale stále není perfektní, takže další a další vývojáři míří svá kopí na tento větrný mlýn.

Posledních několik měsíců úloha vylepšit OOM zabijáka padla na Davida Rientjese, který zaslal několik verzí svojí sady patchů přepisu OOM zabijáka. O této verzi doufá, že ji bude možné začlenit do 2.6.36; revizemi prošla již několikrát, ale ještě není jasné, jaký nakonec bude její osud.

Větší část sady patchů je věnována relativně přímočarým opravám a zlepšením, která nejsou obzvláště kontroverzní. Jedna změna otevírá poslední jadernou rezervu paměti procesům, které se buď ukončují, nebo jim má být doručen smrtící signál; to by jim mělo umožnit uklidit po sobě a rychle uvolnit paměť. Další změna brání zabíjení procesů, které jsou v jiné paměťové alokační doméně [memory allocation domain] než v té, ve které došla paměť; zabití těchto procesorů není férové a situaci s největší pravděpodobností nevyřeší. Jestliže je OOM situace důsledkem omezující politiky, za cíle jsou považovány jenom procesy, které mohou uvolnit stránky na uzlech, které tato politika řídí.

Další zajímavá změna se týká zabíjení potomků. Současný OOM zabiják poté, co si vybere oběť své nevítané pozornosti, zamíří na jednoho z potomků tohoto procesu, pokud nějací potomci existují. Zabití rodiče pravděpodobně potomky stejně zlikviduje také, takže pročištění potomků – alespoň těch, které mají vlastní adresovací prostor – by mohlo problém vyřešit s menšími ztrátami. Aktualizovaný OOM zabiják dělá totéž, ale s mířením – pokouší se zamířit na potomka, který má největší skóre „špatnosti“ [badness]. Cílem je zvýšit šance na rychlé a skutečné uvolnění paměti.

Další změna ovlivňuje chování, když je vyčerpána paměť v zóně dolní paměti [low memory zone]. Tato zóna přítomná na 32bitových systémech s 1 GB paměti nebo více je potřeba tam, kde musí mít jádro možnost použít přímý ukazatel. Občas se také používá pro DMA I/O. Když tato paměť dojde, říká David, zabíjení procesů ji pravděpodobně neuvolní a mohlo by způsobit skutečné potíže. Místo volání OOM zabijáka tedy požadavky na alokaci dolní paměti jednoduše selžou, pokud není přítomen příznak __GFP_NOFAIL.

Přidána byla nová heuristika „penalizace forkbomb“. Jestliže má proces velký počet potomků (kde výchozí hodnota „velkého“ je 1000) s méně než vteřinou doby běhu, je považován za fork bombu. Když taková situace nastane, je skóre upraveno tak, aby takový proces byl mnohem pravděpodobněji OOM zabijákem zvolen. Politika „zabití nejhoršího potomka“ zde stále platí, takže výsledkem tohoto řešení řešení bude fork bomba s 999 potomky. I v tomto případě je ale zabíjení potomků po jednom považováno za lepší výsledek než zabití potenciálně důležitého serverového procesu.

Nejkontroverznější část patche je kompletní přepis funkce badness(), která každému procesu v systému přiřazuje skóre. Tato funkce obsahuje většinu heuristik, kterými se určuje, který proces si nejvíce zasluhuje služby OOM zabijáka; postupem času se v ní nahromadilo mnoho testů, které se pokouší identifikovat procesy, jejichž skon by uvolnil nejvíce paměti a přitom uživateli způsobil co nejméně nepříjemností.

V Davidově sadě patchů staré heuristiky badness() téměř mizí. Místo toho se výpočet mění v jednoduchou otázku toho, kolik procent dostupné paměti proces používá. Jestliže celému systému dochází paměť, pak je „dostupná paměť“ součet celkové dostupné RAM a swapu v systému. Jestliže OOM situaci způsobuje vyčerpání paměti dostupné dané řídící skupině/cpuset skupině, pak je „dostupná paměť“ celkové množství alokované pro danou řídící skupinu. Podobný výpočet se provádí, pokud byly překročeny limity vynucené politikou paměti. Ve všech případech je využívání paměti procesem získáno součtem rezidentní sady [resident set] (počet stránek v RAM, které proces používá) a využitého swapu.

Výsledkem tohoto výpočtu je počet procent vynásobený deseti; proces, který využívá poslední byte jemu dostupné paměti, bude mít skóre 1000; proces, který nevyužívá žádnou paměť, bude mít nulu. Toto skóre je heuristicky laděno jenom minimálně, kód ale stále odčítá malou hodnotu (30) od skóre procesů vlastněných rootem s tím, že jsou o něco cennější než procesy vlastněné uživateli.

Další úprava hodnoty je přičtení hodnoty uložené v proměnné oom_score_adj každého procesu; tu lze nastavit pomocí /proc. Tato hodnota umožňuje upravit to, jak moc je OOM zabiják k danému procesu přitahován. Nastavení -1000 OOM zabijáka úplně vypne, zatímco nastavení na +1000 znamená, že danému procesu je na záda namalován obrovský terč. Jeden z důvodů, proč je tento patch kontroverzní, je odlišné jméno a sémantika této hodnoty od oom_adj, kterou OOM zabiják aktuálně používá; jinými slovy je to změna ABI. David implementoval mapovací funkci mezi těmito dvěma hodnotami, kterou se snaží problémy zmírnit; oom_adj je zastaralé [deprecated] a roku 2012 má být odstraněno.

Opozice vůči této změně ale zachází za potíže s ABI. Pochopit proč není vždy jednoduché; reakce jednoho z revidovatelů je jediné slovo nack. Námitky se podle všeho týkají toho, že patch úplně nahrazuje badness() místo toho, aby ji rozvíjel novým směrem; také se objevily obavy, že bude mít nový algoritmus horší výsledky. Je pravda, že nebyly zaslány žádné přesvědčivé důkazy, které by tuto změnu ospravedlňovaly, ale získat v tomto případě přesvědčivé důkazy je obtížné. Není žádný jednoduchý benchmark, který by dokázal kvantifikovat rozhodnutí OOM zabijáka. Máme tedy k dispozici jenom odpovědi jako:

Několikrát jsem řekl, že oom zabiják na mém desktopu už nezabíjí KDE, když spustím proces, který zabírá paměť a který je napsán specificky k tomu, aby způsobil oom. To je lepší výsledek, než má současná implementace…

Patche správy paměti bývá obtížné začlenit a přepis OOM zabijáka rozhodně nebude výjimka. V tomto případě to začíná vypadat tak, že bude zapotřebí vyšší moc, která zasáhne a rozhodne. A skutečně, Andrew Morton je připraven zasáhnout, řekl:

Nepodložená „nack“ jsou k ničemu a budu je ignorovat a rozhodovat se sám. Jestliže máte specifické námitky, sem s nimi. Detailně, prosím – a neodkazujte se na předchozí konverzaci, protože ta je příliš matoucí – začít znova má své výhody.

V závislosti na tom, jak se Andrew rozhodne, tedy může být v 2.6.36 na skladě nový OOM zabiják. Pro většinu uživatelů bude tato nová vlastnost asi tak vzrušující, jako když dostanou k narozeninám nový záchodový čistič, ale pokud to někdy pomůže jejich systému dobře přežít OOM situaci, nakonec ji ocení.

       

Komentáře

[Bedňa]

Jak pekne začínajú tie riadky o ZFS, už som sa tešil že budem mať čím nahradiť Reisera, ale zas nič.

[xm]

Btrfs je pro Linux podstatně lepší řešení než ZFS.

[VSi]

Proč? (bez ironie)

Má (bude mít) Btrfs vlastnosti ekvivalentní výhodám ZFS? Jako RAID-Z, kontrolní součty dat i metadat (tohle asi ano), co možná největší zajištění konzistence při výpadku napájení a ztrátě obsahu cache, klasické user a group kvóty (ne jenom kvóta na adresář / filesystem). V low-level architektuře se tolik nevyznám, ale z prezentace o ZFS jsem měl pocit, že je to fakt hodně chytře udělané. Možná jen dobrý marketing SUNu.

Jinak bude asi trvat velmi dlouho, než Btrfs dosáhne kvality a spolehlivosti ZFS. ZFS je už nějaký čas v produkčním nasazení, jsou na něm reálná data. Četl jsem i velmi zajímavý článek o automatizovaných testech ZFS - mají stovky strojů, na kterých se ZFS automaticky testuje vč. tvrdých výpadků napájení, poškození dat na discích apod.

[Laco]

Ty brdo vy ste iny magori, riesite somariny ako file system. Kupte si Windows 7 a zacnite zit normalny zivot...

[F.]

Az bude vediet napr. win2008 server nabootovat zo zariadenia, ktore bude obsahovat particiu vacsiu ako 2TB, tak sa nad MS riesenim bude tak mozno aj uvazovat...

[Laco]

Ano bezpochyby je to hanba, posrate 2TB, dnes uz to ma kazdy mobil... LOL :)

[Jakub Lucký]

Vy instalujete Windows server na mobil? Já instaluju serverový OS na server. A server může mít pole. Třeba z 32 disků... a to je pak hodně TB

[Jardík]

Windows Server 2008, tak Windows Vista a Windows 7 z takového oddílu nabootovat "umí". Resp. nabootuje ho EFI. A pokud tvůj komp EFI nemá, tak si říkáš o problémi i v Linuxu. Sice to grub tak tak rozchodí a je schopný z toho různými "hacky" nabootovat, ale takový gparted ještě nedávno na GPT disku rád promazával zavaděč v MBR.

[F.]

Osobne som to neriesil, kedze nemam v sprave windows servery, ale kolegovia s tym bojovali a vysledok bol (lovim v pamati), ze po konzulacii s Dellom/MS a prehrabani sa googlom bol vysledok vytvorit na poli jeden "logicky" disk na system (/dev/sda) mensi ako 2TB. Druhy "logicky" disk (/dev/sdb) sa potom riesil vo windowse z cmd, kde sa urobil prevod na gpt a potom to uz nemalo problem s 2TB limitom. Problem bol, ze win2008 proste nevedel z instalatora vytvorit viac ako 2TB (a ak sa to napr. nastavilo inak napr. z linuxu) a chcelo sa instalovat, tak win nebol ochotny z takejto particie bootnut (ak malo to zariadene, z ktoreho sa malo bootovat GPT). Povodny zamer bol totiz /dev/sda1 (system) a /dev/sda2 (data).

[xm]

Doporučuji k přečtení článek Krátká historie Btrfs (překlad článku od věhlasné Valerie Aurory). Sice je už trochu staršího data, ale dost toho vysvětluje.

[Milan Jurik]

Ty jo, Valerie uz je dokonce vehlasna Jen nevim, jak odpovida na otazky tazatele

[xm]

Ano, věhlasná mezi vývojáři souborových systémů opravdu je. Ten článek mimo jiné ukazuje, proč má Btrfs lepší návrh než ZFS a proč je vhodnější pro Linux. Co se týče vlastností Btrfs, tak ty jsou přehledně popsány např. na btrfs.wiki.kernel.org.

[Milan Jurik]

Kazdy chapeme vyznam slova "vehlasna" asi jinak. Ja jen muzu soudit na zaklade toho, cim skutecne prispela

btrfs ma nepochybne novejsi design (ktery umoznuje jistou podmnozinu operaci implementovat jednodusseji), ale ani ten dalsi odkaz neodpovida na otazky tazatele asi dostatecne.

xm, tve navazeni se do ZFS je letite, tva bezmezna ucta k btrfs uz je take dlouhodoba (snad od chvile, kdy se objevil prvni kod). Ale obcas by to chtelo nehazet jen odkazy asi. Cimz btrfs nechci nijak shazovat.

[geebranz]

Quick memory

fencing missoula mt

[Radovan Garabík]

Tato omezená verze bude pravděpodobně začleněna s tím, že doba spotřeby vyprší v 2.6.27

- asi to má byť 2.6.37...

[chrono]

Podľa originálneho článku to má byť naozaj 2.6.37

[pozortucnak]

Jsou pro linux i jiné použitelné souborové systémy s transparentní kompresí? ReiserFS odešel do věčných lovišť, Btrfs je nestabilní, jediné, co se mi zdá (zatím) použitelné je zfs-fuse.

[xm]

Osobně považuji Btrfs už za vcelku stabilní (i když samozřejmě s nějakým kritickým serverových nasazením by asi bylo záhodno pro sichr ještě počkat). Rozhodně lepší než ZFS přes Fuse.

MeeGo ho již nasazuje jako defaultní filesystem. V nejnovějších verzích Ubuntu, Fedory a OpenSUSE už je také podporován (včetně takových vychytávek jako snapshot a případný rollback systému při aktualizacích).

[Nikola Ciprich]

"i když samozřejmě s nějakým kritickým serverových nasazením by asi bylo záhodno pro sichr ještě počkat"

u takto komplexniho fs ktery jeste nema ani stabilni diskovy format? tim jeste pockat myslis aspon 3-5 let ne?

[trekker.dk]

u takto komplexniho fs ktery jeste nema ani stabilni diskovy format?

Podle varování v Kconfigu ne, fakticky jo, diskový formát už se nezměnil hodně dlouho.

[Milan Jurik]

Nesla nahodou pred par dny zprava, ze tvurci zavadeji verzovani formatu, takze by dalsi zmeny formatu mohly byt uz pred uzivateli skryty, tak jako je to ZFS?

[Nikola Ciprich]

to ze se nezmenil uz dlouho jeste nic neznamena, i v dnesnim gitu je stale oznacen jako unstable a cely fs jako experimental, na to bych si dal tak maximalne /tmp, o nejakem nasazeni na servery nemluve...

[poky74]

"ReiserFS odešel do věčných lovišť"

To mi vysvětlete, něco mi uniklo?

[pozortucnak]

Vývoj ReiserFS 4 je přinejmenším nejistý... Potřebuji spolehlivý souborový systém s podporou transparentní komprese. Který byste my doporučil?

Btrfs je nový, když jsem ho nedávno zkoušel, tak měl problémy a komprese nefungovala.

ReiserFS 4 nejistý vývoj...

zfs-fuse - podpora komprese, mělo by to být bezpečné, netřeba kontrolovat integritu dat...

fusecompress - nevěřím mu, co se stane s daty při tvrdém restartu?

Mě z toho vychází nejlépe zfs-fuse, krom toho se vyvíjí jaderný modul...

[poky74]

Však je to dobrej systém, to není nikdo kdo by reisera vyvýjel? Kdy pustěj toho vrahouna?

[JVid]

Edward Šiškin (vývojář Reiser4) plánuje svoje dílo v brzké době začlenit do vanilky, takže by ta nejistota kolem vývoje mohla trochu opadnout, a „starý“ ReiserFS je sice málo udržovaný, ale to je spíš příznakem toho, že je dost stabilní a prostě není potřeba ho dál upravovat. Mimoto do něj nedávno přistálo obrovské množství patchů kvůli akci „Kill the Big kernel lock“, tudíž nějaká údržba probíhá a jeho jaderný kód ještě zcela neosiřel.

Jediný problém ReiserFS je to, že se při návrhu nepočítalo s ACL, kvótami nebo xattry, takže tyhle modernější fce do něj byly dost ošklivě dohackovány a jejich používání není tolik otestováno (osobně mám právě s rozšířenými atributy špatné zkušenosti). Dnes se od jeho používání odrazuje, já ale vážně nevím proč. Pořád je to FS dost rychlý a v porovnání s Ext4 nebo brtfs je IMO i stabilnější.

[trekker.dk]

Edward Šiškin (vývojář Reiser4) plánuje svoje dílo v brzké době začlenit do vanilky, takže by ta nejistota kolem vývoje mohla trochu opadnout

Plánuje neznamená, že mu to projde.

ReiserFS je sice málo udržovaný, ale to je spíš příznakem toho, že je dost stabilní a prostě není potřeba ho dál upravovat.

A přesto je schopný samovolně se rozsypat na funkčním hardwaru.

[JVid]

Plánuje neznamená, že mu to projde.

Doufat ale můžeme, ne?

A přesto je schopný samovolně se rozsypat na funkčním hardwaru.

Myslíš tu známou chybu s xattrs? Hans byl sice hovado, ale věděl, proč nackovat přidávání vlastností, na které ten FS nebyl stavěný. Když ho ostatní vývojáři přehlasovali, mají, co chtěli.

[trekker.dk]

Myslíš tu známou chybu s xattrs?

Myslím, že ne, protože xattrs se tam nepoužívaly.

[Bedňa]

Nenavážaj sa do môjho oblúbeného FS, čo je potom šmejďárna ext2,3,4? S extom som si zažil svoje, je to hnus velebnosti.

[Martin Mareš]

Pokud mi předvedete jakoukoliv chybu v ext2/3, která by mohla vést ke ztrátě dat, máte u mně pozvání na čaj nebo na pivo podle vlastního výběru

[Mrkva]

Hm, třeba tady? Novější jsem nenašel :)

[Martin Mareš]

Za bug, který existoval naposledy před 8 lety, u mně máte pozvání taktéž před 8 lety

Já myslel něco alespoň trochu současného.

[JVid]

A ReiserFS má nějaký současný (otevřený) bug?

[Martin Mareš]

To netvrdím. Zato pan kolega o pár příspěvků výše tvrdil, že ext2/3 nestojí za nic, tak jsem ho vyzval.

ReiserFS sám nepoužívám, jen k němu mám velmi subjektivní nedůvěru danou tím, že jsem jeho zdroják četl a nevěřím tomu, že by něco napsaného takhle mohlo být správně Naproti tomu ext3 má kód mile přímočarý.

[Bedňa]

Napríklad ja pred mesiacom, dáta s celého disku. Zas som dal šancu extu, teraz vo verzii 4.

[Martin Mareš]

No to mi je líto, že jste přišel o data, ale jak jste poznal, že je to chyba filesystemu?

[Bedňa]

Teraz už bez predošlých emócií. No chcel som pretaktovať procesor na vyššiu frekveciu. Pretože sa procesor bránil, tak úspešnému štartu predchádzalo približne desať reštartov, potom upozornenie na to že systém nieje konzistentný. OK spustím fsck vyhodí niekoľko chýb a opraví ich, ale s pripomienkou že nieje všetko úplne OK, aby som fsck spustil s nejakým parametrom. Pre istotu som najskôr nabootoval všetko OK. Tak si hovorím čo sa môže stať pri nejakej banalitke na disku. Tak som spustil fsck s tým parametrom (neviem už akým) data komplet v prdeli, nepomôhlo už nič, ani rady zaritých exťákov. Neviem možno mám smolu, ale keď mi odišiel radič na disku s Reiserom a potreboval som dokončiť súrnu prácu, tak mi reštartoval komp desať krát denne a až po niekoľkom dni Reiser zahlásil že chce opravu a všetko prebehlo OK. Teraz ho mám v druhom kompe a stále na tom "mrtvom" Reiseri idem. Nehovoriac o ďaľších vlastnostiach, ale o tom som už písal inokedy. S extom som začínal ako každý Linuxák, ale kto si vidí pred nos a rád porovnáva a skúša, tak ho rýchlo zavrhne, nemyslím len na chybu čo som opísal, ale chod systému, nevysvetlitelné spomalenia, problémy so softom, ktoré si nezapisujem a preto to ani nijak dokazovať nechcem, ale každému kto narazí na nevysvetlitelní problém doporučujem skonči s extom a veľa ľuďom to pomôhlo, nielen Reiser.

[Mrkva]

Hm, takže lamerský zásah do HW :) Ten FS mohl odpálit chybující procesor, nebo RAM (pokud jsi taktoval změnou frekvence FSB).

[Bedňa]

Lenže ten lámer používa Reiser celé roky a ešte o nič neprišiel.

[Martin Mareš]

No já si především myslím, že pokud někdo přetaktovaný procesor pustí na živá data, místo aby ho delší dobu testoval na read-only filesystemu nebo nějakém Live CD, tak má neskutečné štěstí, že o ta data přišel jenom jednou.

[Martin Mareš]

No chcel som pretaktovať procesor na vyššiu frekveciu. Pretože sa procesor bránil, tak úspešnému štartu predchádzalo približne desať reštartov, potom upozornenie na to že systém nieje konzistentný.

Když ono se při přetaktování procesoru může stát ledacos – a poměrně běžně se například stává, že procesor uvnitř funguje OK, ale nestíhá komunikovat s okolím, takže třeba může místo všech dat na disk zapisovat nuly (případně zapisovat o kousek vedle). To z počátku vypadá nevinně, ale pak zjistíte, že je přepsaná komplet celá struktura filesystemu. (Už to, že si ext3 stěžoval, že je FS nekonsistentní, místo aby prostě chybu opravil podle žurnálu, naznačuje, že to maličkost nebyla.)

Pokud se vážně stalo něco podobného, pak nemůžete mít žádnému FS za zlé, že to nepřežil.

(Kdysi v dávných dobách jsem opravoval disk, který se někdo pokoušel 5 minut používat ve stavu, kdy řadič zapisoval 7. bit každého 16-bitového slova jako nulu. Takový puzzle se ještě za pár hodin ruční práce s hexeditorem složit dá.)

S extom som začínal ako každý Linuxák, ale kto si vidí pred nos a rád porovnáva a skúša, tak ho rýchlo zavrhne, nemyslím len na chybu čo som opísal, ale chod systému, nevysvetlitelné spomalenia, problémy so softom, ktoré si nezapisujem a preto to ani nijak dokazovať nechcem, ale každému kto narazí na nevysvetlitelní problém doporučujem skonči s extom a veľa ľuďom to pomôhlo, nielen Reiser.

Vida, a já radím přesný opak: pokud se vám systém chová nespolehlivě a záhadně, zahoďte všechny ostatní filesystemy a použijte starý dobrý ext2/3. Vrchol moderního návrhu to rozhodně není, výkon má slušný, ale ne špičkový, ovšem co do spolehlivosti ho v linuxovém světě vážně nepřekoná vůbec nic. A také vím, co je uvnitř

[Bedňa]

Kamaráde je neviem čo je vo vnútri to sú len moje skúsenosti za čo ma zatracujú. Ja si pre mňa nepodstatné veci nezapisujem, hoci som aktívnym hlásiteľom chýb v projektoch ktoré ma zaujímajú. Som zaregistrovaný asi vo všetkých bugzilách čo existujú :) Reiser ide celé roky sám, možno mám len šťastie, ale po tom čase aj keby sa už konečne niečo stalo, asi by som to skôr pričítal HW. Väčšina ľudí si myslí že Linux je nejak závislí na extoch, čo našťastie nieje pravda.

[Heron]

Reiser ide celé roky sám, možno mám len šťastie, ale po tom čase aj keby sa už konečne niečo stalo, asi by som to skôr pričítal HW.

HW problém byl ale i v tom případě přetaktovaného padajícího stroje s ext3.

[Martin Mareš]

Já se hlavně už mnoho let chechtám tomu, že nejvíc řečí o tom, jak je který filesystem skvělý a jiný stojí za bačkoru, mají lidé, kteří žádný nikdy neviděli zblízka.

[poky74]

To jako při pohledu na plotnu? Vyjadřujte se konkrétně.

[Bedňa]

Tak to si ten komp budem asi musieť dať bližšie k sebe.

[Michal Vyskočil]

Martin spíše myslel podívat se na zblízka na git.kernel.org.

[Bedňa]

Myslíš kritiku štýlu kódu? Ale to je vec ostatných kvázi programátorov takých ako som ja, že myslíme len jednoducho. To nič nemení na tom že reči odporcov sú len čisté drísty, hoci ma mrzí že to vyslovili aj ľudia od jadra. Ale predsa sa nemôžeme stotožňovať s vrahom že? Radšej budeme plácať ext2,3,4,5,9999 a stále vytvárať nové bugy, ale náš systém bude ideologicky čistý, s prehľadným kódom, hoci bude stáť za ...

[Martin Mareš]

To nič nemení na tom že reči odporcov sú len čisté drísty

A Vaše řeči nejsou? Nevšiml jsem si, že byste vyslovil jediný solidní argument proti ext3.

[Martin Mareš]

Ale to je vec ostatných kvázi programátorov takých ako som ja, že myslíme len jednoducho.

Na to samozřejmě máte plné právo. Jen se pak nesmíte divit, že to, co tvrdíte, sotvakdo bere vážně

[Bedňa]

To je pravda, ja to tiež beriem skôr ako povzdych nad tým, ako jadráci odstavili pre mňa najlepší natívny Linuxový FS.

[Jardík]

Jak moc myslíte, že by bylo reálné dostat do kernelu do ovladače cdrom nové ioctl CDROM_GET_EXCLUSIVE_ACCESS (nebo tak něco) s následujícím chováním:

• CDROM je otevřen více než jednou, volání by selhalo
• CDROM je otevřen pouze jednou, dostanu exkluzivní přístup. Každá další aplikace volající open() na dané zařízení by dostala chybu (např. EBUSY), nehledě na mód přístupu.
• Po zavření deskriptoru by byl příznak odstraněn (tj. kdyby root chtěl přístup, stačí zabít proces přistupující k zařízení a přístup dostane).

[Mrkva]

Napiš patch, pošli na mailing list a uvidíš, ne?

To to nejde nějak rozumě udělat v userspace, že to chceš prasit do kernelu?

[Jardík]

A jak to uděláš v userspace? Pokud otevřu s O_EXCL cdromku přes /dev/sgX, tak mi jí to dá exkluzivně a nic ji neotevře ani pouze pro read. To platí ale jenom o /dev/sgX. Pokud to samé udělám pro /dev/sr0, tak ji jen neotevře program, co to opět zavolá s O_EXCL, ale program, co zavolá open bez O_EXCL ji stejně otevře a může posílat SCSI příkazy, co podělaj proces vypalování. Navíc O_EXCL pro srX a sgX se vzájemně nevylučují a lze tak opět podělávat vypalování. A jelikož lze SG_IO posílat jak přes srX tak sgX, tak je to určitě nějak vzájemně "propojené" a mohlo by to fungovat pro obě rozhraní najednou. Nebo to třeba nazvat jinak (třeba s SG_ prefixem). Zkusím kouknout do zdrojáků jádra.

[Jardík]

Tak trošku pomáhá fcntl/F_SETLK, ale to zase pomůže jen proti otevření bez O_NONBLOCK. Pokud je tam O_NONBLOCK, tak se to stejně otevře. Takže je situace:

• Otevřu /dev/sgX s O_EXCL a O_NONBLOCK
  • Žádná jiná aplikace už /dev/sgX neotevře
  • Aplikace však může otevřít /dev/srX a podělat tak vypalování
• Otevřu /dev/srX s O_EXCL a O_NONBLOCK, použiju fcntl/F_SETLK(RW) na zamknutí
  • Žádná aplikace to neotevře s O_EXCL flagem
  • Žádná aplikace to neotevře bez O_NONBLOCK flagu (např. mount nebude fungovat)
  • Aplikace, která nepoužije O_EXCL a použije O_NONBLOCK to klidně může otevřít (a v případě DVD-RAM třeba i RW a pak pálí samo linuxové jádro) - to má za následek podělání vypalování
  • Každá aplikace přistupující přes /dev/sgX může podělat vypalování
• Otevřu jak /dev/srX tak /dev/sgX způsoby popsanými výše.
  • Každá aplikace přistupující přes /dev/sgX má smůlu, každá aplikace otevírající /dev/srX s O_EXCL má smůlu, každá aplikace otevírající bez O_NONBLOCK má smůlu.
  • Aplikace, která přistupuje přes /dev/srX, nepoužije O_EXCL a použije O_NONBLOCK může podělávat vypalování
• Se staršími jádry lze přistupovat přes /dev/hdX - další trable nastávají.

Koukal jsem na ty zdrojáky, koukal jsem na ovladač cdrom, na scsi (sr, sg) "věcičky", na ide věcičky, vypadá to, že každé si dělá "na svém písečku", je tam spousta duplikátních věcí ... fakt netuším, kam bych měl nové ioctl dát, aby to mělo efekt na všechna rozhraní pro cdromy