Vlákno názorů k článku
Komiks: Miluji Linux!
od Radek Hulán - Dokazuje to moje nejnovější analýza.
http://radekhulan.cz/item/srovnani-gnome-2-20-versus-windows-vista
jj zase samy FUD ako vzdy... a este k tomu kopirovaniu nebit FSF alebo OSS tak dodnes na oknach nebude funkcny IP stack a dalsich veci je lepsie kopirovat(to robi Linux) ako vykradat(to robi MS)!!! Nereagoval som na diskusiu pod clanok, lebo sa mi nechce registrovat...
Cool :-)
Ale nevím člověče, jestli to od tebe bylo rozumné. Nevím, jestli i ostatní tamní články jsou parodie, ale na každý pád hrozí, že by to nějaká lama mohla nepochopit a vzít tě vážně.
No napada me taky jeden remix na tento komiks, ten klucina co leti pres plot by mohl volat "Ale ja jsem Hulan!!!" a vyhazovaci by mu mohli odpovedet neco jako "no prave! My ten tvuj web videli!"
Tak tenhle vtípek dokazuje, že na tom nejste s vnímáním
světa lidí tak špatně.
Co se obhajoby práce týče, tak by mě extrémě potěšilo,
kdybych něco jako SPADFS viděl dělat naše studenty.
Takže z odmítnutí si nic nedělejte a nebo ještě lépe
vemte ho jako pobídku k nabuzení a dokažte, že máte
pravdu. Vždyť Nasranost je kromě Nadpřirozena, Přemlouvání,
Nejistoty jednou ze základních sil, které drží vesmír
(alespoň podle druidů) pohromadě.
Kód SPADFS se mi tedy čte dost špatně (nějak je tam moc
velkých písmen), ale myšlenka je pěkná a věřím tomu,
že to může být opravdu zajímavé řešení a benchmarky
vypadají slibně. Jsem zvědavý, jaká je architektura
ostatních subsystémů SPADu.
Kdyby u Vás nějaký student něco takového naprogramoval, dojdete ke standartnímu problému --- fakulta nebo stát Vás bude nutit to publikovat na konferencích, které se vývojem softwaru nezabývají (recenzenti si tam ten software ani nestáhnou), tam bude dotyčný student soupeřit s lidmi, kteří nic neprogramují a tráví celý čas editováním článků --- taková soutěž se nedá vyhrát. A nakonec z toho Vaše oddělení nebude nic mít, bez ohledu na to, kolik lidí ten software bude používat.
Díky za odkaz. Myslím, že text předkládá hodně
informací a jsem přesvědčen, že mnoho rozhodnutí
o způsobu řešení určitého praktického podproblému
je mnohem těžší a vyžaduje mnohem víc znalostí
a představivosti než mnoho vědeckých pseudočlánků.
Co se textu týče, tak je tam na můj vkus moc "We".
U logových sytémů se mi zdá, že není jejich myšlenka
v začátku odstavce ideálně popsaná. Pokud jsem to nepřehlédl,
tak myslím, že u root anode chybí vysvětlení, proč
zahrnuje i ty původní embeddované extenty.
Dále se nikde v textu nevyskytuje popis toho, jakým
způsobem umožňuje SPADFS jednoznačné mapování inode čísel.
Pokud file přejde v důsledku hard-linku na samostatný
blok a potom je původní jméno smazané, tak to vidím
jako dost složitý problém. Obecně vyhledání souboru
podle inode je nechutná věc, kerá komplikuje unixovým FS
život. Když je inode indexem na fyzickou polohy disku,
je potřeba nějak zkontrolovat, že jsou to skutečně platná
metadata. Když je to číslo přiřazení jinou metodou a
vyhledatelné třeba přes stromy, tak je nutné zajistit unique
alokaci. Taky docela komplikovaný problém.
"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ů?
Proc ta p*ca Hulan nadava na Linux ale sam pouziva na svych "webech" PHP a MySQL? Proc ne placeny ASP a MSSQL? Zeby na to nemel penize z te jeho reklamy?
Nadávat na linux a používat PHP a MySQL, v tom nevidím žádný rozpor. PHP+MySQL se přeci automatický nerovná LAMP. (Ale jenom ??MP :) ) A i kdyby, používám ASP.NET + MS SQL a taky nadávám na Widnows (ale na linux taky). A víš kolik lidí nadává na Česko a stejně tu žijou? :)
Obrázek si udělejte sami... obzvláště když si člověk vědomí kolik přemáhání ho musí stát aby si nezměnil hosting na MS .... to musí bejt linux reálně o hodně lepší než MS ;)
Pán Hulán, neviem akú máte zmluvu, alebo iný kontakt s výrobcami, hardwéru, lebo HW nároky Visty neskryjete, skúste nainštalovať, a udržiavať v akom takom chode počítač s procesorom 800 Mhz a 128 MB RAM. Windovs XP má problémy, obstojne ide iba Windows 2000, ale ten je pomerne starý. Najlepšia alternatíva je Xubuntu, drží sa najnvších trendov, je aktualizovaný. Tento komentár, píšem tu, lebo viem, že na svojej "supermegaextragiga čítanej stránke" upravujete komentáre. Takýto človek nemá na root,cz čo robiť.
P.S máte s falšovaním svoje skúsenosti, a preto sa skúste uchádzať o post riaditeľa Miscrosoftu po Gatesovom odchode