Jaderné noviny - 10. 1. 2007

30. 1. 2007 | Robert Krátký

Články - Jaderné noviny - 10. 1. 2007  

Aktuální verze jádra: 2.6.20-rc4. Proč je kernel.org tak pomalý. Vývoj KVM. Unionfs. Blížící se 2.6.20, sledování regresí.

Aktuální verze jádra: 2.6.20-rc4

Aktuální předverze jádra řady 2.6 je 2.6.20-rc4, vydaná 6. ledna. Linus o ní řekl: Vůbec nic zajímavého - pokud si nechcete hrát s KVM nebo se vás netýkala chyba s těmi starými verzemi linkeru, kvůli které mizely části entry.S."

Do hlavního git repozitáře bylo od té doby začleněno přibližně 100 patchů. Jde o opravy, většinou v subsystémech architektur, ALSA a síťování.

Aktuální verze -mm stromu je 2.6.20-rc3-mm1. Mezi nedávné změny patří KVM (vizte níže), další sada změn API pracovních front a virtualizace struct user.

Aktuální stabilní 2.6 jádro 2.6.19.2, vydané 10. ledna. Obsahuje dlouhou řadu oprav, včetně opravy problému s poškozováním souborů a několika bezpečnostních potíží.

Starší jádra: 2.6.16.38-rc1 bylo vydáno 9. ledna a také obsahuje spoustu oprav - mnohé z nich řeší bezpečností chyby.

Proč je kernel.org tak pomalý

Kernel.org je hlavním repozitářem pro zdrojové kódy linuxového jádra, množství vývojových stromů a hromadu příbuzného materiálu. Nabízí také zrcadlení několika dalších projektů souvisejících s Linuxem - například CD obrazy distribucí. Uživatelé kernel.org si občas všímali, že je server dost pomalý. Jednotlivým vydáním jaderných stromů trvá dlouho, než se objeví na hlavní straně a zrcadlení zaostává. Vypadá to, že tato důležitá součást vývojové infrastruktury nedrží krok s nároky, které jsou na ni kladeny.

Z diskuzí v konferencích je zřejmé, že servery kernel.org (jsou dva) často běží s průměrnou zátěží v rozsahu 2-300. Není tedy moc překvapivé, že se vždy nechovají tak svižně, jak by se od nich očekávalo. Mluví se o přidání serverů, ale zároveň panuje shoda v tom, že by se současné servery se zátěží měly umět vypořádat. Takže se vývojáři snažili zjistit, co se děje.

Problém je patrně způsobován gitem. Kernel.org hostuje docela dost git repozitářů a také systém gitweb - i když gitweb je často vypínán, když zátěž příliš stoupne. Problémy s gitem zase vycházejí z toho, jak rychle umí Linux načítat adresáře. Podle administrátora kernel.org H. Petera Anvina:

Během extrémně vysoké zátěže to vypadá, že více než cokoliv jiného je kernel.org zpomalován tím, jak dlouho trvá každé jednotlivé volání getdents(). Když jsem to sledoval, naměřil jsem časy od 200 ms po až skoro 2 vteřiny! Tak si to spočítejte sami, když nezabalený *NEBO* nepročištěný [unpruned] git strom přidává k čistě zabalenému stromu 256 adresářů.

Zjevně je něco v nepořádku s tím, jak se při velkých zátěžích zachází s objemnými souborovými systémy. Část problému může být v tom, že Linux v takové situaci nevyhrazuje dost paměti pro kešování adresářů, ale hlavní chyba je jinde. Ukazuje se, že:

• Systémové volání getdents(), které se používá pro čtení adresářů, je (podle Linuse) jedno z nejnáročnějších v Linuxu. Zamykání je nastaveno tak, že v jednu chvíli může daný adresář číst jen jeden proces. Pokud musí tento proces čekat na diskový I/O, tak spí, přičemž drží semafor inody a tím blokuje všechny ostatní zájemce o čtení - i v případě, že by některé z nich mohly pracovat s částmi adresáře, které jsou již v paměti.
• U adresářů se neprovádí žádné přednačítání [readahead], takže musí být postupně přečten každý blok, přičemž se celý proces pokaždé zastavuje a čeká na I/O.
• A aby to bylo ještě horší, tak ačkoliv se souborový systém ext3 usilovně snaží dávat soubory na disk souvisle, u adresářů taková snaha neexistuje. Je tedy dost pravděpodobné, že víceblokové adresáře budou na disku roztroušeny, což vynucuje vyhledávání při každém čtení, takže kešování stop, které možná dělá samotný disk, vychází nazmar.

Třetí z těchto neduhů může být vyřešen přechodem na XFS, kterému se lépe daří udržovat adresáře pohromadě. Kernel.org by takový přechod mohl podstoupit - za cenu týdenního odstavení každého ze serverů. Nedá se proto čekat, že se tak stane přes noc.

Prioritou číslo jedna pro zlepšení situace je tedy pravděpodobně implementování nějakého přednačítání adresářů. To by ubralo na čase stráveném při čekání na I/O adresářů, ale především by to nevyžadovalo žádnou změnu stávajících souborových systémů. Dokonce ani zálohu a obnovu. Jeden raný readahead patch už se objevil, ale protože jde o komplexní záležitost, bude potřeba několik kol pečlivých kontrol, než bude hotovo opravdové řešení. Výsledek tedy čekejte kolem 2.6.21.

Vývoj KVM

O sadě patchů KVM jsme stručně mluvili minulý říjen. Ve zkratce: KVM umožňuje (relativně) jednoduchou podporu virtualizovaných klientů na novějších procesorech. Na CPU s podporou intelské nebo AMD hardwarové virtualizace může hypervizor otevřít /dev/kvm a prostřednictvím série ioctl() volání vytvořit virtualizované procesory; a na těch spustit hostované systémy. Ve srovnání s plnou paravirtualizací (jako je Xen) je KVM poměrně prosté a přímočaré; to je jeden z důvodů, proč bylo KVM zařazeno do 2.6.20, zatímco Xen zůstává venku.

Ačkoliv je KVM v hlavním jádře, nedá se říci, že by bylo dokončené - a před i po vydání 2.6.20 by se ještě mohlo dočkat výrazných změn. Jeden aktuální problém se týká implementace "stínových tabulek stránek" [shadow page tables], která nepodává požadovaný výkon. Řešení je koncepčně jednoduché - tedy když pochopíte, co stínové tabulky stránek dělají.

Tabulka stránek samozřejmě představuje mapování z virtuální adresy na příslušnou fyzickou adresu (nebo příznak, který říká, že mapování v tuto chvíli neexistuje). Virtualizovanému operačnímu systému je přidělen rozsah "fyzické" paměti, se kterou může pracovat, aby si implementoval vlastní tabulky stránek, které budou mapovat mezi jeho virtuálními adresními prostory a přiděleným paměťovým rozsahem. Ale hostova "fyzická" paměť je ve skutečnosti virtuální rozsah spravovaný hostitelem; hostované systémy nepracují přímo s "železem". Výsledkem je, že mezi virtuálním adresním prostorem na virtualizovaném hostu a skutečnou fyzickou pamětí, na kterou mapuje, máme dvě sady tabulek stránek. Host může nastavit jednu úroveň překládání, ale pouze hostitel může spravovat mapování mezi "fyzickou" pamětí hosta a opravdovou pamětí.

Tato situace je řešena pomocí stínových tabulek stránek. Virtualizovaný klient si myslí, že spravuje své vlastní tabulky stránek, ale procesor je ve skutečnosti nepoužívá. Místo toho implementuje hostitelský systém "stínovou" tabulku, která zrcadlí tabulku hosta, ale mapuje hostovy virtuální adresy přímo na fyzické adresy. Stínová tabulka je vytvořena prázdná; každý výpadek stránky [page fault] na hostovi pak způsobí zaplnění příslušné stínové položky. Jakmile u hosta proběhnou výpadky ve stránkách, které potřebuje, bude moci běžet nativní rychlostí bez nutnosti dalšího zapojení hypervizora.

S verzí KVM, která je v jádře 2.6.20-rc4, však toto šťastné soužití moc dlouho nevydrží. Jakmile host provede přepnutí kontextu [context switch], je ta obtížně vybudovaná stínová tabulka stránek zahozena a nahrazena novou. Výměna stínové tabulky je nutná, protože proces běžící po přepnutí kontextu bude mít odlišnou sadu mapování adres. Ale když se předchozí proces dostane zpátky na procesor, bylo by fajn, kdyby tam na něj jeho stínová tabulka čekala.

Patch pro kešování stínových tabulek stránek, který poslal Avi Kivity, dělá přesně to. Místo aby prostě stínovou tabulku zahodil, dá ji na stranu, aby mohla být natažena, až bude příště potřeba. Nápad je to jednoduchý, ale implementace vyžaduje 33dílný patch - je potřeba se postarat o hodně drobností. Spousta potíží vychází z toho, že hostitel nedokáže pokaždé odhadnout, jestli host v položce tabulky stránek provedl nějaké změny. Proto musí být hostovy tabulky stránek chráněny před zápisem [write-protected]. Kdykoliv pak host provede změnu, narazí na hypervizora, který změnu dokončí a příslušným způsobem aktualizuje stínovou tabulku.

Aby systém ochrany před zápisem fungoval, musí kešovací patch přidat mechanismus pro reverzní mapování, který mu umožní sledovat výpadky nazpět až k tabulce(-kám), o kterou jde. Občas může dojít k zajímavé situaci, při které přestane být tabulka stránek používána, aniž by o tom hostitelský systém věděl. Aby tuto situaci odhalil, hlídá si kód KVM příliš časté nebo odchýlené [unaligned] zápisy, které (heuristicky) značí, že se funkce stránky změnila.

Jádro 2.6.20 je v poměrně pokročilém stádiu vývoje; finální verze by měla vyjít někdy koncem měsíce. Přesto by si Avi přál, aby byly tyto velké změny začleněny ještě teď. Ingo Molnar souhlasí:

Testoval jsem ty nové změny MMU docela zevrubně a vychází to pěkně. Režii spojenou s přepnutím kontextu sráží desetkrát a více, dokonce i u mikrobenchmarků: místo zahazování celé té pracně sestavené hierarchie stínových tabulek umožňuje tato sada patchů inteligentní kešování. Efekt je vidět pouhým okem - systém je zřetelně svižnější.

Protože je KVM v jádře 2.6.20 nové, nezpůsobí změny v jeho rámci žádné regrese. Je tedy pravděpodobné, že tato nová funkce bude přidána, i když už je tak pozdě ve vývojovém cyklu.

Unionfs

Jeden dlouho známý (a v Linuxu dlouho nepodporovaný) koncept souborového systému je union filesystem [sjednocený souborový systém]. Union souborový systém je logickou kombinací dvou nebo více dalších souborových systémů, což vytváří iluzi jediného souborového systému s obsahem všech.

Jako příklad si představte uživatele, který by chtěl připojit DVD s distribucí plné balíčků. Bylo by fajn mít možnost přidávat aktualizované balíčky opravující bezpečnostní chyby, ale DVD je médium, na které nejde zapisovat. Řešením je unionfs. Administrátor systému může vzít zapisovatelný souborový systém a spojit jej s read-only DVD, čímž vytvoří zapisovatelný souborový systém s obsahem obou. Pokud pak uživatel přidá balíčky, půjdou na zapisovatelný souborový systém, který tak může být menší, než kdyby měl pojmout celý obsah.

Unionfs patch od Josefa Šípka tuto možnost nabízí. S unionfs pak může administrátor systému sestavit spojené souborové systémy pomocí následujících příkazů:

    mount -r /dev/dvd /mnt/media/dvd
    mount    /dev/hdb1 /mnt/media/dvd-overlay
    mount -t unionfs \
          -o dirs=/mnt/media/dvd-overlay=rw:/mnt/media/dvd=ro \
          /writable-dvd

První dva řádky jen připojí DVD a zapisovatelný oddíl jako běžné souborové systémy. Poslední příkaz je spojí do jediného svazku [union], který je připojen jako /writable-dvd. Každá "větev" svazku má prioritu určenou pořadím, ve kterém jsou uvedeny v parametru dirs=. Když je hledán soubor, jsou větve prohledávány podle priority, přičemž uživateli je vrácen první nález. Je-li učiněn pokus o zápis read-only souboru, bude tento zkopírován do zapisovatelné větve s nejvyšší prioritou a tam zapsán.

Jak je asi zřejmé, musí jít o dost komplexní systém, aby všechno tohle fungovalo. Spojování hierarchií souborových systémů, kopírování souborů mezi nimi a vkládání "zabělených" míst kvůli maskování souborů vymazaných z read-only větví. To jsou jen některé z problémů, které je nutné řešit. Zdá se, že kód unionfs většinu z nich zvládá dobře.

Při kontrole kódu se tedy všichni pustili do výjimky, která je zmíněna v dokumentaci:

Provádění změn přímo ve větvi unionfs ve chvíli, kdy je připojen svazek, není v současné době podporováno. Všechny takové změny mohou způsobit vše od žádné reakce, přes oops unionfs, až po ZTRÁTU DAT.

Znamená to, že je nebezpečné se vrtat přímo v souborových systémech, které byly spojeny do svazku. Andrew Morton poznamenal, že z hlediska uživatelského rozhraní se jedná o dost hrubý nedostatek. A protože připojení pomocí --bind tento problém nemá, zeptal se, proč by takovou past na uživatele měl mít unionfs. Josef odpověděl:

Připojení přes bind je záležitost na úrovni VFS. Unionfs je však, jak naznačuje název, souborový systém. Minulý rok na OLS to vypadalo, že se mnoho lidí shoduje v tom, že svazkování [unioning] není věc ani čistě FS, ani VFS.

To vyvolalo docela rázná prohlášení v tom smyslu, že by unionfs měl být implementován na úrovni virtuálního souborového systému. Bez toho není jisté, že by se kdy podařilo udržet koherentní jmenný prostor při změnách na všech úrovních svazku. Jak se zdá, unionfs bude potřebovat přepsat, aby si získal souhlas vývojářů jádra. Andrew Morton uvažoval o tom, jestli by neměla být aktuální verze začleněna v naději, že by to tento přepis podnítilo. Doposud nebylo žádné rozhodnutí učiněno, takže vůbec není jasné, zda bude mít Linux v dohledné době podporu unionfs nebo ne.

---

Následující obsah je © KernelTrap

Blížící se 2.6.20, sledování regresí

9. led, originál

Adrian Bunk vystavil seznam známých regresí v posledním jádře 2.6.20-rc4 oproti předchozím stabilním vydáním verze 2.6.19. Ve dvou zprávách vyjmenoval šest regresí, pro které ještě nejsou opravy, a šest opravených, jejichž opravy ještě nebyly začleněny.

V jiném emailu Linus Torvalds načrtl, že pro 2.6.20 má v plánu především zaměření na stabilitu. Také uvedl, že stabilní jádro se chystá vydat někdy po skončení konference linux.conf.au, která se letos koná v Sydney od 15. do 20. ledna. Vysvětlil: Poslední -rc snad vyjde před LCA, ale vlastní vydání 2.6.20 nechám až na potom. Nechci, aby období pro začleňování nových věcí probíhalo během LCA, protože jak já, tak mnozí další budou stejně pryč. Bude tedy lepší, aby LCA proběhlo ke konci stabilizační fáze, kdy se toho snad moc dít nebude.

Diskuse k tomuto článku

[Radek Hladik]

Unionfs je fajn a klidne si ho prelozim z balicku jako modul. Horsi je, ze uz pomerne dlouho obsahuje bug, ktery pri spojeni nekolika adresaru do jednoho a vyexportovani pomoci samby neukazuje vsechny soubory. Ovsem uz jsem nejakou dobu nezkousel, zda se neco nezmenilo, nevite o tom nekdo neco?

Radek

[Radek Podgorny]

Kdyztak, pokud jste nespokojen s kernelim unionfs, muzete zkusit FUSE implementaci: http://podgorny.cz/unionfs-fuse/

[Jiri]

Jak se unionfs tvari, kdyz je jeden z tech filesystemu primountovan na adresar z toho druheho filesystemu? Jde to vubec?

[Michal Ludvig]

Diky za uvadeni originalniho anglickeho terminu v zavorce za prekladem. Myslim ze to takhle je mnohem prehlednejsi a uzitecnejsi pokud uz o veci neco vim a tudiz znam jen puvodni nazev, nebo pokud se chci dozvedet neco dalsiho a tedy potrebuju puvodni nazev pro vyhledavani.

[Robert Krátký]

Rádo se stalo. I když mám pocit, že jsem to dělal i dříve - jen asi ne v tolika případech.

[petr_p]

Context switch ma v cestine ustaleny preklad prepnuti kontextu (ne zmena). Ale na srozumitelnost to vliv nema.

[Robert Krátký]

OK, upravím.

[Michal Vyskočil]

Kacířská myšlenka - co dát na kernel.org BSD?

[Ľubomír Host]

Nechcem robit flame, ale nemyslim si, ze by to *BSD zvladalo lepsie. Ak to spravne chapem, tak kernel.org stoji na tom, ze je pomaly paralelny pristup k adresarom, ktore su asi dost velke.

Podla toho, co som naskumal ohladom filesystemov v *BSD (napr. FreeBSD), tak je vykon fs vo FreeBSD (UFS1, UFS2) niekde na urovni linuxoveho ext3. Stabilne, ale pomale. Aj preto sa zacina pracovat na integracii XFS z ZFS do FreeBSD. XFS v linuxe uz nejaky ten piatok funguje, ZFS sa portuje zo Solarisu na linux rovnako ako do FreeBSD.

Odporucam precitat si zoznam algoritmov implementovanych v XFS a zistis, ze ten fs je dost inde ako zvysok.

P.S.: toto ti na *BSD nezbehne:

time  perl -e 'foreach my $i (1..35000) { mkdir($i) or die $!; } '

[vencour]

Dík za tip, na noťasu mam výsledek

$ time  perl -e 'foreach my $i (1..35000) { mkdir($i) or die $!; } '
0.02user 3.31system 0:23.92elapsed 13%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+421minor)pagefaults 0swaps

- je to ok?

[Ľubomír Host]

Ak ten skript dobehol a neskoncil s chybou, tak ano. Na FreeBSD nemozes mat v jednom adresari viac ako 32767 podadresarov v jednom adresari. Tam to skonci s chybou.

[Aleš Kapica]

No ono je to spíš asi omezení souborového systému než operačního systému, nebo se mýlím?

[Ľubomír Host]

Sulasim. Ale vzhladom na to, ze FreeBSD ma iba UFS1/UFS2, tak je to zaroven obmedzenim FreeBSD.

[vencour]

Bez chyby doběh ... paseku mi tu ten skript udělal pěknou ... a jinak mam reiserfs asi 3.6 v def. konfiguraci.

[Ľubomír Host]

Super. Perfektny cas. U mna XFS taky cas neviem dosiahnut. Ja mam casy zhruba nasledovne:

0.20s user 14.00s system 41% cpu 34.328 total

Moze to byt aj mierne odlisnym HW. Ale na druhej strane toto cislo nic neznamena. Na vytazenych serveroch je dolezity vykon pri paralelnych a opakovanych citaniach/zapisoch.

Btw. time /bin/ls -la > /dev/null na tomto adresari s 35 tis. podadresarmi za 1.2 - 1.9 sec.

Skusme este toto:

mkdir x;
cd x;
time  perl -e 'foreach my $i (1..150000) { mkdir($i) or die $!; } '; \
 time /bin/ls -la > /dev/null ; time /bin/ls -la > /dev/null
cd ..
time rm -rf x > /dev/null

Vysledok:

perl -e 'foreach my $i (1..150000) { mkdir($i) or die $!; } ' \
  0.77s user 51.86s system 30% cpu 2:53.09 total
/bin/ls -la > /dev/null  1.88s user 4.38s system 43% cpu 14.298 total
/bin/ls -la > /dev/null  1.52s user 1.38s system 86% cpu 3.337 total
rm -i -v -rf x > /dev/null  5.30s user 63.94s system 39% cpu 2:54.92 total

Ma niekto niekde ext3 filesystem? ;)

[vencour]

Já bych to svaloval na těch 1.5GB RAM, co vy?

$ free -m
             total       used       free     shared    buffers     cached
Mem:          1390       1294         95          0         57        467
-/+ buffers/cache:        768        621
Swap:            0          0          0

[Ľubomír Host]

Tak je to jasneee, ja mam iba 512MB RAM a podtaktovany procesor.

[Michal Kubeček]

Nechápu tak úplně smysl toho vašeho smajlíku. 150000 podadresářů sice na ext3 nevytvoříte (vzhledem k 16-bitové hodnotě link count), ale pro 31900 mi to vychází takto:

# ext3
real    0m5.515s
user    0m0.012s
sys     0m1.884s

real    0m0.790s
user    0m0.372s
sys     0m0.408s

real    0m0.425s
user    0m0.264s
sys     0m0.164s

real    0m11.698s
user    0m0.068s
sys     0m11.301s
# XFS
real    1m37.638s
user    0m0.060s
sys     0m3.560s

real    0m0.757s
user    0m0.300s
sys     0m0.456s

real    0m0.374s
user    0m0.200s
sys     0m0.172s

real    1m26.941s
user    0m0.276s
sys     0m5.764s

Oba filesystémy byly vytvořeny s defaultními parametry, pouze u ext3 jsem použil '-m 0' (což by ale na rychlost nemělo mít vliv). Výsledky XFS by asi šlo nastavením parametrů vylepšit, ale i tak bych řekl, že s tou pomalostí ext3 to nebude až tak strašné, jak naznačujete…

[Ľubomír Host]

Ale da sa to otestovat aj na velkom pocte suborov vytvorenych v jednom adresari. Aj ked po zavedeni dir_hash v ext3 s avykon ext3 asi vyrazne zlepsil.

time  perl -e 'foreach my $i (1..150000) { open(F, ">$i") or die $!; close(F); } ';
time /bin/ls -la . > /dev/null ; time /bin/ls -la . > /dev/null ; 

perl -e 'foreach my $i (1..150000) { open(F, ">$i") or die $!; close(F); } ' \
  1.09s user 9.92s system 11% cpu 1:34.37 total
/bin/ls -la . > /dev/null  1.49s user 2.14s system 63% cpu 5.712 total
/bin/ls -la . > /dev/null  1.48s user 1.34s system 73% cpu 3.812 total

P.S.: /bin/ls je pustene po sebe 2x schvalne, aby sa ukazalo cahovanie dat.

[Michal Kubeček]

Tady jsou výsledky pro 150000 souborů (nevytvářel jsem je ale tím perlovým skriptem, napsal jsem si na to prográmek v C):

ext3:
  real    0m5.717s     0m2.550s    0m2.516s    0m3.661s
  user    0m0.164s     0m1.664s    0m1.700s    0m0.052s
  sys     0m5.076s     0m0.884s    0m0.816s    0m3.604s
XFS:
  real    8m12.059s    0m2.472s    0m1.936s    7m41.173s
  user    0m0.312s     0m1.192s    0m1.072s    0m0.224s
  sys     0m17.365s    0m1.272s    0m0.864s    0m16.457s

Ty výsledky XFS při vytváření a mazání souborů se mi nějak nelíbí, asi to ještě vyzkouším na ramdisku.

[Ivanhoej]

Pre JFS:

$ time  perl -e 'foreach my $i (1..150000) { open(F, ">$i") or die $!; close(F); } ';
real    0m17.068s
user    0m0.676s
sys     0m8.321s

$ time /bin/ls -la . > /dev/null ; time /bin/ls -la . > /dev/null ;

real    0m1.604s
user    0m1.268s
sys     0m0.280s

real    0m1.606s
user    0m1.336s
sys     0m0.272s

[Michal Kubeček]

Hezké, ale něco mi říká, že aby ta čísla mělo smysl porovnávat, musel byste to zkoušet na stejném počítači… :-)

[Ivanhoej]

to je vela tych 17 sec?

Masina to bola:

CPU: AMD64 X2 3800+ Disk: 320GB Seagate FS: JFS Pamat: 1GB

[Michal Kubeček]

To se právě nedá posoudit. Smysl by to mělo, pokud byste stejný test provedl na jednom konkrétním počítači s několika různými filesystémy (např. ext3, ReiserFS, XFS, JFS).

[..... Izak .....]

JFS je jednoznacne nejrychlejsi, jenze trpi takovym nedostatkem, ze kdyz se JFS neodpoji, nejsou tam data ani po 20 minutach, testoval jsem to vypojenim power snury .... a vzdy to chtelo opravit, protoze to samo ani nenabehlo. A vzdy to stratilo kupu veci, mozna to bylo tim, ze jstem tam dal jen par textaku, ale uz jsem tam dostal i predposledni verzi, misto posledni ... taktez samozrejme par minut pockano.

[peterh]

Ked maju s tym taky problem, preco to nebezi nad nejakou databazou? FS asi nie je urceny na to naco ho git pouziva (priznavam ze netusim ako funguje git).

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

Tohle je unix, tak dejte pokoj s databází. Jedná se o prostou manipulaci se soubory a adresáři, žádné x-násobné joiny, group by a transakce. Pokud ten problém nějak vyřeší na systémové úrovni, budou na to benefitovat všichni, nejen servery kernel.org.

[Majkls]

Možná to bude znít jedovatě. Ale ono je dobře, že ten problém nastal a že se používá git. Aspoň je vidět, co systém dělá na vytížených strojích. A třeba s tím i někdo něco provede. Když korg něco pálí, vždycky se to řeší :)