Jaderné noviny - 10. 1. 2007 (diskuse)

[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ší :)