[linux-l] mbox/Maildir/tar

[Oliver Bandel]

Zitat von Rocco Rutte <pdmef at gmx.net>:

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

OK, ja, das macht Sinn.

...jedenfalls, wenn die Einträge korrekt sind.



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


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


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.



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


...wahrlich!


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


hmhhhh... ich kenne den genauen Aufbau von ext3 nicht im Detail.
Ich dachte durch Baumstruktur wäre das trotz Journalling noch recht
schnell... hmhhh was meintest Du mit den Listen in Deiner Aussage da
oben? hmhh, muss mir das ext3-Format wohl mal anschauen.

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

Wäre mir neu, daß sich Mails in den Mbox_files ändern,
zumindest bei den empfangene n tun sie das ja eigentlich nicht.
Naja, in Ausgangsfoldern... aber die könnten auch in einem
anderen Format ableget sein. One Mail per mbox/File oder so.


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

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.



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

Man könnte ja nen Index haben, in dem auch einige Infos der Header
abgelegt sind. Aber das will ich jetzt nicht noch mal neu
durch diskutieren; das macht IMHO erst Sinn, wenn man sowas
implementieren will.


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

Wenn man Dateiweise packt hat das den nachteil,
daß man beim Packen möglicherweise nicht so gute
Kompressionsraten hat.
Dann kann man ja gleich zip und seine Ableger nehmen.


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

Statt dem in dem Artikel vorgeschlagenen "kommt statt EOF noch was,
dann ist es der nächste Header" könnte man auch konstante
Abstände von header- zu Header vorgeben (also
Konstante Blocklänge der Daten). Dann könnte man anhand
der Gesamtlänge, die im ersten header steht, wenn man die mit der
Dateilänge vergleicht, sehen, ob da vom Archiv hinten was
"abgebrochen" ist ;-)

Eine Fehlerkorrektur wäre vielleicht auch ganz sinnvoll.

Gruß,
   Oliver