Re: Pakete, die wesentlich bremsen, finden

[Richard Mittendorfer <delist@gmx.net>]

Also sprach Andreas Pakulat <apaku@gmx.de> (Fri, 10 Feb 2006 00:20:53
+0100):
> On 09.02.06 23:31:28, Richard Mittendorfer wrote:
> > Also sprach Andreas Pakulat <apaku@gmx.de> (Thu, 9 Feb 2006 22:45:21
> > +0100):
> > > On 09.02.06 21:07:20, Christian Bodenstedt wrote:
> > > > Sehe ich das richtig: du benutzt xfs als root-Dateisystem? Als
> > > > ich mich vor ein/zwei Jahren zu Dateisystemen informiert habe,
> > > > hieß es immer: xfs ist toll und schnell bei großen Dateien aber
> > > > für viele kleine Dateien ist es einfach nur lahm.
> > > 
> > > Entweder hast du das falsch in deinem Kopf abgespeichert, oder
> > > aber dich falsch informiert. XFS ist gerade sehr gut bei vielen
> > > kleinen Dateien im Gegensatz zu ext2/3 in der Default-Konfig. XFS
> > > legt den Verzeichnissinhalt IIRC als Baum ab.
> > 
> > Meinst du nicht reiserfs's (no)tail - mountoption?
> 
> Nein, ich hab noch nie reiserfs benutzt. Aber seit ca. 1 Jahr mein
> $HOME auf XFS, weil das Maildir mit der d-u-g deutlich schneller laedt
> mit XFS als mit ext3 (ohne dir_index, das kannte ich da noch nicht).

~/Maildir hab ich auch auf reiserfs. Den Rest XFS. /boot ext2, wird aber
selten gemountet.
 
> > Kann aber sein, dass XFS das auch kann.
> 
> Wie oben gesagt ich kenne XFS erst seit etwas ueber einem Jahr, aber
> ich habe noch nie davon gehoert das es langsamer ist als ext2/3. Eher
> im Gegenteil.

Right.

> > > > Für kleine Dateien sollte wohl Reiser der Hit sein
> > > 
> > > Das mag sein
> > 
> > Ist so.
> 
> Hast du dazu Benchmarks? Insbesondere im Vergleich zu XFS?

Zufaellig noch wekche von gestern zur Hand. Es ging in dem thread aber
darum, ob ich ueber einen UltraSCSI/8bit Controller mehr als 20MB/sec
bringe wenn die Drives an einem Kable haengen und eines davon den Bus
schon gut auslasten.  Google sollte aber auch genug hergeben, gerade in
Sachen Filesystem Benchmark hab ich eine Menge gefunden.

<message>
[...]    Here are bonnie++(v1.03) results on xfs and reiserfs over a
raid0 [sdb|sdc]. I did no tuning of drive/mount parameters or VM with
2.4. 

hdparm -tT
2.4.32 disks:
/dev/sdb  364MB in 2.01 sec =    181 MB/sec
           44MB in 3.14 sec =  14.01 MB/sec
/dev/sdc  360MB in 2.01 sec = 179.10 MB/sec
           44MB in 3.12 sec =  14.10 MB/sec
/dev/md4  352MB in 2.01 sec = 175.12 MB/sec
           44MB in 3.02 sec =  14.57 MB/sec

2.6.15 disks: (see above)
</stop>

md0 : active raid0 sdc3[1] sdb3[0]
      963712 blocks 64k chunk

/dev/sdc:
 Timing cached reads:   468 MB in  2.01 seconds = 232.84 MB/sec
 Timing buffered disk reads:   50 MB in  3.12 seconds =  16.03 MB/sec
/dev/sdb:
 Timing cached reads:   468 MB in  2.00 seconds = 234.00 MB/sec
 Timing buffered disk reads:   50 MB in  3.08 seconds =  16.23 MB/sec
/dev/md4:
 Timing cached reads:   468 MB in  2.00 seconds = 234.00 MB/sec
 Timing buffered disk reads:   52 MB in  3.02 seconds =  17.22 MB/sec

<weiter>
2.4.23 mem=256M / bonnie++ -s 512M
reiserfs (no mountoptions):
cell,512M,5686,88,21261,46,7710,10,5508,79,16705,9,342.4,3,
     16,3609,92,+++++,+++,6894,99,3727,95,+++++,+++,5054,88
xfs (logbufs=8)
cell,512M,6668,96,23106,25,7807,9,5468,79,16902,9,295.7,3,
     16,1170,57,+++++,+++,1410,48,1123,54,+++++,+++,758,36

2.4.23 mem=128M / bonnie++ -s 512M
reiserfs (no mountoptions)
cell,512M,6107,95,19152,41,8097,10,5815,84,16976,10,237.9,2,
     16,5710,94,+++++,+++,6884,99,5804,97,+++++,+++,5091,88
xfs (logbufs=8)
cell,512M,6716,97,19943,21,8145,9,5809,83,17167,9,209.9,2,
     16,898,44,+++++,+++,1523,54,863,44,+++++,+++,936,38

When testing with RAM*4 files it shows that it (the HBA) can't deliver
more than 20MB/sec. While I saw 25MB/sec (like the 23MB/sec seq.read
above), it just was due to bad messurement with RAM*2 files (which
didn't show up on 2.6 this way).

2.6.15-cks3 mem=128M / bonnie++ -s 512M
reiserfs (notail,noatime)
cell,512M,9134,98,18200,32,8924,13,10224,99,18583,17,238.1,3,
     16,5369,99,+++++,+++,6301,95,5197,100,+++++,+++,5443,100
xfs (logbufs=8)
cell,512M,9432,97,19480,25,8376,13,10914,97,18600,18,208.9,3,
     16,854,38,+++++,+++,1257,40,830,38,+++++,+++,735,30

</message>

> > > >, ext2/3 seie aber auch nicht schlecht.
> > > 
> > > Das genau nicht, jedenfalls nicht ohne die dir_index Option. 
> > 
> > Schon lange nicht mehr verwendet. ext2 ist aber gewiss recht flott,
> 
> Schonmal versucht ein dir mit >3000 kleinen Dateien mit ls zu listen?
> Da kommst du mit nem standard-ext2 nicht gegen XFS und vmtl. auch
> ReiserFS an. Wenn man aber die dir_index Option einschaltet (womit das
> Lookup von Dateien mittels B-Baeumen durchgeführt wird) sind XFS und
> ext2/3 ziemlich gleich schnell.

Nein. Hab ext schon lange nicht mehr angeschaut. Glaub' ich dir auch so
gern.
 
> Womit ich allerdings keine Erfahrung habe ist die Veränderung von
> Block-Groessen um bei kleineren Dateien weniger "Verschnitt" zu haben,
> bzw. weniger Fragmentierung ueber die Zeit...

Ist ohne raid nicht sehr tragisch. Je nach geschaetzter Verwendung und
Groesse des Dateisystems einen Eintrag von 1024, 4096 oder 8192 waehlen.
Geschwindigkeitsmaessig ist's nicht sehr relevant, wohl aber, was die
Platzverschwendung angeht. Also news/mail mach' ich zwischen 1024 und
4096, normal 4096 und eine ogg-Sammlung mit 8192. IIRC sollte mkreiserfs
das nach Partitionsgroesse ohne Angabe vernuenftig selber bestimmen. Bei
XFS bin ich mir nicht sicher, da ich's momentan nur auf raid hab und da
die chunck-/stripe-size zur Berechnung verwende. 

Wieviel genau mit den verschiedene Blocksizes an Platz drauf geht hab
ich auch nicht gemessen.
   
> Andreas

ritch