[linux-l] mbox/Maildir/tar

[Rocco Rutte]

Hi,

* Oliver Bandel wrote:
>Zitat von Rocco Rutte <pdmef at gmx.net>:
>> * Oliver Bandel wrote:
>> >Zitat von Steffen Dettmer <steffen at dett.de>:

>> >> P.S.: http://www.qmail.org/man/man5/maildir.html

>> >Ist ja eigentlich trivial; aber eine gute Idee, dieser Aufbau.

>> Ich bin da inzwischen fast schon anderer Meinung. Maildir löst das
>> Locking-Problem (und damit auch NFS-Sorgen) sozusagen "final" sowie
>> das
>> noatime-Problem bei mbox für das Linux-Lager.

>noatime-Problem?

>IMHO ist noatime ein Unding.

>Ist fast wie nofilename ;-)
>oder wie noPID ;-)

>Wie wirkt sich noatime bei Benutzung
>von mailfoldern im mbox-Format aus?
>Das ist mir nicht klar. Verlassen sich die Reader
>auf die atime für ihre Operationen?
>Fände ich nur sinnvoll; man verlässt sich ja auch auf andere
>Informationen des Filesystems.

>Wo ist da das Problem?

Man kann definieren, dass eine mbox-Mailbox ungelesene Nachrichten hat, 
wenn mtime > atime. Aus Performance-Gründen (oder warum eigentlich 
sonst?) wird ext2/ext3 oder so oft mit noatime gemountet. Verstanden 
habe ich das nie so richtig.

>> Andererseits hängt die Benutzbarkeit teilweise von Low-Level-Sachen wie
>> Dateisystemparametern ab, was nicht Sinn der Sache sein kann (also als
>> Admin am FS zu fummeln nur weil User Maildir haben könnten).

>Wo ist in dem Falle das Problem?
>Kannst Du das mal erläutern?

S.u.

>> Um es
>> schnell zu implementieren, muss man leider genau wissen in welcher
>> Reihenfolge die Blöcke der Files auf der Platte liegen.

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

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.

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

Eine Sortierung setzt aber widerum voraus, dass die zu Inodes gehörigen 
Blöcke auch strikt linear auf der Platte liegen. Ob das immer bei allen 
FS der Fall ist, weiss ich nicht.

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

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

Aber so richtig bin ich nicht überzeugt, dass die Indizierung was 
bringt. Höchstens wenn du außerhalb es Mailclient was suchst. Dann kann 
man aber auch gleich grep nehmen; der Mailclient muss es aus anderen 
Gründen parsen, wo ihm der Index nichts nützt.

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

MfG, Rocco