[linux-l] Wohin mit den alten Mails? -> +sent

olafBuddenhagen at gmx.net olafBuddenhagen at gmx.net
Sa Feb 17 03:06:13 CET 2007


Hallo,

On Fri, Feb 16, 2007 at 02:20:47AM +0100, Oliver Bandel wrote:

> On Thu, Feb 15, 2007 at 08:56:56AM +0100, olafBuddenhagen at gmx.net
> wrote:

> > Das scheint mir erstens sehr unzuverlässig, und zweitens sehe ich
> > dabei keinen Vorteil gegenüber der Eingabe von Schlüsselwörtern erst
> > bei der eigentlichen Suche...
> 
> Eingabe von Schlüsselwörtern bei der Suche? Du meinst also eine
> Volltextsuche?
> 
> Naja, je nach Datenbestand, oder ob de Originaldaten vorliegen oder
> nicht, ist das  ja nicht unbedingt möglich.
> 
> Keywords, vorher raus gepickt, sind wie ein Inhaltseverzeichnis. Das
> kann man sich separat legen. hat man es nicht, muß man den gesamten
> Datenbestand absuchen.

Schon klar, dass ein Index bei einer Volltextsuche behilflich sein kann.
Das ist aber IMHO vollkommen orthogonal zum Tagging.

> > Was man hingegen machen könnte, wäre über Textähnlichkeitsanalyse
> > (Bayes oder so) automatisch Tags zu vergeben, statt oder ergänzend
> > zu den festen Regeln.
> 
> 
> Bayes ist zwar wohl ganz nett, aber eigentlich "veraltet". Schon seit
> (mindestens) Ende des letzten Jahrtausends, wenn man es genau nimmt.
> Das sind ja auch schon 8 bis 10 Jahre.
> 
> Und so lange schon rede ich gegen Wände. Aber was solls.

Ich finde Bayes auch ziemlich primitiv, aber es scheint halt für Vieles
gut genug zu sein.

Wie auch immer: Wenn Du ein besseres Tool kennst, um Mails anhalt ihres
Inhalts automatisch zu bereits vorhandenen Kategorien zuzuordnen -- nur
her damit :-)

> > Unter Hurd könne man das zwar abmildern, indem man mit einem
> > Translator die Daten transparent als Verzeichnisstruktur darstellt,
> 
> Was meinst Du? Was soll dieser Translator sein?

   http://google.com/search?q=hurd+translator

:-P

Grob gesagt sind Hurd-Translator einfach nur Dateisystem-Server, d.h.
Prozesse, die einen Teilabschnitt der Verzeichnisbaums implementieren.

Einen Translator könne man beispielsweise benutzen, um Mails, die in
einen DB-Backend abgelegt sind, alsrklassische Dateistruktur (also
maildir oder sowas) darzustellen.

> > (Mit neueren Linux-Versionen könnte das dank FUSE vielleicht auch
> > gehen; weiß nicht wie gut das für sowas geeignet ist...)
> 
> FUSE?

   http://google.com/search?q=linux+fuse

:-P

Heißt "Filesystem in Userspace" -- der Name sagt eigentlich schon alles.
Funktioniert zwar technisch ganz anders als Hurd-Translator, und ist
daher wesentlich beschränkter, aber für Sachen wie ftpfs oder gphotofs
reicht es. Vielleicht wäre es auch für ein mailfs geeignet...

> > Besser wäre es aber, wenn das eigentliche Dateisystem von sich aus
> > mit komplexen Verzeichnisstrukturen effizienter umgehen könnte. Ich
> > denke der Weg mit maildir ist prinzipiell schon richtig; ist nur
> > eben sehr ineffizient bei klassischen Dateisystemen :-(
> 
> Naja, was soll Maildir im Vergleich zur mbox denn bezüglich Recherche
> verbessern?

Es geht um das Problem, dass mbox extrem ineffizient wird, wenn man alle
Mails in einem einzigen riesigen Ordner lässt, und nur noch anhand von
Tags in verschiedene Ansichten filtert: Beim Öffnen der Mailbox muss der
gesammte Inhalt durchgegangen werden; und bei Veränderungen muss auch
der gesammte dahinterliegende Teil der Mailbox neu geschrieben werden.

Maildir hilft hier teilweise, weil jede Mail in einer eigenen Datei
abgelegt ist, so dass man nicht alles lesen/schreiben muss. Dafür muss
man sehr viele Einzeldateien öffnen, was bei traditionellen
Dateisystemen sehr langsam ist. (Wobei Header-Caching das wohl
abmildert; weiß halt nicht wie gut das in der Praxis funktioniert.) Und
die vielen kleinen Dateien belegen auch wesentlich mehr Platz auf der
Platte. (Bei Dateisystem mit Tail-Merging nicht ganz so schlimm, aber
die haben wiederum andere Nachteile...)

Bei einem Dateisystem, das von sich aus effizient mit vielen kleinen
Einzeldateien umgehen kann, hätte man solche Probleme nicht -- mit
maildir wäre das ideal.

-Olaf-



Mehr Informationen über die Mailingliste linux-l