[linux-l] mbox/Maildir/tar

[Oliver Bandel]

Zitat von Steffen Dettmer <steffen at dett.de>:

> * Rocco Rutte wrote on Wed, Nov 28, 2007 at 22:26 +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!
>
> Nochmal warum es nicht funktioniert:
>
> - proc A und proc B überwachen.
> - proc C schreibt neue mail
> - proc A stellt fest, mtime > atime
> - proc A liest Änderungen (setzt atime)
> - proc B merkt nichts, weil atime schon wieder neuer
>
> A und B sind natürlich wechselbar. Einer merkt es, der andere nicht.


Schön.

Normalerweise ist das mbox-Locking aber notwendig, nicht weil
mehrere Lesen und einer Schreibt, sondern weil einer liest und mehrere
möglicherweise Schreiben.

Das, was Du da schön beschrieben hast, ist also nicht der
Fall, der auftaucht, wenn Dein Mailreader neue Mails meldet
und mehrere Mails Dir z.B. über mehrere Procmails in die
Boxes schreiben.

Also wird die atime auch nur vom (vom = von dem einen)
Mailreader geändert, die anderen (die Schreiber)
ändern die mtime.

Also passt es.




[...]
> Wenn ich wissen möchte, ob sich ein File geändert hat, seit ich es
> gelesen hab (Zeitpunkt X), prüfe ich doch, ob dessen mtime neuer ist
> als
> Zeitpunkt X?! Wie kommt man darauf, die atime zu verwenden? Was ist,
> wenn ein anderer Prozess das File auch liest?
[...]

Warum sollte ein anderer Prozess da die Files auch lesen?


>
> > Es ist es auch der mit Abstand schnellste Weg, es gibt keine
> > Alternativen.
>
> Ich hab sowas schon in etlichen Scripten gemacht. Ich hab mir immer
> mtime gespeichert, das file gelesen und dann gewartet, bis mtime >
> last_mtime wurde. Was ist daran falsch/schlecht/langsam?

Ja, stimmt. So würde ich es auch bauen.
So habe ich das bisher auch gmeahct, wenn ich ein einzelnes
File mir nochmal angeschaut habe.
Z.B. Apache-Log lesen mit Tool, das kein Daemon ist.
Merke Zeit und Ort (Position im File) usw. ...
...wobei die Zeitmessung hier eher für die Intervalltime
wichtig ist.... aber das führt jetzt weg vom Thema.



>
> > 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).
>
> ja, hab ich gefunden. Grösse ist meiner Meinung genauso falsch, wenn
> eine neue Mail mit 2K reingeht und eine andere mit 2K gelöst wird,
> bleibt die Dateigrösse ja konstant.
[...]

Eben.
Aber das Filesystem bietet einem ja Zeitinfos an... :)


[...]
>
> Weiss jemand, warum man das mit dem atime macht?

Viele schreiben, einer liest?!


>
> > >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.
>
> Nein, eben nicht /immer/. Hat man grosse Dateien, ist mbox langsam,
> weil
> man (ohne index, was ja mbox erstmal nicht hat)
[...]

mbox hat keinen Index.
Aber mbox hat auch keine Statusflags im Header.


> ja u.U. Megabytewise
> MIME Anhänge parsen müsste, um die nächste Mail zu finden.
>
> Eigentlich ist es ja durchaus elegant, das Filesystem als Index zu
> benutzen.

Stimmt.
Ist eine Möglichkeit, wie man schnell zu einem Ergebnis kommt.
Nennen wir es wohlwollend Rapid Development.


> Ich meine, dafür ist es ja da! Es gibt Resourcen (u.A.)
> Namen,
> man dann da was lesen/schreiben - genau, was man hier braucht und bei
> maildir ja verwendet wird.

Ja, sozusagen ein Hash :)
Filename ist der Key und Inhalt ist die Value.



>
> > 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.
>
> Na ja, lokal mit flock oder fnctl locking funktioniert ja (jedenfalls
> hatte ich früher, als ich sowas benutzt hatte, keine Probleme im
> Falle
> ein procmail und ein PINE oder mutt), oder? So theoretisch
> jedenfalls.
> Nur halt nicht ganz immer...


Wieso "halt nicht ganz immer"?




>
> > 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.
>
> Ja, das geht nicht. Man muss exklusiv locken und umkopieren, bei
> jeder
> Änderung. Schreibt man Änderungen nicht sofort, muss man das lock
> halten
> und kein anderer kann schreiben.

Eben.

Und da man auch keinen anderen Lesen lässt,
dann verstellt sich auch die atime nicht.


>
> In solchen Fällen (mbox als spoolfile) ist das meiner Erfahrung nach
> schnell extrem tötlich langsam - aber mailbox sollte doch nicht
> kaputtgehen...
>
> > Das ist zwar jetzt arg konstruiert, aber im Prinzip schützt das
> Locking
> > nicht vor kaputten Foldern;
>
> ja klar, wer sich nicht an dsa locking hält... Aber wer sich nicht
> daran
> hält, kann die Datei auch einfach löschen, ist's auch kaputt...

Eben.

Das ganze $HOME wegmetzeln....



> > [ 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.
>
> Warum muss man die mbox+ (ich nenn das mal anders, weil mbox mit
> Index
> ist ja nicht mbox, weil mbox kennt sowas ja nicht) locken? Man kann
> doch
> definieren, dass man die Index immer lockt, das gilt dann immer für
> mbox
> mit. Theoretisch könnte man die mbox lesen wollen ohne index zu
> lesen,
> aber dann muss man laut dieser Konvention halt trozdem den Index
> locken.
> Damit ist mbox+ und Index eine logische Resource.
[...]

Und in den Index kommen dann auch noch die Flags rein,
dann braucht man die mbox, die DANN erst eine ist,
auch nicht mehr immer wieder ändern, nur wenn man mal eine Mail
lesen will.

Gruß,
   Oliver