[linux-l] mbox/Maildir/tar

[Steffen Dettmer]

* 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. Finde ich sinnvoll, wenn man z.B.
flash `readonly' benutzt (auch wenn rw gemounted) oder Backups mounted /
flashed / auf DVD RAM hat.

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

Ich würde erwarten, ext2 ist genauso schnell wie ext3 ohne dir_index.
Mit dir_index ist (hier) ext3 sicherlich schneller.

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

300k files ist echt nicht schlecht... Mein Serverbackup hat 150k files,
wenn ich mich Recht entsinne. Da versagen schon Programme (z.B.  k3b
brennt sowas nicht). Mails mach ich aber extra, ich glaub neue Sets im
alten Archiv erzeuge ich aus 10-100MB maildirs und dann maildir weises
tar (oder so ähnlich, macht ja ein Script).

Bei solchen Grössenordnungen sollte man meiner Meinung nach nicht mehr
erwarten, dass defaults passen. Ich kann mir z.B. nicht vorstellen, dass
eine GUI gut damit klarkommt, wenn z.b: 10k oder mehr files in einem
Directory sind etc.

Mit unix Bordmitteln kann man sich aber für 600k  ja schon was basteln,
nur mit win ist sowas schwierig (und KDE etc, klar). Vielleicht ist der
Kram darunter auch immer so komisch optimiert? Als Kompromiss?

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

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.

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

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

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

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

Gibt es, sowas nutzen die IMAP Server, soweit ich weiss. Funktioniert
meines Wissens nach nur richtig gut, wenn lokale Prozesse unter
bestimmten Regeln darauf zugreifen. Umständlich zu benutzen. Das kann
man meiner Meinung nach eher als eine einfache Datenbank sehen. Wenn man
nicht von mehreren Hosts via NFS drauf zugreift, funktioniert das
sicherlich auch stabil.

Auch Outlook macht was ziemlich komplexes mit Mails. Funktioniert aber
wohl nicht so gut, ich kenne Beispiele von Datenverlust.

> Dann kann man ja gleich zip und seine Ableger nehmen.

(hätte ich mal lesen sollen, bevor ich das auch nochmal wiederholt hab
:))

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

> Eine Fehlerkorrektur wäre vielleicht auch ganz sinnvoll.

Gibt es sowas eigentlich? Was beispielsweise konfigurierbar Redundanz in
Datenströme einfügt oder so?

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.