[linux-l] mbox/Maildir/tar

[Oliver Bandel]

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

> * Oliver Bandel wrote on Tue, Nov 27, 2007 at 22:22 +0100:
> > > Man kann definieren, dass eine mbox-Mailbox ungelesene
> Nachrichten
> > > hat,
> > > wenn mtime > atime.
> > [...]
> >
> > OK, ja, das macht Sinn.
>
> (Find ich nicht)
>
> > > Aus Performance-Gründen (oder warum eigentlich sonst?) wird
> > > ext2/ext3 oder so oft mit noatime gemountet. Verstanden habe ich
> das
> > > nie so richtig.
> >
> > Wenn ich das richtig sehe, ist noatime ein Workaround für nen
> > ext3-Design-Fehler?!
>
> atime ist ein abschaltbares Feature.


"Feature" klingt irgendwie "optional".
PIDs sind auch ein feature des kernels,
und IP-Adressen sind ein Feature,
und Filenamen.
Sollte man alles auch abschalten können. ;-)

Kommt bestimmt irgend eine Linux-Kernel-Hacker
mal auf die Idee, das zu machen, weil es ja so cool ist.

Und hinterher funktioniert nix mehr.... aber immerhin schnell isset.


[...]
>
> > > >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.
> >
> >
> > Böse, böse.
> > Das hätte ich nicht gedacht.
> > Daß ext3 etwas langsamer als ext2 ist, hatte ich noch in
> Erinnerung.
> > Daß das aber solche Erscheinungen gibt, war mir neu.
> > habe aber ext3 bisher nur selten in gebrauch.
>
> Wieso, er schreibt doch gar nicht, wie schnell ext2 ist?
[...]

War wohl meine Assoziation mit seinen Aussagen.
Immerhin erwähnte er, daß er ext3 nimmt, da vermutete ich,
es geht hier um spezielle ext3-Probleme.



[...]
> > > 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.
> > [...]
> >
> > Wäre mir neu, daß sich Mails in den Mbox_files ändern,
> > zumindest bei den empfangene n tun sie das ja eigentlich nicht.
>
> Die flags stehen doch mittendrin! Daher muss ja soviel kopiert
> werden,
> wenn eine Datei in der Mitte plötzlich ungelesen wird oder umgekehrt.

Ach so, das habe ich vollkommen übersehen.
Ist nämlich nicht RFC-irgendwas, sondern
<programm>-eigen.

Aber auch das kann man ja gezielt machen.
Wenn man bei einer mbox einen Index hat, wo die einzelnen
zu ändernden Daten liegen, dann kann man sie überschreiben,
sofern das Feld sich in der Länge nicht ändert.
Eine fixe Record-Länge wäre sinnvoll.

Über sowas denke ich eh schon eine Weile nach: Mailbox-Format
mit fixed record length. Ist eine Mail länger als die Record-Size,
nimmt sie halt mehrere Daten-Records in Anspruch.

Das wäre dann auch im Prinzip das selbe Format,
wie ein indexed-tar es nutzen könnte, oder zumindest ähnlich.



>
> Ich hab das früher benutzt, mein MUA läuft meist die ganze Zeit. Mit
> maildir läuft er `weiter' und sync ($ in mutt) ist schnell. Öffnen
> ist
> langsamer. Kommt halt drauf an, was man macht.

Bis jetzt hatte ich mit mbox und maildir keine großen Probleme.

Ist die Frage, ob sich extra-Aufwand für Normalmensch-Mailerei
lohnt. Und für nen Provider kann man dann ja mit Datenbanken
was machen. Und irgendwo dazwischen gibt es vielleicht ein paar
"Ich-habe-10GB-große-mbox-files"-user, die dann ein Problem haben. ;-)



>
> > Naja, in Ausgangsfoldern... aber die könnten auch in einem anderen
> > Format ableget sein. One Mail per mbox/File oder so.
>
> `One Mail per mbox/File' kommt maildir ja schon recht nahe.

Stimmt.
Ist aber was anderes, ob man die Mails vornehmlich als Archiv
nutzt: das ist es, wenn ich sage: man ändert die Mails ja nicht mehr,
oder wenn man da einen Drafts-Folder hat, an dem man die Texte editiert,
bevor sie abgesendet werden.
Solange die noch nicht gemailt wurden, sind es ja eigentlich noch keine
Mails, sondern nur Texte, die mal Mail werden wollen.
Die können also prinzipiell auch in einem ganz anderen Format abgelegt
werden.


>
> > > Aber das Hauptproblem an dem Ansatz ist: jetzt hast du nicht 1x
> > > sondern 2x Locking.
> >
> > Man könnte auch Locking über einen Locking-Index-/Table machen
> (dann
> > wäre es nur ein Locking), also man kann sich sicherlich vieles noch
> > ausdenken, wenn man sich sowieso vom ursprünglichen Konzept ein
> > Stückchen entfernt.
>
> Ja, das "noch ein Stückchen entfernt" ist ein guter Punkt. Sicherlich
> gibt es Anwendungsfälle, wo man mails in einer Datenbank verwalten
> sollte (wenn man komische Indecies braucht, vielleicht ein Teil der
> Message-ID oder so), da lässt sich sicherlich was /konstruieren/.
[...]

IMHO gibt es auch sowas bereits; aber ich weiss da keine
Programm-Namen. Aber sowas kann ja nicht all zu schwer zu bauen sein.


>
> Die Frage ist natürlich, was man machen will.

Die Frage stellt sich ja immer ;-)


[...]
> > > Hat auch den Vorteil, dass man join/split trivial ist (ideal für
> > > Archivierung). Sowas könnte man wirklich mal implementieren.
> > [...]
> >
> > Ja, über sowas habe ich letztens auch nachgedacht.
> > Statt sich also die Mühe zu machen und die zig verschiedenen
> > tar-Implementierungen für den Indexer zu reimplementieren
> > (zumindest das Lesen der Formate muss man ja können),
> > sollte man wohl lieber was neues entwickeln.
> > Dann kann man sich sein eigenes Format ausdenken.
>
> lol
>
> Weil es soviele Formate gibt, denkt man sich ein eigenes aus?
>
> Bitte nicht. :)
[...]

Doch, gerade dann! :)

Endlich mal eins, das den Anforderungen gerecht wird.

Ich dachte anfangs, es gibt zwei tar-Formate, aber
es sind fünf oder so.
POSIX-tar, GNU-tar (aklt), GNU-tar (neu),
USTAR, ein uraltes V7-tar, und ich glaube da war noch eins,
oder zwei?

Alle haben ihre eigenen Problemchen-.

Da blickt dann keine Sau mehr durch; da es keine
Versionskennzeichnung in den Files gibt,
weiss man auch nicht, was man parsen muss,
solange bis man merkt, daß das Format nicht stimmt. :(

Wenn man sich also für eines der Formate entscheidet,
bleibt man in dem Problemkreis.

Also ein neues entwerfen, welches die Vorzüge der anderen
vereinigt, die Nachteile bleiben lässt und ein paar andere
nützliche Eigenschaften hat.

Aber so Sachen, daß ein zu langer Filename die Längenfelder
überschreibt, die will man sich doch nicht wirklich ans Bein binden,
oder? Also was neues machen.
Vielleicht sollte man es auch nicht mehr "tar" nennen,
sonst klebt man noch an dem alten Zeugs, und man wird
von den tar-Traditionalisten geteert und gefedert. ;-)



>
> > Eine Fehlerkorrektur wäre vielleicht auch ganz sinnvoll.
>
> Gibt es sowas eigentlich? Was beispielsweise konfigurierbar Redundanz
> in
> Datenströme einfügt oder so?


rar/par/par2-Format machen das, aber
ich weiss nicht, ob das konfigurerbar ist
mit der extra-redundanz. Ich würde mal vermuten,
es ist festgelegt.

Gruß,
   Oliver