Názory k článku Komiks: Miluji Linux!

Z obhajoby mě vyhodili, protože mám poruchu osobnosti. Nelíbí se jim můj způsob psaní.

zenam se nelibi tvuj styl psani? co si pred tou zenskou prosimte neobhajil? poruchu osobnosti? neverila ti ji???

Poruchu osobnosti mám diagnostikovanou a je jedno, zda mi ji někdo věří nebo nevěří. Měl jsem na mysli obhajobu disertační práce. Tam ženy nejsou, tam jsou většinou muži.

kdyz tam nejsou zeny a vetsinou sou tam muzi, tak kdo je ten zbytek? hermafrodite?

Někdy tam žena může být, ale není to moc obvyklé.

A ja ze sa premenujes na Dr.BLEK. XD ale tak potom nic :(

Zatím jsem MaGoR BLEK. Mám totiž psychickou poruchu.

a nemas to nekde na netu? tvoje diplomka me prisla docela dobra...

Dal jsem to na http://artax.karlin.mff.cuni.cz/~mikulas/spadfs/THESIS.PDF

Důvody odmítnutí:

Je to popis vývoje filesystému a nevypadá to jako vědecký text. Nejsou tam tvrzení a nejsou experimentálně doložená. Smyslem PhD nemá být nic naprogramovat, ale dělat výzkum.

Málo citací. Zejména málo akademických citací.

Špatná angličtina, chybí tam členy.

diky, docela zajimave, ale je fakt, ze je to docela popisne... na druhou stranu... na obycejnou diplomku je to tema moc drsne...

Za celou dobu, co se zabývám operačními systémy, jsem žádné obecně platné tvrzení o rychlosti programů neviděl, ani jsem žádné neudělal.

Bohužel vědci taková tvrzení vyžadují, vědecké práce se hemží úvahami typu "algoritmus X zvyšuje rychlost o 15%" --- takové tvrzení je nepravdivé, protože když algoritmus X naprogramujou různí lidi do různých systémů, bude změna rychlosti značně různá. Takže tam nějaká taková měření a závěry dodělám a pak to podám znovu, ani nevím, zda mám takhle "vylepšenou" disertaci publikovat na internetu, když tomu vlastně ani sám nevěřím.

Hmm, tak koukam, ze jsem udelal dobre, kdyz jsem sel radsi na teoretickou informatiku a ne na softwarove systemy.

Z hlediska intelektuální konzistence je určitě teoretická informatika mnohem lepší. Zase tady mám šanci, že to někdo bude aspoň třeba používat, pokud mě přijmou u Zeleného Chameleóna a nechají to tam vyvíjet.

Zelený Chameleón mě zajímá. Máte někdo představu kolik tam platí?

No, já myslím, že pokud se ptáš "kolik platí", tak z tebe programátor free software nebude :-))

Kolik platí nevím, a přežiju od 10000, neboť nemám ženu a nikam nejezdím. Takže mě to zas tolik nepálí.

omg wtf :)
!!!!!!!!!!

nejaky drsny "teorem" s dukazem, ktery by jim vytrel zrak, tam opravdu chybi ;-] ale to je problem vsech realnych aplikaci, protoze se musi spolehat na heuristiky a empiricke mereni :-/

osobne bych to asi tlacil na to ukazat v cem je pocitani padu lepsi oproti jinym technikam...

Určite by z toho bol krásny seriál na root.cz :-)

... kdyby to někdo přeložil do češtiny. Chce se někomu?

a neuvazovals o tom, dat to nejake slecne na korektury (odstranit z tama nejake ty lingvisticke mouchy) a publikovat to v anglictine? ja si myslim, ze by to lidi zkousli... teda ja urcite...

btw. ja jsem za korektury diplomky slibil jedne slecne luxusni veceri... prilezitost spojit tak nutne s prijemnym... a navazat kontakt s lidmi i mimo IT ;-]

Tak to mas stesti:) Me akorat slecny posilaji do prdele.

jezis, to sou pyce!!!!!!!


ale jako ja to vim uz davno, ze akademicka puda je lehce (EXTREME ULTRA!!) prohnila a tupa :) super info !!! moc se mi to libi

to sou fakt kokoti debilove !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! malo akademickych citaci. boha jeho.... ja bych je tak nakopal do riti....

ale ty experimentalne dolozene tvrzeni by nebyly spatne..... (hadam nejake ty statistiky a srovnani)

No, právě, že ty experimenty nejdou udělat.

Představ si, že doktor má dva pacienty s nějakou nemocí, jednomu dá lék, druhému ne, po nějaké době porovná jejich stav, a udělá závěr na účinnost léku. Takový experiment by nikdo nebral vážně, protože stav pacienta závisí i na mnoha dalších okolnostech než jen na tom, zda dostane lék --- těch pacientů musí být aspoň stovka, aby to mělo nějakou statistickou vypovídací hodnotu.

Nojo, jenomže 100 filesystémů a 50 vývojářů, co by do poloviny filesystémů doimplementovali featuru, nemáš. Takže na otázku, jak moc nějaká featura pomáhá, nejde přesně odpovědět. Odpověď jde pouze intuitivně odhadnout, jenomže intuitivní odhad vědci šíleně nenávidí. Cíl je tedy "napsat to tak, aby to recenzentovi vypadalo jako že je to jisté".

-

Další problém je ten, že experimentem získáš nějaké číslo --- a není známo, jak to číslo souvisí s prožitkem uživatele. Když udělám rozhodnutí, co operaci X zpomalí a operaci Y zrychlí, bude uživatel rád nebo ne?

Já jsem třeba SpadFS optimalizoval na případy, kdy se často hrabe na související soubory, které jsou blízko sebe v adresářové struktuře --- naproti tomu při náhodném přístupu na spoustu souborů bude nejspíš pomalejší než Ext3. Optimalizoval jsem to tak proto, že ze zkušenosti vím, že programy jako "cp", "tar", "find" apod. se takhle chovají (a ještě nějaké optimalizace na to hodlám udělat). A když ti teď vědec předloží umělý benchmark, který přistupuje na soubory náhodně a začne ti tvrdit, že to je ta performance, protože to bylo publikováno na konferenci, co mu na to říct? Které z těch čísel je důležitější?

Aby se tohle rozumně experimentálně vyřešilo, musel bys udělat double-blind test, mít velkou skupinu uživatelů, která neví, jak je filesystém nastaven a pak bude vyplňovat dotazník o tom, jak jim to připadá rychlý a co jim připadá rychlé a co ne. Takový experiment budeš dělat třeba dva měsíce, zjistíš optimální nastavení jedné konstanty v tvém kódu --- nojo, jenomže těch konstant tam máš ještě dalších dvacet.

-

Místo toho existuje mnohem jednodušší metoda vývoje --- neexperimentovat, prostě svůj program používat, a pokud tobě samotnému připadá v nějaké akci pomalý, tak to zrychlit. --- pak nemusíš dělat nějakou statistiku na to, která část je zodpovědná za kolik procent uživatelova prožitku apod. --- jenže tuhle metodu vývoje vědci nesnáší.

Závěr je takový, že špatně provedený experiment (pustíš benchmark, vemeš číslo a to vydáváš za performanci) je horší než vývoj podle intuice. A dobře provedený experiment udělat nejde z důvodů lidské/časové náročnosti.

a vliv poruchy osobnosti je jaky?

Prý tam nějaká korelace je, ale rozhodně ne implikace. T.j. porucha osobnosti neimplikuje programování a programování neimplikuje poruchu. Ale pokud má člověk schizoidní poruchu, tak je velká šance, že bude trávit čas nějakou samotářskou činností, např. programováním. Jak velká je ta korelace, nevím.

nevim..

udelal bych treba nekolik typickych scenaru.. a ty bych aplikoval na kazdy popisovany fs, aby bylo zrejme na co je kterej fs dobrej.. rozumis..

kdyz nechcou tvuj SpadFS, tak aspon budou mit ty statistiky... sak na ne ser.. dej jim co chcou, ne.... nahustit a poslat do riti .)))))))))))

No, jasně, že udělám testy, co oni chtějí, jenom nevěřím, že to někomu k něčemu bude. Spíš by mě zajímaly reálné zkušenosti lidí s nějakými programy, co na tom pustí.

Oponent asi řekne "ano, jsou tam čísla, ta čísla jsou získaná vědeckou metodologií", pak tu práci uloží do skříně a nikdy ta čísla k ničemu nepoužije.

Bodejť, udělej benchmark a napiš tam "Test ukázal, že SpadFS není rychlejší než ext3." a budou mít, co chtějí. Negativní výsledek je taky výsledek. A jestli to má nebo nemá nějaký přínos pro praktický život, to vůbec neřeš. Dizertace není nikdy o životě :-)

ahoj. fajn, zalozia to do skrine. ty budes mat svoju obhajobu, oni svoje ciselka a formalne tance. ale nic ti nebude branit uplatnit naucene v praxi, nech si akademici hovoria a myslia co chcu.

"We" --- školitel mi říkal, že nemám psát "I", ale "We", oponent zase, že nemám psát "We", ale "I" --- čili rozporuplné požadavky :-)

Anode kopíruje ty embeddované extenty proto, aby když je adresář poškozen, tak se soubor dal z anody obnovit. Ze stejného důvodu je v anode i prvních 16 znaků jména.

Inody --- unix naštěstí neumožňuje otevírat soubory podle čísla inod, takže otázku, co dělat, když mi někdo dá číslo inody, nemusím řešit. Potřebuje to jen NFS (to zatím SpadFS neumí), asi to hodlám udělat jednoduchým indexem číslo inody->cesta (a v případě použití na NFS serveru se tento index bude sám vyrábět).

Nějaké unixové programy (např. tar) nemají rády, když se číslo inody mění (to jsem zjistil až poté, co jsem to naprogramoval), takže asi do extended attributů přidám 64-bitové číslo inody a každý nový soubor dostane nové číslo. Vzhledem k tomu, že je 64-bitové, tak se nebude muset řešit přetečení ani alokace volných čísel.

Co se týče "We"/"I", tak moje osobní preference je
psát technické informace pokud možno (ú)trpně
a činný tvar ponechat v abstraktu, úvodu a závěru,
aby to nevypadalo tak, že se dílo vytvořilo úplně samo
bez autorova přispění. Celkově ale na mě moc nedejte,
protože disertační práci nemám jseště ani dopsanou,
natož obhájenou a hned tak to ani nebude.

To otvírání inode jsem uvažoval právě na úrovni VFS
kvůli NFS a požadavku na stabilitu přes rebooty.
Ono když mají chodit na NFS linky, tak asi nic moc
jiného nezbývá. Ale z hlediska psaní FS je to dost
otrava.

Ještě mě napadl jeden problém, ketrý mi není jasné,
jak je na Vašem FS řešen. Myslím, že lze souhlasit s názorem,
že ochranu před chybou media není až tak nutné řešit na úrovni
FS. Stejně je to většinou ochrana jen metadat a i tak,
aby to opravdu chodilo by bylo nutné provést další čtení
každého zapsaného bloku až na fyzickou úroveň
a zkontrolovat alespoň konzistenci checksumů.
Je tedy možné předpokládat, že selhání média musí být
ošetřeno mimo FS. V dnešní době to RAID celkem rozumně
řeší. Jenže zde vzniká problém, že zápis je distribuován
na více disků naráz a 100% atomicitu při nedokončených
operacích nelze jednoduše zaručit. Může se stát, že
data dorazí jen na některý/é disk/y. SPAFS požaduje
atomicitu zápisu bloku, která pak nemusí být úplně
zaručena. Zvažoval jste nějak tyto situace.
Má smysl, aby crash-count a příslušející tabulka
byla na disku ve dvou kopiích? Adresářům to stejně
asi nepomůže, přepisují se in-place. Jak moc lze
předpokládat, že situaci napraví řadič RAIDu při příštím
startu? Co se bude dít při dvojité chybě (pád systému
a chyba na úrovni media pro právě zapisovaná data bez
dokončeného zápisu kopie/parity).

PS: nestálo by za to k diskuzi o SPADFS založit nějaké
fórum/list nebo budete pokračovat v loňské diskuzi na LKML?

S tím NFS --- dá se to udělat tak, že udělám adresář /.nfs a v něm pro každé číslo inody udělám soubor, který bude obsahovat cestu k souboru s danou inodou. Pokud bude na soubor víc hardlinků, tak dám jeden hardlink rovnou do /.nfs (pojmenovaný podle čísla inody). Soubory budou obsahovat flag, zda jeho číslo inody je v .nfs, aby se zbytečně nezpomalovaly operace se soubory, na které se přes NFS nikdy nepřistoupilo.

Ad ten RAID --- pokud RAID 5 není degradován, tak špatné zapsání (nebo nezapsání) paritního bloku nevadí, protože se po novém startu stejně synchronizuje. Čili se to z hlediska pádů chová stejně jako normální disk.

Degradovaný RAID 5 nepřežije pád počítače v žádném případě, bez ohledu na filesystém. Tam totiž dochází k situaci, kdy pád v momentě zápisu bloku může modifikovat jiný blok, na který filesystém vůbec nesahal --- takové poškození nepřežije žádný filesystém. Hardwarové RAIDy mají baterii, která by měla data zachránit v případě výpadku proudu, softwarový RAID 5 je prostě poškodí.

Zajímalo by mě --- existuje nějaká možnost, jak implementovat softwarově RAID 5, aby k tomuto poškození nedocházelo? O ničem takovém nevím, ale je to celkem zajímavý problém. Jak je to s RAID 6? - dají se v případě pádu během zápisu data nějak dostat ze dvou paritních disků?