Jaderné noviny - 26. 7. 2006

7. 8. 2006 | Robert Krátký | Jaderné noviny | 3693×

Aktuální verze jádra: 2.6.17.7. Citát týdne: Hans Reiser. Nový pohled na síťové kanály. revoke() a frevoke(). Souborové systémy, politika a jádro. Linus o Extensible Firmware Interface.

Aktuální verze jádra: 2.6.17.7

Aktuální verze jádra řady 2.6 je 2.6.17.7, vydaná 24. července. Doplňuje poměrně dlouhou řadu oprav pro problémy se síťováním, zvukem a několika dalšími oblastmi.

Aktuální předverze je i nadále 2.6.18-rc2. V hlavním git repozitáři se hromadí opravy a brzy lze očekávat vydání -rc3.

Od 2.6.18-rc1-mm2 ze 14. července nevyšla žádná nová verze stromu -mm.

Citát týdne: Hans Reiser

link

Problémem Linuxu je, že jeho úspěch k němu přivádí lidi schopnější než ty, se kterými se začínalo, a nedaří se mu s tím vypořádat. Je v tom přímo mizerný, protože se chová nejhorším možným způsobem. Ztratili jsme docela dost vývojářů souborových systémů, protože se prostě nechtěli dohadovat s lidmi, kteří toho ví méně než oni, ale na nové návrhy se tváří otráveně a chovají se nezdvořile, protože chtějí být bossové.

-- Hans Reiser

Nový pohled na síťové kanály

Když Van Jacobson nadhodil v lednu minulého roku na linux.conf.au svou představu o síťových kanálech, způsobil v linuxové síťové komunitě pořádný rozruch. Pomocí výrazných změn způsobu zpracovávání příchozích paketů a natlačením většiny práce co nejblíže k cílové aplikaci dosáhl Van velkého zlepšení výkonu - odstranil až 80 % režie na víceprocesorových systémech. S takovými čísly to vypadalo, že o začlenění kanálů do Linuxu je už dopředu rozhodnuto.

Od té doby se však začala o slovo hlásit realita - to ona dělává, dříve či později. Proto také David Miller posledně říkal o síťových kanálech tohle:

Na síťové kanály od VJ nebuďte příliš natěšení, protože se objevuje stále více a více překážek bránících jejich nasazení v praxi... Všechen výkon původně ušetřený na úkor routování, netfilteru a vyhledávání TCP soketu se nám ztrácí, když se snažíme přimět síťové kanály k fungování na skutečných systémech.

Daný problém se týká integrace síťových kanálů a netfilteru. Doufalo se, že by pakety mohly být identifikovány a roztříděny do příslušných kanálů ještě před zpracováváním netfilterem (firewallem). Pak by to zpracovávání mohlo být provedeno blízko aplikaci, na tom samém procesoru. Ukázalo se však, že netfilter může změnit skutečný cíl paketu. Takže je nutné pakety filtrovat před vstupem do kanálu a většina výkonu získaného díky použití kanálu je ztracena.

Alexej Kuzněcov poslal podrobnou kritiku kanálů, ve které tvrdí, že většina výhod je iluzorních:

Je to úžasná hračka. Ale nevidím nic, co by ji mohlo pozvednout na praktickou úroveň. Exokernely tohle dělaly léta a veškerý získaný výkon je vyrovnán příliš komplikovaným klasifikačním enginem, který musí zůstat v jádře a dělat v podstatě totéž, co dělá routování/firewall/...

Kromě toho se zdá, že mnoha výhod, které nabízejí kanály, lze dosáhnout pečlivým využitím možností moderního hardwaru. Konkrétně jde o to, že stále větší počet zařízení dokáže provádět jednoduchou klasifikaci paketů a směrovat je na procesor (přes cílená přerušení), kde běží cílová aplikace. Tato technika eliminuje přehmaty keše způsobované zpracováváním přerušení na jednom procesoru a protokolu na druhém.

Vypadá to, že další zdánlivě chytrý nápad se nedostane do reálného nasazení. Některé z jeho základních konceptů, jako například datové struktury spolupracující s kešemi však pravděpodobně ovlivní budoucí směr síťového stacku. Takže ačkoliv asi nebude revoluční nový mechanismus, některá slibovaná zlepšení výkonu by přeci jen měla být realizována. A jak říká David: Aspoň není potřeba psát tolik kódu.

revoke() a frevoke()

V některých variantách Unixu je systémové volání revoke():

    int revoke(const char *path);

Toto volání slouží k odpojení procesů od souborů; když je zavoláno s určitou path, uzavře všechny otevřené popisovače souborů, které odkazují na soubor nacházející se na konci této cesty [path]. Původním účelem bylo zbavit se lidí, kteří napsali program sedící na sériovém portu a předstírající, že je login. Jakmile bylo revoke() zavoláno se souborem zařízení odpovídajícím sériovému portu, všechny falešné loginy byly odpojeny a nemohly nikoho oklamat. Existují i jiná možná využití. Například odpojení procesu od souboru, který brání odpojení souborového systému.

Linux toto systémové volání nikdy neměl, ale možná nebude trvat dlouho a dojde ke změně; Pekka Enberg poslal implementaci revoke() ke kontrole. Pekka také přidal druhou verzi:

    int frevoke(int fd);

Tato verze bere samozřejmě jako parametr otevřený popisovač souboru. V obou případech musí volající proces buď soubor vlastnit, nebo být schopen přebít práva. Takže revoke() umožňuje procesu vyškubnout otevřený soubor procesům, které vlastní jiní uživatelé - za předpokladu, že proces daný soubor vlastní.

Zvládnout tuto operaci správně není tak docela snadné, což má za následek určité kompromisy v současné implementaci, které se možná nebudou některým vývojářům líbit. Zjednodušeně ten proces vypadá takto:

• Kód prochází ve smyčce přes každý proces v systému; u každého procesu projde tabulkou otevřených souborů a hledá popisovače souborů odpovídající zavíranému souboru. Pokaždé, když nějaký najde, vynuluje záznam popisovače (čímž se popisovač stane pro původního majitele nedostupným). Soubor však není uzavřen; místo toho je vytvořen seznam souborů pro pozdější akci.

  To vše je poměrně pomalé, ale problém to není: revoke() není operace, která by ovlivňovala výkon. Trochu problematičtější je alokace paměti (pro přidání záznamu do seznamu souborů k uzavření); selže-li, ukončí se revoke() na půli cesty, přičemž provedlo neznámé množství škod, aniž by splnilo svůj účel.

• Po uzavření všech otevřených popisovačů souborů mohou být uzavřeny samotné soubory. revoke() projde vytvořeným seznamem a všechny otevřené soubory uzavře.

• Zůstává jeden malý nepříjemný problém: některé procesy možná využily mmap() k namapování souboru do svých adresných prostorů. Volání revoke() musí s těmito oblastmi paměti něco udělat, nebo jeho práce nebude dokončena. Takže je nutné projít všechny oblasti virtuální paměti spojené se souborem; u každé je metoda nopage() nastavena na speciální verzi, která vrátí chybový stav.

  Tato změna zabrání procesu v chybném běhu na nových stránkách z uzavřeného souboru, ale neudělá nic se stránkami, které už jsou součástí adresného prostoru procesu. Pro nápravu je potřeba prolézt tabulky stránek každého procesu, který soubor namapoval, a vyčistit všechny záznamy, které odkazují na stránky z daného souboru.

Alternativní přístup používá patch pro nucené odpojení od Tigrana Aivaziana, který byl během své dost dlouhé historie (komentáře k němu obsahují jméno autora portu na jádro 2.6) upravován i mnoha jinými vývojáři. Patch má jiný cíl - být schopen odpojit souborový systém bez ohledu na aktuální činnosti. Musí však vyřešit stejný problém - uzavření přístupu ke všem souborům na cílovém souborovém systému. Místo vyčištění popisovačů souborů nahrazuje tento patch výchozí strukturu file novou, která pochází ze souborového systému "badfs". Po této změně budou na pokusy o práci se souborem vraceny EIO. Mapování paměti je odstraněno přímým voláním munmap().

Konečná podoba patche by klidně mohla být kombinací obou a poskytovala by jak nucené odpojení, tak revoke(). Do té doby bude nutné vyřešit několik zbývajících otázek (například jak provést bezpečné uzamčení bez zpomalení vysoce optimalizovaných read() a write()). O tyto funkce je však zjevně zájem, takže je pravděpodobné, že práce dospěje až k začlenění do jádra.

---

Následující obsah je © KernelTrap

Souborové systémy, politika a jádro

24. črc, originál

Na LKML pokračuje diskuze o tom, proč nebyl Reiser4 dosud začleněn do jádra. Hans Reiser postavil do kontrastu snahy o začlenění Reiser4 a nedávnou diskuzi o novém souborovém systému ext4. Ten kód není ještě ani napsán nebo testován, ale do jádra jde rovnou, aby se jeho vývojáři nemuseli starat o udržování patchů mimo hlavní strom. No ne. Tak trochu těžko vyvracet, že nejde o politikaření, co?

Theodore T'so odpověděl: Jde o vývojovou proceduru, které bylo dosaženo po diskuzi a hledání kompromisu na LKML a mezi vývojáři ext2/3/4. Není to původní plán, který navrhovali vývojáři ext2, ale když jsme naslouchali obavám a návrhům, nepochybovali jsme o motivech těch lidí, kteří s návrhy přicházeli; naslouchali jsme. Pokračoval poznámkou o tom, že části kódu, ze kterého bude ext4, byly napsány už před rokem, a byly důkladně testovány a kontrolovány. Další připomněli, že evoluce z ext3 na ext4 bude velmi veřejný proces, přičemž patche budou začleňovány postupně, kdežto Reiser4 je založen na úplně jiném kódu než Reiser3.

Linus o Extensible Firmware Interface

26. črc, originál

Nedávný patch poslaný do LKML obsahoval následující popis: Tento patch přidává mapování paměti efi na e820. Andrew Morton reagoval: Proč? Linus Torvalds nabídl svůj pohled na EFI (Extensible Firmware Interface - rozšiřitelné firmwarové rozhraní), který uvedl slovy: Další dementní věc od Intelu (první bylo ACPI). EFI je náhradou BIOSu, která byla původně navržena pro použití na architektuře ia64, ale od té doby ji přijaly i jiné počítače, včetně intelských Maců. Linus pokračoval ve vysvětlování: Původní EFI kód v jádře v podstatě duplikuje všechna rozhraní BIOSu (tj. vše, co se dotýká mapování paměti, máme ve dvou variantách: normální, otestovaná verze pro e820 BIOS a většinou nefunkční, splácaná verze EFI). Překládat paměťovou mapu EFI do e820 je tedy velmi rozumné.

Linus pokračoval v dalším emailu: Abych se vyjádřil jasně - problém s EFI je ten, že na povrchu vypadá o hodně lépe než BIOS, ale v praxi se z toho stává jedna z těch věcí, které mají jen pár skutečných výhod a často jen přidávají spoustu komplikovanosti, protože ta 'nová a vylepšená' rozhraní byla z většiny vymyšlena komisí. A pokračoval: Takže EFI má bezvadný shell, systém pro natahování ovladačů a další pěkné funkce. Kde "pěkné" samozřejmě znamená "daleko komplikovanější než v sedmdesátých letech, když byli lidi ještě blbí a jen chtěli, aby věci fungovaly". Je samozřejmě otázkou, jestli lidi za posledních 30 let zmoudřeli nebo zblbli. Není to dost času na to, abychom měli díky evoluci větší mozky, ale určitě to stačilo na to, aby většina lidí přestala rozumět tomu, jak vlastně hardware funguje. A co se BIOSu týče: Nikdy bych netvrdil, že BIOS je úžasný, ale každý aspoň ví, že je to jen zavaděč systému, a nikdo se z něj nesnaží udělat něco jiného.

       

Komentáře

[Michal Kubeček]

Ten citát je drsný. Nevím proč, ale připomíná mi to jeden citát Járy Cimrmana…

[Dan Keder]

Jára Cimrman podľa všetkého vymyslel aj súborové systémy.

[Marek Bernát]

To je neprevdepodobné. Po vymyslení prvého parného robota s umelou inteligenciou už nič také nebolo potrebné

[ava]

Krasny cteni na dobrou noc, lepsi nez pohadka, diky. Potesil me "přehmat keše", v tomhle spojeni ma kes takovou lidstejsi tvar nez pri "vypadku"

[Michal Ludvig]

Neni mi jasne proc si davat tolik prace s revoke()? Kdyz procesu pod rukama zavru soubor nebo jeste hur kdyz mu odmapuju cast pameti, tak to dost mozna vubec nerozdejcha. A kdyz rozdejcha tak nebude delat to co mel, protoze kdyby ten soubor nebyl nepotreboval tak by ho nejspis vubec neoteviral. A kdyz mam pravo zavirat cizi soubory tak mam nejspis i pravo vrazdit jejich majitele.

Mozna mi neco unika, ale cele mi to pripada jako velmi komplikovany zpusob jak aplikace dostat do nedefinovaneho nestabilniho stavu. Pro odpojovani mountpointu jsem si zatim vzdycky vystacil s fuser a kill...

[Pavel Dobeš]

Kdyz jdes spravovat databazi a vyzaduje to vyhradni pristup, tak se taky nasilne odpoji ostatni spojeni k databazi. A ta spojeni to nerozdejchaji (a nektere aplikace take ne).

No a revoke() je presne ten pripad, kdy pri nejake akci vyzadujes vyhradni pristup k nejakemu souboru/zarizeni.

A stejne jako s tou DB musis sakra dobre vedet PROC to revoke() volas. IMHO to nebude tak vyuzivana funkce.

A s tim vrazdenim? Obavam se, ze tak humalni pristup pri trestu smrti by asi nikdo nezvolil. Tady se zalogujte, zavolejte fopen() a my vas zabijeme pomoci revoke()... zadne strikacky do zily, zadne elektricka kresla. Stacil by pocitac s linuxem.

PaD

[Marek Bernát]

A kdyz rozdejcha tak nebude delat to co mel, protoze kdyby ten soubor nebyl nepotreboval tak by ho nejspis vubec neoteviral.

To, čo píšete, sa týka len jednoduchých aplikácií, ktoré manipulujú s jedným súborom. Pri takých je to naozaj to isté, ako ich zabitie. Ale pri komplexnejších aplikáciách, ktoré pracujú s viacerými súbormi, ako napríklad textový editor, kde máte niekoľko okien, je jeho zabitie a odobratie descriptoru už niečo úplne iné. Samozrejme, že aplikácia sa s tým bude musieť vedieť vysporiadať, ale to nie je taký strašný problém. A existuje určite ešte veľa prípadov, ktoré nás zrejme ani nenapadnú. Navyše, používať to nemusíte, ak nechcete a nijako vás vývoj tohto riešenia nepoškodzuje.

[R]

Presne tak - ked si predstavim, ze mam v textovom editore otvorenych 10 suborov, z toho jeden z CDcka (ten som tam zabudol otvoreny, lebo na CD by som ho asi needitoval :) ). Chcem vybrat CD, tak:

a) zavrie sa mi ten jeden subor otvoreny z CD, editor mi ohlasi I/O error, subor odtial zmizne a hotovo

b) zabije mi to cely editor - sice ziadnu chybu neuvidim ale stratim neulozenu pracu v ostatnych 9 suboroch...

[Michal Ludvig]

A co treba ten soubor explicitne uzavrit drive nez se pokusim to CDcko vyndat?

[Marek Bernát]

A prečo explicitne, ak sa to dá riešiť implicitne? Načo ručne hľadať, ktorý súbor komu patrí a chodiť po všetkých otvorených aplikáciách. Ak bude funkčný ten revoke a aplikácie naňho budú pripravené, tak proste dáte revoke a hotovo (a ak pripravené nebudú, tak sa to rovná killu, ale to vôbec nevadí). A vy si to samozrejme robte ručne

[Michal Čihař]

Třeba protože se mi nechce hledat ve kterém z mnoha shellů, které mám puštěné je aktuální adresář na CD a proto ho nemůžu odpojit.

[Láďa]

Teď jsem potřeboval nasadit na Gentoo diskové kvóty, naštěstí když jsem server instaloval, tak jsem vybral XFS místo ext3 (popravdě jsem ani moc nevěděl proč to dělám). Teprve teď jsem zjistil, že jsem si ušetřil spoustu práce, protože XFS umí skvělé věci, které jak jsem tak četl různá HowTos na ext3 nemají šanci (kvóty jsou implementovány přímo v metadatech souborového systému, nepotřebuje žádný quotacheck, žádný běžící démon, umí tree quotas pro adresářové stromy atd.). Neboli na tom citátu možná bude něco pravdy Btw. no flame please - je možné, že lidi co psali HowTos to prostě jenom napsali blbě, ale nepřišlo mi.

[Heron]

XFS je pokročilý FS.

Zajímalo by mě, s čím se vytasí ext4. ext* se (zatím) drží velmi konservativní cesty, moc nových prvků imho neimplementuje. Quoty jsou jedna z nich, dalším je skutečně nativní podpora pro acl.

Na druhou stranu je to FS, který "just works".

[alblaho]

ext4 je jen údržba. Akorát kvůli podpoře větších souborů se změní diskový formát (co se jednou zkonvertuje na čtyrku, trojka už nepřečte), tak to musí být extra verze.

Já teda ext3 nemusím. Kromě toho, že je pomalý (ale to se dá jistě vytunit, výchozí nastavení je paranoia), tak se mi na něm občas vyskytly chyby. A to by měl žurnál zachraňovat. Z mého pohledu je "just works" Reiser3. Ale ext3 má zase nějaké jiné výhody, tuším malou latenci, což se hodí na některé appky.

Takže žádný flejm. Nejlepší je stejně asi XFS a stejně jsou lidi, co ho nemají rádi (třeba proto, že nemají UPS)

[Láďa]

Nebo mají server v Casablance na jejich "UPS, dieselgenerátorech a dvou nezávislých přípojkách na dva pražské obvody" Tam jsem skřípal zuby a říkal jsem si, jestli XFS byl opravdu tak dobrý nápad.

[Petrik]

Muzu se zeptat, pro je u XFS potreba UPS? XFS ma prece zurnal, takze by stejne jako u reiseru 3 vypadek napajeni nemel vubec vadit, ne? Ja uz totiz o nutnosti UPS pro XFS nectu poprve a jelikoz to je velmi vykonny FS, rad bych ho pouzival, ale UPS nemam.

[alkoholik]

Protoze XFS pri vypadku napajeni dost casto vykurvi data v souborech otevrenych pro zapis.

[Michal Ludvig]

Jojo. Naposledy minuly tyden. S ext2 sice system musim fsck-ovat, ale pak alespon vim ktere soubory to odnesly. XFS se po crashi tvari jako by nic a ja pak jeste mesic nachazim pomrvene soubory vsude mozne. Nejhorsi je ze ani sync neni jistota - staci mit soubor otevreny pro zapis a v tom okamziku vypnout napajeni - sance ze jsem o nej zrovna prisel neni zanedbatelna. Vyzkouseno.

Naproti tomu Reiser3 pri crashi eventualne znici jen to co bylo zmeneno a nebylo zapsano/syncnuto. Idealni na vyvoj kernelu system co chvili muze lehnout.

[none]

nejen otevrenych pro zapis, nedavno jsem z niceho nic prisel o 20GB dat, ke kterym jsem pristupoval pred nekolika hodinami (jen cteni). takze ups vrele doporucuji!

[Michal Kubeček]

XFS ma prece zurnal, takze by stejne jako u reiseru 3 vypadek napajeni nemel vubec vadit, ne?

Představa, že žurnálovací filesystém vás ochrání před ztrátou dat při nekorektním ukončení systému, je hojně rozšířeným omylem. Žurnálovací filesystém vám pouze poté, co se tak stane, umožní velmi rychle uvést filesystém do konzistentního stavu, aniž byste musel dlouho (třeba i desítky minut) čekat, až proběhne jeho kompletní kontrola.

[Petrik]

A jak je na tom reiser4? V popisu rikaji, ze to je atomarni system, ze opera budto probenhnou uplne, nebo vubec, ze to udelali nejak fikane tak, ze neni potreba duplikovat data. Nevi o tom nekdo neco vic?

[VM]

Ono tohle samo o sobe nestaci. Procesy volaji vice operaci zapisu, a pokud nektere atomicky uspeji a jine ne, tak vysledkem je stejne pokazeny soubor.

[Michal Kašpar]

FS ma prece zurnal, takze by stejne jako u reiseru 3 vypadek napajeni nemel vubec vadit, ne?

Opište stokrát "žurnálovací filesystémy nezaručují automaticky konzistenci dat při neočekávaném ukončení systému (např. výpadku napájení)". Většina žurnálovacích souborových systémů žurnáluje pouze metadata, což sice znamená, že při potížích by měl být v konzistentním stavu souborový systém, ale data na něm mohou být na kaši stejně, jako u souborového systému, který žádný žurnál nemá.

Jediný z linuxových fs ,o kterém vím, že chrání žurnálem i data je právě ext3 s parametrem data=journal. Viz např. tento článek.

[Michal Kubeček]

…a u toho ext3 se to téměř nepoužívá, protože to filesystém velmi výrazně zpomaluje.

[disorder]

a existuje nejaky FS, kde to vyrazne zrychluje? ;)

[Marek Bernát]

To má byť pokus o humor?

[disorder]

uplny zurnal vzdy spomali filesystem, nie je to nic vynimocne.

[Marek Bernát]

Ide o to, že opakom "veľmi výrazne spomaľuje" nie je len "veľmi výrazne zrýchľuje", ale aj tisíc vecí medzi tým. Bolo by to vtipné a ak veci, keby tam boli vhodné len tie dve možnosti. Takto som rád, že viem, že to nie je len "trochu pomalé", ale "príliš pomalé", pretože to nie je vôbec zrejmé, takže post pána Kubečka mi pripadá byť k veci.

[Marek Bernát]

s/ a ak veci//

[disorder]

opakom spomalenia je zrychlenie. ale o tom to nie je. ked si to nepochopil, tvoj problem.

namiesto slepej dovery tomu tvrdeniu (ktore si si mozno zle vylozil, pretoze mne to vyznelo ako porovnanie s rychlostou defaultneho zurnalu) by si mohol nejake benchmarky vyhrabat, alebo by si ich mohol spravit sam (porovnal by si aktualne verzie).

[Marek Bernát]

Opakom spomalenia je zrýchlenie? A opakom 1 je -1 podľa teba? By si sa mal vrátiť na základnú školu, ak ti unikajú takéto triviálne záležitosti. Možno by ti došlo, že množina riešení nie je dvojprvková a negácia prvku v takejto množine je bud nedefinovaná, alebo je to celý zvyšok množiny okrem toho prvku. Ale to vlastne na základnej neučia a každý to nechápe :-P

Ja nemám slepú vieru, ak by som to potreboval niekde použiť, tak si o tom zistím viac. Navyše ide o človeka, ku ktorého príspevkom som si za ostatný čas už vypestoval dôveru a navyše ten príspevok bol k veci. Ten žurnál mohol byť pokojne takisto rýchly, ako keby bol vypnutý. Dôkazom je až a iba experiment. Preto som nepochopil tvoj hlúpy komentár, ako keby to malo byť zrejmé, že to bude pomalšie.

[disorder]

1 a -1 su opacne cisla. toto sa uci aj na zakladnej skole a kazdy tomu chape (pokial neberiem do uvahy teba).

rovnako rychle to nikdy nebude, to pochopi aj sedliak. aby to bolo rovnako rychle museli by vsetky nadbytocne operacie trvat... nic.

[Marek Bernát]

1 a -1 su opacne cisla. toto sa uci aj na zakladnej skole a kazdy tomu chape (pokial neberiem do uvahy teba)

Ešte raz, pojem opačný prvok (alebo negácia) je väčšinou definovaný len pre dvojprvkové množiny, typicky pre hodnoty pravda nepravda, prípadne, v teórii množín, je negácia (alebo komplement) množiny definovaný, ako prvky v nadmnožine, ktoré do nej nepatria. Ale ťahať tieto pojmy do množiny odpovedí na otázku, prípadne do množiny celých čísel (ten príklad som použil naschvál, aby som sa uistil, že či tomu naozaj nerozumieš, alebo sa tak len tváriš), tak to sa robí len na tej zákldnej.

rovnako rychle to nikdy nebude, to pochopi aj sedliak. aby to bolo rovnako rychle museli by vsetky nadbytocne operacie trvat... nic.

Mohlo by to byť asymptoticky rovnako rýchle, nadbytočné operácie by mohli trvať O(1), takže v praxi by to bolo to isté, to pochopí aj sedliak, máš úplnú pravdu. Ale že sa to spomalí výrazne, to už vôbec zrejmé nie je.

[disorder]

nehovoril som o negacii ale o opaku. su to ANTONYMA. slova negovat nemozes, ich zmysel MOZES.

to o kolko sa to spomali zavisi od implementacie a HW obmedzeni. tak mas nejake porovnanie s inymi FS? neviem ako ty, ale ja by som to vyrazne spomalenie cakal (relativne-na velmi rychlom mediu by to mohlo byt nepostrehnutelne, ale rovnako vyrazne), kedze sa data zapisuju najprv do zurnalu a potom normalne.

[Marek Bernát]

nehovoril som o negacii ale o opaku. su to ANTONYMA. slova negovat nemozes, ich zmysel MOZES.

Opak je negácia, ale o tom potom. Podstatné je, že si použil jazykovú operáciu pri logickej debate. Tu si nemôžeš len tak obracať pojmy, ako sa ti zachce. Treba si uvedomiť, že "nie pomalý", znamená aj "bežný" a ja si mylím, že ak by si si toto uvedomil, tak by si ten hlúpy vtip nemohol napísať.

to o kolko sa to spomali zavisi od implementacie a HW obmedzeni. tak mas nejake porovnanie s inymi FS? neviem ako ty, ale ja by som to vyrazne spomalenie cakal (relativne-na velmi rychlom mediu by to mohlo byt nepostrehnutelne, ale rovnako vyrazne), kedze sa data zapisuju najprv do zurnalu a potom normalne.

Vidíš? Už o tom diskutuješ. Ak by to bolo také triviálne, tak by si o tom nediskutoval. Zostáva tu proste fakt, že to závisí od implementácie a tá môže byť pokojne rýchla.

[disorder]

vies kde je problem? ty nevies od coho sa odvija hodnotenie "vyrazneho spomalenia". v logickej debate usudzujem ze to je oproti normalnemu stavu, nie oproti ostatnym FS. tak som napisal to co som napisal. (50% spomalenie (minimum) je podla mna vyrazne)

[Marek Bernát]

Ja to predpokladám tak isto, že je to oproti normálnemu stavu. A hovorím, že nie je zrejmé, že to bude tak veľa, ale že by to mohlo pokojne byť aj menej, až na úrovni bežného stavu.

[disorder]

prosim ta, ako by si docielil to, aby dva zapisy na disk (plus nejake dalsie operacie) trvali to iste co jeden?

[Marek Bernát]

Stále prekrúcaš tému. Ja nie som expert na filesystémy, ani architektúru diskov. Ja len tvrdím, že by to _mohlo_ ísť, nie že sa to dá. A sedliackym rozumom mi to tiež pripadá, že by to malo byť pomalšie, ale používať sedliacky rozum pri takejto problematike považujem za hlúpe.

[disorder]

ako prekrucas? na to netreba byt expert aby si vedel, ze disky su najvacsi bottleneck a duplicitny zapis vyrazne pocitis.

[Marek Bernát]

Typický argument pre laikov. Najprv sa použije veta, ktorá je celkom zrejmá (bottleneck), aby čitateľ uveril, že sa autor vyzná a za ňou už môže ísť hocičo bez dôkazu (že je to výrazne pomalšie) a je to pravda (autor sa predsa vyzná!). Paráda, diskusia nám speje čoraz k vyššej úrovni, najprv sedliacky rozum, teraz toto. Myslím, že by sme to mali nechať tak. Nechaj si svoj sedliacky rozum a ked niekto príde s journalom, ktorý nebude pomalý, tak ho prosím ťa nepoužívaj! Také niečo sa predsa nedá, sedliacky rozum nepustí…(soráč, ak zveličujem, ale možno ti už dôjde, že zatiaľ si nepoužil jediný solídny argument v prospech tvojej teórie pomalosti. A sedliacky rozum pre mňa argumentom určite nie je. To už rovno môžem začať veriť v kreacionizmus, tam sa tiež používajú podobné argumenty.)

[disorder]

a ako by si to prelozil? to slovo to uplne vystihuje a mylim, ze jeho chapanie by ti nemalo robit problemy (ved mas google a wiki).

ked nedokazes pochopit, ze tvoj disk sa ti pouzitim uplneho zurnalu 2x nezrychli, tak to je koniec. dakujem.

[Marek Bernát]

a ako by si to prelozil? to slovo to uplne vystihuje a mylim, ze jeho chapanie by ti nemalo robit problemy (ved mas google a wiki).

Kde som napísal, že neviem, čo znamená bottleneck? Vidím, že ti úplne ušla pointa, čo už.

ked nedokazes pochopit, ze tvoj disk sa ti pouzitim uplneho zurnalu 2x nezrychli, tak to je koniec. dakujem.

Ešte raz, ja tvrdím, že by to mohlo ísť rýchlejšie ako dvakrát pomalšie, až na úroveň normálnej operácie (to znamená s vypnutým žurnálom). Teda, ak ti to mám napísať inak, rýchlosť bude k*v (kde, k je konštanta a v rýchlosť za bežného behu). Ty tvrdíš, že k bude vždy na úrovni ½. Ja tvrdím, že to je medzi ½ a 1. Ak ti ešte nedošlo, že toto je to, o čom hovorím, tak je to naozaj koniec. A ak nájdeš jediný príspevok, kde tvrdím, že sa to dvakrát zrýchli (samozrejme oproti normálnemu stavu, nie oproti spomalenému, ale takto hlúpo si to dúfam nemyslel?), máš u mňa pivo

[disorder]

si to doplietol. tu konstantu mas zle. 1/2 by bolo zrychlenie oproti normalnemu (1).

a je to od teba pekne, ale na normalnom disku nemas sancu, aby bolo k=1 alebo aspon priblizne. chapeme? a poprosim dokazy, o sci-fi implementaciach sa tu nebudem bavit.

[disorder]

alebo skor fantasy.

[Marek Bernát]

si to doplietol. tu konstantu mas zle. 1/2 by bolo zrychlenie oproti normalnemu (1).

Aha, takže ak bežím 4 m/s, tak 4 * ½ m/s = 2 m/s je zrýchlenie behu. No už aspoň vidím, s kým mám tu česť. Potom niet divu, že ti uniká pointa, ak nerozumieš jednoduchej operácii násobenia.

a je to od teba pekne, ale na normalnom disku nemas sancu, aby bolo k=1 alebo aspon priblizne. chapeme? a poprosim dokazy, o sci-fi implementaciach sa tu nebudem bavit.

Ako som už povedal, nemám chuť počúvať argumenty typu "nemáš sancu" od niekoho, kto o tom nič nevie.

Hm, a ak sa ti bude zdať, že ti neodpovedám niekde, kde ma explicitne vyzývaš na odpoveď a/alebo provokuješ, tak je to tým, že ťa blokujem, bude to tak lepšie pre všetkých

[VícNežNic]

Matematik sice nejsem, ale svým způsobem mi číslo +1 přijde jako opačné k -1. I když pojem opačnosti tu možná nemá vhodné a pevné teoretické základy, stejně tak si nemyslím, že bychom jen tak mohli říct, že mezi těmi čísli žádný aspoň přibližně podobný vztah není.

[disorder]

opacne cislo je normalny matematicky pojem. je to cislo, ktore ked pricitas k povodnemu dostanes 0.

a je rovnako vzdialene od 0 na ciselnej osi, ale na opacnu stranu :)

[Marek Bernát]

Máš pravdu, nemal som uviesť blbý príklad; nechtiac som vybral taký, kde je tento pojem definovaný aj v tomto zmysle. Ale prečítaj si to, čo som napísal nižšie.

[Marek Bernát]

Ono, môžeš mať definíciu, akú chceš, konkrétne pri aditívnej grupe sa používa pojem "opačný prvok", takže to sem náhodou sedí, ale to je len náhoda. Pri multiplikatívnej sa volá inverzný. Ale to nie je pointa, pointa, je, že ak poviem "nie som pomalý", tak to neznamená "som rýchly". A to bola presne implikácia, ktorú použil disorder.

[VícNežNic]

Možná. Ale rychlý a pomalý už může být dvojice, o které tu mluvíš Opět, diskuse praštěná, původní vtip sice možná nebyl vtipný, ale reakce na něj byla taky divná

[Marek Bernát]

Mne nevadí, že vtip nie je vtipný, dobrý vtip som už nepočul veky. Išlo mi o niečo celkom iné. Ale celkovo je tá diskusia neškodná, takže ja s tým problém nemám

[VícNežNic]

Tak jestli se tu někdo hádá takříkajíc profesionálně, s tím se nic dělat nedá

[Marek Bernát]

Tupým hádkam sa vyhýbam, ak jedna strana proste nepočúva, tak to je koniec. Tu je to v pohode, vlastne je to trochu ostrejšia diskusia, resp. tvoj pekný termín profesionálna hádka

[disorder]

mozes aj polemizovat ci je slany opakom sladkeho, ci je horky opakom kysleho. nic na tom nezmenis, matematicky to brat nemozes.

a antonymum som pouzil, aby som zdoraznil, ze uplny zurnalovaci fs ma vzdy rychlostnu penalizaciu. evidentne si nepochopil zmysel alebo si sa naschval zacal hadat.

[Marek Bernát]

a antonymum som pouzil, aby som zdoraznil, ze uplny zurnalovaci fs ma vzdy rychlostnu penalizaciu. evidentne si nepochopil zmysel alebo si sa naschval zacal hadat.

Áno, toto je podstata. Pretože tá rýchlostná penalizácia je síce zrejmá (je tam réžia navyše), ale nie je zrejmé, že to musí byť nutne aj badateľné v praxi (asymptoticky pomalšie). A o to mi ide celý čas, že ty si predpokladal, že to zrejmé je.

[disorder]

pokial si myslis, ze rezia zabera najviac casu, tvoj problem.

[Marek Bernát]

A réžia (súčasne s diskovými operáciami, ale tie patria pod ňu) samozrejme zaberá najviac času. Ak máš definíciu réžie bez diskových operácií, tak už vieš moju a nič by ti nemalo brániť sa vyjadriť k tomu dalej.

A inak, vôbec si sa nevyjadril k tomu, že si predpokladal, že je to zrejmé, pričom to zrejmé celkom určite nie je.

[disorder]

diskove operacie nie su rezia. ked to aplikujes na ramdisk, ta vyrazna pomalost takehoto zurnalu uz zrazu nie je taka (subjektivne) vyrazna, ze? takze rezia nezabera najviac casu.

ale kedze sa to pouziva na diskoch, tak je to zrejme.

[Marek Bernát]

Nie všetko, čo sa blyští, je zrejmé. Ale nebudem sa s tebou už hádať. Povedať, že je niečo zrejmé, by som si dovolil len pri jednoduchých matematických konštrukciách. Všetko ostatné "zrejmé" obvykle hovoria ľudia, ktorý o tom veľa nevedia (videl si nejakú konkrétnu implementáciu?). Nemusí to byť nutne tvoj príklad, možno si expert na filesystémy, ale ak si, tak si to mal povedať. Proste nemám rád slovo "zrejmé" od laika.

[disorder]

sedliacky rozum. vzdy to bude trvat aspon dvojnasobok casu.

[Marek Bernát]

Sedliacky rozum si nechaj pre seba. Ešte raz, nie som odborník na disky, ale príklad (možno úplne mimo). Tie zápisy môžu byť na fyzickom disku za sebou, takže disk nemusí veľmi seekovať, takže to určite nie je to isté, ako zapisovanie náhodných dát. Niekde sa dá použiť cache. A proste hocičo, ale moja pointa nebola navrhnúť riešenie. Proste nepoužívaj sedliackym rozum, tam kde sa to nedá. Sedliackym rozum je len inými slovami povedané, že sa tomu vôbec nerozumieš a že ti niečo pripadá zrejmé.

[disorder]

cache? cache sa strati pri vypadku prudu, tu ide o to, aby to bolo naozaj zapisane aj v zurnali.

a pokial ide o vselijake finty na zrychlenie, tak ma napada externy zurnal na druhom disku. ale to je AFAIK zase riziko.

a sedliacky rozum tu plati ci chces alebo nie. 1+1 != 1. a neviem si celkom predstavit implementaciu zurnalu, ktora by vzdy bola hned za zapisovanymi datami :)

[Marek Bernát]

Ale ja som tu nechcel hľadať implementácie a to čo som povedal bolo len tak, ešte raz, nič o tom neviem, okrem skúseností a dohadov a sedliackeho rozumu. A myslím si, že ty si na tom rovnako. A tomu 1 + 1 != 1 skutočne nerozumiem. Máme to tu nejako definované, aby to malo zmysel? Ak máš jednoprvkovú grupu, tak platí 1 + 1 = 1. Ale nebudem ťa chytať za slovíčka, je mi jasné, čo chceš povedať. Ide ti o to, že sa to bude musieť zapísať dvakrát a teda spomalenie je dvojnásobné. Ale toto práve mi jasné nie je, konkrétna architektúra disku by to mohla (hovorím mohla) byť schopná robiť efektívnejšie. To že si to nevieš predstaviť neznamená vôbec nič. Pokroky sa dejú stále a väčšina smrteľníkov nie je schopná pochopiť ani na čom sú založené, preto nie je divné, že by ich sami nikdy nevymysleli. Chcem len aby si uznal, že o tom nevieš toľko, aby si si mohol byť istý, že sa to rýchlejšie nedá, o nič viac mi nejde.

[disorder]

teraz len hladas unik. ked mi ukazes uplny zurnalovaci fs, kde to nebude vyrazne spomalene v realnych podmienkach (t.j. s mojim diskom), tak budem len rad. len tym ma presvedcis, ze mas pravdu. pretoze tu nejde o subjektivne zrychlenie pouzitim ineho hardware, ale o zrychlenie zurnalovania samotneho.

[Marek Bernát]

Ja únik rozhodne nehľadám, budem diskutovať, kým sa nezhodneme, alebo nás to neprestane baviť. Ale ty nechápeš, že ja netvrdím, že sa to dá, ale že sa to _môže_ dať. Pozri si ešte raz moje príspevky a dôjde ti, že je to tak. Všade, prakticky od začiatku píšem, že možno. Ide mi o tvoje rezolútne "určite to ide pomaly", pričom o tom veľa nevieš. Neverím, že poznáš dôkladne architektúru aspoň jedného pevného disku a neverím, že dôkladne poznáš implementáciu aspoň jedného plne žurnálovacieho filesystému. A ten sedliacky rozum si nechaj do krčmy, ak ho ešte raz vytiahneš, tak fakt nemá význam diskutovať.

[disorder]

tak si zjavne nepochopil, ze vychadzam z toho, ze fyzicky zapis si vyzaduje vacsinu casu a tiez som pisal, ze na ramdisku to nie je take vyrazne - ale len subjektivne.

[Kyosuke]

To je hóóódně pesimistické... Není k tomu moc velký důvod, když buffer flush ve většině případů sekvenční není, zatímco log write do vyhrazené oblasti disku je sekvenční vždycky.

[disorder]

to hovori sedliacky rozum :)

ale disk je disk, takze vyrazne spomalenie. a mohol by si dat nejaky interval, v ktorom sa to spomalenie obycajne pohybuje? to by ma zaujimalo.

[m0rph]

Jo, treba kdyz preformatujete ext3 na Reiser4 ;)

[disorder]

by som prosil nejaky benchmark uplneho zurnalu v tych dvoch fs.

[peter_h]

Toto reagujem na hornu diskusiu, je uz moc vpravo

Journalovanie v reiser4 je prave o tom, ze sa data nezapisuju dvakrat. Ak to dobre chapem, data sa zapisu akoze je to zurnal, a potom sa nejako atomicky zmeni na datovu cast. Problem reiseru4 je, ze bez repackera to ide po case s nim dole vodou. Viac na strankach namesysu, je tam pekny, dlhy obkec a tiez Hansova prednaska niekde v google video.

Journalovanie JE mozne urobit s rovnakym vykonom ako nezournalovany system, mozno este s vyssim, pretoze data sa najprv mozu zhromazdit v journali a potom sekvencne zapisat. Chce to len spravnu podporu v HW (samozrejme uz pri samotnom navrhu fs by sa s takymto hw muselo ratat). Vsetko je to len otazka penazi. Napr. lepsie RAIDy maju na sebe par 100mega ram a baterku, potom pri (kratkom) vypadku energie sa nacachovane data nestratia a write-caching nie je az taky riskantny.

(a mozno je to vsetko inak )

[disorder]

budem len rad, ked atomic fs budu spolahlive a vykonne, ale zatial som k tomu skepticky a ziadne masove presadenie sa zatial nekona. hlavne sa bojim stability - cim su veci jednoduchsie, tym menej sa moze pokazit :)

IMO specialne disky sa neoplati vyvijat a vyrabat. ani po tom nie je nejaky dopyt. mozno niekedy, ale skor by som povedal, ze sa to v buducnosti stane sucastou nejakeho ineho zaznamoveho media.

[peter_h]

V podstate netreba ani specialny disk, staci nejaka karta medzi radicom a diskom.
Faktom zostava, ze ext3 s plnym journalovanim podaval v urcitych situaciach vyssi vykon, ako je to teraz netusim.
A nove disky sa oplati vyvijat, disk je totiz v sucastnosti jedna z najpomalsich veci v PC. Vyvoj v oblasti diskov totiz prebieha, len sa nemeni celkova koncepcia - hlavicky pisu na platnu...

Reakcia na atomicke diskove operacie nizsie - je to o tom, ze ked robim nejaku jednoduchsiu aplikaciu, tak sa nepotrebujem s tym zbytocne trapit, proste poprepisujem subor a hotovo, but sa to prepisalo a je to konzistentne, alebo nie.

[disorder]

prave pre tu rovnaku koncepciu koncia. ja dufam, ze disky cim skor vymru a konecne ich nahradia nejake flash pamate, alebo nejake ine media (spolahlivejsie a odolnejsie, urcite prekonaju aj kapacitu diskov).

ext3 s plnym journalovanim podaval v urcitych situaciach vyssi vykon

by ma zaujimalo v akych. ale celkovo urcite nie. pri syncovani fs sa to vynahradi.

[none]

pri pouziti data=journal se nektere operace, docela zrychli. mozna take vychazite ze starych udaju, jelikoz se tento kod docela optimalizoval.

[Mikuláš Patočka]

Konzistenci dat ti nezajistí nic, ani žurnálování dat. Kernel nezná význam těch dat, tudíž nemůže určit, zda jsou data konzistentní nebo ne. Ext3 s journal-data zajistí pouze to, že write() na souboru budou provedeny v tom samém pořadí --- ovšem to ještě konzistenci neimplikuje.

Konzistenci dat by si měla každá aplikace zajišťovat sama --- databáze mají žurnál. Textové editory a další uživatelské aplikace by při ukládání souboru měly dělat to, že ho uloží do souboru file.tmp, pak provedou fsync() a pak udělají rename() přes původní soubor --- tím se zajistí, že ať systém spadne kdykoli, budeš mít buď starý nebo nový soubor, ale nikdy ne neúplný soubor. (a žurnálování dat k tomu není potřeba)

Pokud používáš špatně napsaný program, který při kliknutí na "Save" začne přepisovat půsovdní soubor, tak tě při pádu nezachrání nic ani žurnálovaná data.

BTW. kdysi byly myšlenky, že by se skutečné žurnálování dat mohlo dělat, aplikace by zavolala něco jako begin_transaction(), write(), write(), write(), commit_transaction() a filesystém by zajistitl, že se provedou buď všechny writy nebo žádný. Implementovat se to nikdy nepodařilo --- jednak je problém, co dělat, když aplikace udělá begin_transaction(), write() a pak nekonečně dlouho čeká? --- není možné ta data zapsat ani odemknout. U databází tento stav nevadí, protože se předpokládá, že všichni klienti zapisující do databáze jsou důvěryhodní, ale u filesystému je to problém. Další problém je, že u takovýchto transakcí může docházet k deadlockům, databáze to řeší tak, že některou transakci zabijou (jednou jsem viděl hlášku o deadlocku na WWW stránce, po reloadu se už stránka zobrazila správně), nicméně filesystém, který by svévolně zabíjel transakce by moc použitelný nebyl.

[Michal Kubeček]

Textové editory a další uživatelské aplikace by při ukládání souboru měly dělat to, že ho uloží do souboru file.tmp, pak provedou fsync() a pak udělají rename() přes původní soubor

Autorům aplikací, které se takto chovají, bych nejraději nafackoval. Je moc příjemné editovat soubor, který mám nalinkovaný do deseti adresářů, a po čase zjistit, že se mi jednotlivé verze "rozjely", protože autor editoru se zařídil podle vaší rady…

[stativ]

Asi takhle. Kdyz je vypadek a poskodi se data na FS, tak reiser a ext3 a v podstate jakykoli jiny fs pri obnove poskozenych dat data zpristupni. Ty data muzou vypadat na prvni pohled bezproblemova(proste tam jsou a co?), ale mohla se poskodit treba cast s pristupovymi pravy a k datum pak bude mit pristum kdokoli (pozn. tohle se mi opravdu stalo). XFS AFAIK takovahle data obvykle prepise nulami.

A taky jde o agresivni cachovani prace s diskem u XFS. Takze se muze stat, ze data, o kterych si clovek mysli, ze jsou davno ulozena jsou porad jeste nezapsana v cache.

Nezarucuji bezchybnost vyse psaneho textu.

[Mikuláš Patočka]

To s těmi nulami na souboru v XFS se stane tak, že transakce zvětšující velikost souboru byla commitnuta a transakce zapisující tam ty data nebyla --- takže z toho pak vznikne děravý soubor.

[Heron]

XFS mám na středně velkém FS (360GB v LVM2), několik výpadků napájení ten systém zažil a nic se neztratilo -- stejně jako na žádném FS.

Ale nadruhou stranu to není FileServer s hromadou paměti (kam si XFS ukládá kde co, hlavě cache -- a právě tohle je požadavek na UPS).

Osobně vidím největší problém pro FS vadný disk, nebo nedejbože rozpadlý raid.

[Jim]

Takže nezbývá než počkat na nativní implementaci božského ZFS, které nás NAVŽDY zbaví všech problémů - vadných disků, rozpadlých raidů, výpadků napájení, hádek s drahou polovičkou a kontrol z Finančního úřadu.

[Láďa]

Když jsem poslouchal kamaráda, co se vrátil z roční brigošky u Sunu a došel jsem ke stejnému názoru Chvilku jsem myslel, že ho tam jenom nakazili firemním nadšením, ale když jsm potom koukal na vlastnosti a způsob práce se ZFS, tak bych do toho šel hned. Jenom škoda, že pravděpodobnost toho je dost mizivá, navíc když se Sun před rokem pustil do OpenSolarisu.

[Milan Jurik]

Ale ze Vam ten sarkasmus jde

Je fakt, ze aspon, na rozdil od XFS, neztraci validni data

[Milan Jurik]

XFS na domacim stroji, pro vetsinu mountpointu. A takovy /var/lib/dpkg/available uz to dvakrat schytal. Nic prijemneho

Je fakt, ze posledni dobou (cca rok) uz se mi to nestalo, ale tam hraje nejspise i roli to, ze s tim strojem uz tolik nedelam a servery mam poctive na UPSkach.

[Tomá? ?imek]

Nevím z čeho vycházíte ale udělal jsem zajímavé závěry s fs v praxi, na zálohovacím serveru, kde měl zákazník 200GB dat (hodně malých souborů v relativně málo adresářích - v jednom 70000).

Ext3 fungoval obstojně, traverzace adresáře pomocí mc asi 3s.

Zkusil disk s daty zformátovat na Reiser3 a nechal synchronizovat data. Do 20000 souborů v adresáři traverzace téměř okamžitě, pak se ale začly časy exponenciálně prodlužovat (zatížení sytému 100%) a při 70000 trvala traverzace 2min.

XFS mne také zklamal nebyl sice nepoužitelný jako Reiser, ale traverzace trvala 7s

Nakonec jsem zkusil JFS, traverzace trvala něco málo přez 3s. Jelikož mi došel entuziazmus, už jsem ho tam nechal.

Otevření souboru všech FS skoro stejně a bez problémů s rychlostí, nic víc jsem nezkoušel.

[David Watzke]

XFS mne také zklamal nebyl sice nepoužitelný jako Reiser, ale traverzace trvala 7s

XFS na malý soubory není stavěnej...

[Heron]

Zajímavý test a překvapivé výsledky. Čekal bych, že si reiser poradí s mnoha soubory líp.

On je to vůbec obecný problém. Sám jsem se s ukládání mnoha (na začátku cca 400 000 s výhledem na několik milionů) souborů také potýkat, a žádný (!) FS nevyhověl.

Nakonec jsem to vyřešil podobně jako to řeší jiné projekty - totiž vytvořit strom adresářů (dvě nebo tři patra adresářů - adr[000-255]/adr[000-255]/adr[000-255]), pokud v každém adresáři máte 256 dalších adresářů, získáte celkem 16777216 "přihrádek" pro soubory.*

Výhoda je velmi rychlá traverzace -- vlastně každý adr obsahuje pár souborů. Zásadní nevýhoda ovšem byla nutnost pamatovat si v DB umístění každého souboru - to už je lepší ho uložit rovnou do BD jako blob.

*) Jen poznámka: někdo (tuším na linux@linux.cz) provedl test s paralelním ukládáním dat do tří různých souborů a zjišťoval jejich fragmentaci. Vyhrál to XFS (nad ext3 a reiserfs), který při souborech uložených v jiných adr vykazoval minimální počet extensí na soubor.

[Michal Kubeček]

Čekal bych, že si reiser poradí s mnoha soubory líp.

Možná je problém v tom, co znamená výraz mnoho. Kdysi jsem s tím experimentoval a při 20000 souborech s relativně krátkými názvy v jednom adresáři neměl ext2/ext3 výraznější problémy a dokonce snad byl i o něco rychlejší než ReiserFS. Otáčet se to začalo až někde nad 50000.

[peter_h]

Ten ext3 mal dirindex?
Inak to staci len nastavit a je to, alebo aj pustit nejake fsck?

[Heron]

Nastavit + spustit na tom fsck -Df, který vytvoří index i pro stávající adresáře.

[Láďa]

Na XFS se hlavně pořád pracuje (stačí se podívat na jejich web), třeba úplně skvělé project quotas byly přidány cca před rokem. U ext3 jsem si žádných výrazných změn nevšimnul.

[Mikuláš Patočka]

Tím hůř, že se na něm pracuje --- zanášejí se do něj bugy. XFS kdysi správce instaloval na server artax.karlin.mff.cuni.cz a od té doby server nevydrží běžet víc jak tři týdny. Jednou se mi tam dokonce XFS deadlocklo pod rukou, v mém adresáři vzniknul soubor, na který když se jakýkoli proces snažil přistoupit, tak zůstal viset ve stavu 'D'. Server vydržel ještě asi hodinu a pak spadl.

Když se kouknete, jak je XFS napsané, je to hrůza --- vzalo se původní XFS z IRIXu a napsala se mezivrstva, která má překládat linuxové rozhraní na irixové.

[disorder]

hansik je aky skromny clovek :)

(po tom co som pocul o reiserfs by som ho nikdy nepouzil - kopia zo zalohy je rychlejsia nez oprava fs)

[Jiří (BoodOk) Kadeřávek]

Znamena revoke(), že pujde neco udelat s trvale D-ckovymi procesy?

[neldor]

Mohlo by... I kdyz tyhle procesy imho obecne znamenaji nejaky bug v kernelu (pokud nejde o nedostupny NFS server).

[Mikuláš Patočka]

Ne --- D procesy s tím nemají nic společného a pokud se z toho stavu nelze dostat, tak je v kernelu bug. (při použití revoke() pak se ti pak do trvalého D stavu může dostat i ten revok()ující proces, protože se bude snažit zamknout soubor, jenž je již zamčen).

[nardew]

coraz viac zacinam s hansom suhlasit...

[Kyosuke]

V tomhle má Linus pravdu. S tou transparentností hardwaru je to dneska bída... Zvlášť v tom zpětně kompatibilním molochu s několika apendixy. A to si říkám, že jednou se psaní driverů stejně nevyhnu. No už se na to těším...

[nardew]

pozeram ze aktualna paticka :))

[David Jež]

Přesně, zvláště ta část o sedmdesátých letech sedí. Když vydíš jak jsou šíleně navrhovány ksichty, které by měly být co nejjednodušší, ale výsledkem je příšerně zbastlený kombajn, který neumí snad už jen otevřít pivo, tak je něco špatně. A ještě lepší je k tomu ve většině případů dokumentace, co by se dalo popsat jednou tabulkou a postihnout možné varianty je popsáno tunou dokumentů se spoustou příloh a ještě není jisté, jestli se jedná o kompletní verzi... Zářným příkladem je třeba popis SPD od JEDECu (no vlastně nejen SPD), z toho by se taky jeden zchocholouškoval. Těš se, hlavně pro to že stále může být ještě hůř .
-djz

[Jiří (BoodOk) Kadeřávek]

No zrovna na otevreni piva vetsinou zadnou specifikaci nepotrebujes. Ta funkce jaksi vyplyva z podstaty. Ja bych to skoro obratil. Nektery HW je tak transparentni, ze otevreni piva je jeho jedinou skutecne uzitecnou vlastnosti