[linux-l] mbox/Maildir/tar

[Steffen Dettmer]

* Rocco Rutte wrote on Tue, Nov 27, 2007 at 12:49 +0100:
> Man kann definieren, dass eine mbox-Mailbox ungelesene Nachrichten
> hat, wenn mtime > atime. 

Macht das etwa jemand?! Das geht ja schon kaputt, wenn zwei Prozesse das
File überwachen!

> Aus Performance-Gründen (oder warum eigentlich sonst?) wird ext2/ext3
> oder so oft mit noatime gemountet.  

Wird es? noatime macht Sinn bei Flash und DVD-RAM (und anderen Medien,
die durch Zugriffe schnell altern), aber sonst? Praktisch wir ja nicht
ständig geschrieben wegen caching.

> >Ach, Du meinst wegen Platten-Kopf-Bewegungen?  Meinst Du nicht, daß
> >das eher zweitrangig ist?
> 
> Ja. Nein. :-(
> 
> Bei ext3 mit dir_index macht z.B. Inode-Sortierung das Parsen bei mutt 
> "mal eben" um Faktor 12-13 schneller, wenn man die Mails nicht im header 
> cache hat. D.h. der Seek-Overhead ist wirklich extrem.

Das heisst, das Dateiöffnen geht genau dann schneller, wenn man die
Dateien in dieser Reihenfolge öffnet, richtig?

> Gut, das macht sich wohl erst bei Größenordnungen von 10k und mehr 
> (hier: >300k) bemerkbar. Aber 10 Minuten parsen statt >2h ist schon 
> krass, vor allem weil er simples Mergsesort das Problem löst. Mutt macht 
> da nicht viel, aber 300k Files aus einem komplett lesen in 2h ist 
> deutlich zu viel.

Natürlich ist es schneller, wenn die Daten so liegen, wie man sie gerade
verarbeitet. Daher sollte ein mbox für viele kleine Mails noch schneller
sein. Noch schneller sollte eine ramdisk sein.

Der übliche Vorteil von maildir ist doch aber gar nicht die Performance.

Wenn ich ein schnelles lokales Archiv will auf das nur ein Prozess
schreibend zugreifen können muss (z.B.), kann man vermutlich gut auf
maildir verzichten. Viele können vermutlich auch gut damit leben, wenn
irgendwas nicht richtig funktioniert, wenn man mit zwei MUA auf zwei
Maschinenen gleichzeitig zugreift, beispielsweise, weil sie nur eine
Maschine haben oder IMAP verwenden etc.

> Directory hashing ist ja ganz sinnvoll, um Files schneller zu finden. 
> Aber mit B+-Bäumen (oder war das B*?) hat man im Prinzip eine einfach 
> verlinkte Liste mit einem Baum zum schnellen Zugriff "oben drüber". Das 
> müsste doch reichen. Statt dessen muss man jetzt alle Anwendungen 
> anpassen, die größere Mengen Files aus einem readdir()-Lauf verarbeiten 
> wollen. :(

Warum muss man die Anwendungen anpassen?

> >Ich finde auch das mbox-Format nach wie vor interessant.
> >Was man da für einen schnellen Zugriff benutzen kann,
> >ist ja eine Indizierung, um zu wissen, an welcher
> >Poition in der Datei eine neue Mail anfängt; man braucht dann nicht
> >dauernd die Mails einlesen. (Darüber gab es hier ja schon mal
> >Diskussionen.)
> 
> Das bringt aber nichts. Dann musst du ein neues Format erfinden, denn 
> wenn ich Mail XY an Stelle 3 ändere und sie dadurch kürzer/länger wird, 
> müssen alle Indizes angepasst werden. 

Ja klar, das haben Indizes so an sich, aber die sind ja schneller
aktualisiert als viele Dateien.

Ich glaube, wenn man oft in Mails ändert, ist maildir schon fein, mbox
muss ja immer umkopiert werden.

> Oder man merkt sich nur die Länge der Nachrichten und kann
> inkrementell dann Offsets relativ schnell berechnen (also schneller
> als Parsen), weil man den Index dicht genug packen kann.

Geht bei maildir auch (wenn wir schonmal bei neuen Verfahren sind), wenn
man sie die gelesenen Strukturen (Index/Cache inkl. Mailheader) speichert.

Das Öffnen von einer Mail box ist ja nicht /der/ zu optimierende Punkt.
Ich will z.B. die Auslieferung schnell haben und habe arbeite meistens
mit kleinen Foldern (letzten 30 Tage maildirs mit meist weniger als 1000
Mails). Daraus wird dann in grosse mailboxen verschoben. Das ist mit
maildir schnell und sicher mit einem einfachen Perlscript cron job
möglich. Bei mbox eher nicht so einfach.

> Aber das Hauptproblem an dem Ansatz ist: jetzt hast du nicht 1x sondern 
> 2x Locking.

(Wieso, Du musst doch nur den Index locken?)

> >tar hat übrigens ja das selbe Problem: alle Dateien in einer
> [...]
> >Naja, aber wir waren ja bei mbox-Format/Maildir-"Format".
> 
> Ich finde:
> 
> http://synflood.at/blog/index.php?/archives/399-Warum-.tar.gz,bz2-zum-Archivieren-hirnverbrannt-ist.html
> 
> hat den netten Ansatz, pro File zu packen und dann in einem Container 
> zusammenzuwerfen. Hat auch den Vorteil, dass man join/split trivial ist 
> (ideal für Archivierung). Sowas könnte man wirklich mal implementieren.

Es folgt nur noch ne längere inhaltsarme Stellungnahme zu dem Blog.

Nur leider funktioniert der Ansatz nicht gut... Zip wird da ja schon als
Beispiel genannt. Im Test ein maildir (Mailingliste) mit 689
Dateien:

teffen at link:/tmp/1> time tar czf tgz ~/Mail-In/freifunk
real    0m0.277s
steffen at link:/tmp/1> time tar cjf tbz ~/Mail-In/freifunk
real    0m3.446s
steffen at link:/tmp/1> time zip -qr zip ~/Mail-In/freifunk
real    0m0.332s
steffen at link:/tmp/1> ls -lh tgz tbz zip.zip 
-rw-r--r--    1 steffen  users        613K 2007-11-28 20:17 tbz
-rw-r--r--    1 steffen  users        738K 2007-11-28 20:17 tgz
-rw-r--r--    1 steffen  users        1,8M 2007-11-28 20:17 zip.zip

ZIP ist nicht nur langsamer als tgz, sondern auch eine halbe
Grössenordnung schlechter!

Zum Vergleich: reines tar (unkomprimiert) 4,4M mit gzip und zip gepackt
in beiden Fällen 738K (das tar ist nur 116 Byte kleiner). Der
Kompressions-Algorithmus selbst ist also bei den gleichen Testdaten
gleichwertig.

Macht man es Datei-basiert, muss man pro File einen neuen Baum mit Token
erzeugen, macht man es für ein tar muss man nur einen einzigen Baum
erzeugen (was bei Bandsicherungen sehr blöd ist, weil ein Bitfehler das
ganze Archiv himmeln kann).

Der Container-Ansatz ist auch nicht streamfähig. zip ist nicht
streamfähig (kann ich nicht in eine pipe bauen), gzip oder bzip2 sind es
aber.

Sowas könnte man mit Bordmitteln über ein tmp-Verzeichnis implementieren
(z.B. einfach aber langsam wäre kopieren, find|xargs gzip, tar oder so).
Ich hab auch das mal ausprobiert, komme auf 2,2M Ergebnis, also noch
schlechter als zip.

bzip2 kann wohl alle 900kb nach Fehlern `recovern', ist wohl
einstellbar, da könnte man dann den Fehlerschaden ggf. etwas reduzieren
(tar kann das ja auch ein bisschen). Keine Ahnung, wieviel das hilft,
bei maildirs sicherlich gar nicht. Die am besten gar nicht komprimieren,
was sind heute 600 MB wo es doch 600 GB Platten gibt :-)
Wenn, dann lieber viele kleine Dateien komprimieren (z.B. je 10.000
Mails oder so).

Der Blog schreibt aber ja auch nur, dass im Falle eines Restores es
lange dauert, wenn man nicht weiss, wie die Datei heisst, die man als
einzige restoren möchte, was ja auch eher selten ist und anders gelöst
werden kann (log file aufheben, -vR verwenden, ...).

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.