Maildir vs. BSD MBox Was: Maildir Backup (was: Re: Vergleich Courier Cyrus)

Mon Aug 6 21:16:01 CEST 2007

On Mon, Aug 06, 2007 at 05:00:52PM +0200, Maximilian Wilhelm wrote:
> > Siehe oben
> Widerlegt :)

Was schaetzt du wieviel prozent der User auf dieser Mailingliste sich 
Tivoli geleistet haben ?

> OK, gekauft.
> 
> Wenn ich jetzt aber eine Kosten-Nutzen-Rechnung mache und mir
> überlege, wie oft ich Backup und Restore mache, relativiert sich das
> dann auch wieder (Je nach Backuptool und -strategie).

Nein - Die Frage ist wie lange sich die Firma leisten kann ohne mails zu
sein. Und >24h kann schon ein massiven verlust bedeuten - ist also
inakzeptabel. Bei uns sind 4h schon inakzeptabel.

> Ich denke ich werde aus meinem LKML-Maildir mit atm >= 30.000 Mails
> mal ne mbox machen und mal schauen wie das performed.
> Ich denke, das ist als Testcase schon ganz gut...

Hier der Testcase - Cache cold lesen eines 58000 Mails 350MByte/s LKML 
folders. Testmaschine P4 2.4Ghz, 1GB, Single Disk IDE, ext3 mit 
dir_index enabled.

Um den page cache zu leeren:

	flo at touch:~$ dd if=/dev/zero of=file count=1 bs=1G
	1+0 records in
	1+0 records out
	1073741824 bytes (1.1 GB) copied, 23.7312 seconds, 45.2 MB/s

Lesen des folders - Druecken von Q waerend des lesens:

	flo at touch:~$ time mutt -R -f linux-kernel.200704 

	real    0m15.678s
	user    0m6.532s
	sys     0m1.272s

Hier die groesse:

	flo at touch:~$ ls -la linux-kernel.200704 
	-rw------- 1 flo mways 353973385 2007-08-06 12:01 linux-kernel.200704

Cache hot die wiederholung:
	flo at touch:~$ time mutt -R -f linux-kernel.200704 

	real    0m9.107s
	user    0m6.656s
	sys     0m0.860s

Convertiert zu Maildir
	flo at touch:~$ time mb2md -s linux-kernel.200704 -d linux-kernel.200704.Maildir/
	Converting /home/flo/linux-kernel.200704 to maildir: /home/flo/linux-kernel.200704.Maildir
	Source Mbox is /home/flo/linux-kernel.200704
	Target Maildir is /home/flo/linux-kernel.200704.Maildir 
	58000 messages.

	real    1m11.467s
	user    0m45.607s
	sys     0m8.541s

Hier dann die versuche mit Maildir:
	flo at touch:~$ time mutt -R -f linux-kernel.200704.Maildir/

	real    0m35.741s
	user    0m9.301s
	sys     0m5.344s
	flo at touch:~$ time mutt -R -f linux-kernel.200704.Maildir/

	real    0m15.623s
	user    0m9.061s
	sys     0m2.448s

Backup:
	flo at touch:~$ time tar -cf /scratch/test linux-kernel.200704

	real    0m18.083s
	user    0m0.024s
	sys     0m1.716s

	flo at touch:~$ time tar -cf /scratch/test linux-kernel.200704.Maildir/

	real    12m39.741s
	user    0m0.712s
	sys     0m5.712s

Vergleich:
~350MByte 58000 Messages. 

			Maildir		BSD MBox
	Cache Cold	 35.7s		15.6s
	Cache Hot 	 15.6s		 9.1s
	Backup		759.7s		18.0s

Ich habe die Maildir backup zahlen auch nicht glauben wollen und habe es 2
mal wiederholt. Backup war von /dev/hda nach /dev/hdc d.h. jedesmal war
der writer auf einer anderen platte.

Der Punkt ist das von dem linearen schreiben/erzeugen von allen mails
profitiert Maildir noch mehr als BSD Mbox. Dadurch wird das Disklayout
so das alle inodes, dentrys und Datablocks sehr nah beieinander und damit
guenstig fuer das read-ahead liegen. Ich wuerde erwarten das bei einem
jahrealten filesystem bei dem die files nach und nach erstellt worden sind 
das der vorteil weiter zugunsten von der BSD MBox ausfaellt da diese ab und
an sequentiell komplett geschrieben und damit defragmentiert wird.

Die grundsaetzliche argumentation ist immer - In den letzten 10 Jahren 
hat sich die streaming performance von platten von ~200KByte/s
auf >50MByte/s verbessert. ALso in etwa faktor 25 schneller geworden. 
Im selben zeitraum ist avg Seektime der platten von 50ms auf 8ms
gefallen also auf 1/6tel. 

mbox bedeutet ich nutze die streaming performance von platten und lesen
mehrere mega bis gigabyte sequentiell in den speicher. Bei Maildir
muss ich fuer die Metadaten mehrfach auf der platte seeken. D.h. fuer
einen Seek von ~10ms kann ich 50Mbyte/1000*10 = 500Kbyte in den Speicher
schaufeln.  Bei einer durchschnittlichen Mailgroesse von 4KByte/s habe
ich 125 Mails gelesen bevor im Maildir verfahren der Kopf bei der 2ten
Mail ist (Ausser acht lassend das ich fuer den direntry und die inode
und bei den filesystem noch bei grossen mails die indirekt blocks lesen
muss. Dazu den atime update im inode). Das ganze laesst natuerlich sowas
wie adaptiv read-ahead und inode/dentry caches ausser betracht. Aber
wenn machen wir mal cache-cold betrachtungen bzw man muss immer davon
ausgehen das mein "working set" groesser als mein Hauptspeicher ist.

Das hinzufuegen von "Spindles" d.h. dem raiden des storage ist auch fuer
diesen vergleich irrelevant da beim hinzufuegen einer platte sich die
anzahl der koepfe verdoppelt d.h. die seekzeit statistisch halbiert,
jedoch die streaming performance sich auch verdoppelt.

D.h. meine worst case betrachtung bei Maildir ist das ich den dentry
lesen muss, dann den inode, dann einen indirect block und dann die mail.
D.h. 3 seeks fuer die erste mail. Mit read-ahead habe ich dann den
dentry und die inodes der naechsten mails schon dabei.

Natuerlich ist das fuer den entwickler viel einfach weil man sich um
viele dinge wie mail flags, delete etc keine sorgen machen muss. Alle
metainformationen die im filename d.h. im dentry abgelegt sind, und
damit lockfrei veraendert werden koennen.

Und mit weiterer entwicklung von Festplatten wird die kluft immer
groesser werden, daher empfinde ich Maildir einfach als rueckstaendig,
und als ausdruck der faulheit der programmierer.

Flo
-- 
Florian Lohoff                  flo at rfc822.org             +49-171-2280134
	Those who would give up a little freedom to get a little 
          security shall soon have neither - Benjamin Franklin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lug-owl.de/pipermail/linux/attachments/20070806/4362ff00/attachment.sig>