[linux-l] mbox/Maildir/tar

[Rocco Rutte]

Hi,

* Steffen Dettmer wrote:
>* 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!

Dann müssen sie sauber mit utime(3) zurücksetzen. Und ja, mutt macht das 
schon immer so. Es ist es auch der mit Abstand schnellste Weg, es gibt 
keine Alternativen. Die Dateigröße geht nicht, komplett MIME-parsen 
dauert zu lange und müsste blockieren. Für Systeme mit kaputter atime 
hatte mutt früher eine compile-time Option, die mittlerweile runtime ist 
(auf ftp.mutt.org sollte noch irgendwo fixatime.c rumliegen für cron). 
Die verlässt sich auf die Größenangaben der Mailbox, das ist aber nur 
eine Heuristik.

>> 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?

Ja.

>> 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.

Ohne header caching und sonstige "Tricks" ist 1 File pro Mailbox immer 
schneller als 1 File pro Mail, weil nicht nur seeking fast komplett 
entfällt, sondern noch mehr overhead wie readdir(), tausende zusätzliche 
open()/fopen()-Aufrufe, etc. Das kann teilweise erheblich werden. mbox 
war bei mir schon immer schneller als Maildir ohne Cache.

>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.

Für Archive ist mbox mglw. eine Wahl. Aber sonst nicht.

Es geht bei den Locking-Problemen nicht primär um den MUA sondern darum, 
dass dir irgendjemand in die Mailbox schreiben kann, während du sie 
ebenfalls schreiben willst. Das kann z.B. auch procmail statt einem 
anderen MUA sein. Oder: ein Tool könnte für Manipulationen Offsets 
berechnen, etwas anderes rechnen und dann mit den Offsets schreiben 
wollen. In der Zwischenzeit könnte sich das File aber so geändert haben, 
dass die alten Offsets jetzt völlig falsch sind, ergo: Mailbox kaputt.  
Und wenn es mitten in einer Mail kaputt geht und der Client einfach 
Datenmüll als Nachricht parsed (oder Content-Length ignoriert), kriegt 
man es nichtmal mit außer vielleicht an der Zeilenanzahl/Größe der Mail 
(aber wer guckt schon danach).

Das ist zwar jetzt arg konstruiert, aber im Prinzip schützt das Locking 
nicht vor kaputten Foldern; also entweder ein Mailformat ohne Locking 
(Maildir) oder was anderes, wo nur ein sauberer MDA die Zustellung 
übernimmt (und wo der Storage abstrahiert ist, d.h. nur so Funktionen 
wie Nachricht löschen, anhängen, ersetzen, etc. nach außen sichtbar 
sind, kein Seek, keine Offsets).

>> 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?

Weil eine nicht-angepasste Anwendung auf Inodes in zufälliger 
Reihenfolge zugreift und (meinen Tests nach) um Faktor >10 langsamer 
ist.

[ mbox mit Index ]
>> Aber das Hauptproblem an dem Ansatz ist: jetzt hast du nicht 1x sondern 
>> 2x Locking.

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

Wenn man die mbox und den Index ändert muss 2x locken.

>> 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:

Dass Kompression pro File u.U. schlechter ist, hatten wir ja schon. Wenn 
aber für Backups in einem tgz an der falschen Stelle ein bit kaputt ist, 
dann ist der ganze Block hin. Wenn jedes File komprimiert wird, ist nur 
1 File hinüber (und da evtl. auch nur 1 Block). Hat alles Vor- und 
Nachteile.

Ich habe den Link nur eingeworfen wegen der Index-Problematik für tar, 
nicht wegen der Kompression. Ein solches Verfahren mit n Files pro 
"Container" würde das Problem lösen, weil der Index eingebaut ist. Und 
man bekäme join/split for free.

>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, ...).

Aber selbst dann muss alles erst entpackt werden, weil ja das tar-File 
als solches komprimiert wird. Der Container hätte da enorme Vorteile, 
weil man den Header nicht komprimiert. Man kann also ohne Dekompression 
und mit ein paar Seeks von Header zu Header springen und den 
durchsuchen. Da sollte die Datenmenge keinen Einfluss haben; ein tar 
-ztf je nach Größe dagegen dauert u.U. lange und erzeugt Last.

Soll heissen: 'tar ... | gzip > foo' ist zwar Unix aber vom Prinzip 
kaputt. :)

MfG, Rocco