Danke, den Thread hatte ich noch nicht gefunden (den Wiki-Eintrag natürlich schon
). Also fasse ich mal zusammen:
- Maildir ist die sicherste Option, da mit Verlust einer Datei auch wirklich nur die Informationen der betreffenden Mail verloren gehen. Maildir ist aber auch die Variante mit dem größten I/O Load im laufenden Betrieb, da Dateien häufig umbenannt oder verschoben werden. Allerdings führt Dovecot auch hier Index-Dateien, was die Anzahl an readdir(3) Calls gegenüber anderen MUAs (wie z. B. Courier) deutlich reduziert. Bei Beschädigung können diese Index-Dateien problemlos aus den Maildir-Dateien wieder hergestellt werden.
- sdbox verringert die I/O Last im laufenden Betrieb, da die Datei, in der die Mail enthalten ist, nach der Ablage in einer Mailbox nicht mehr angefasst wird. Alle Flags werden in einer zentralen Index-Datei gespeichert (pro Mailbox); wird diese beschädigt, sind die Flags weg, der Mailinhalt selbst bleibt aber erhalten.
- mdbox verringert die operative I/O Last noch weiter, da die Gruppierung von Mails in Dateien die Packdichte erhöht und die Anzahl Dateien in einem Verzeichnis signifikant reduziert (bei entsprechender Rotate-Größe). In den zentralen Index-Dateien ist jetzt allerdings auch vermerkt, in welcher Datendatei eine Mail verpackt ist. Ist der Index futsch, kommt man auch an die Mails nicht mehr vernünftig ran. Außerdem ist das Format mit einem hohen temporären I/O Load verbunden - immer dann, wenn gepurged wird (per Cron) und so die Datendateien alle neu organisiert werden müssen. Außerdem löst ZFS das readdir-Problem auf ganz ähnliche Weise(1) wie mdbox - ob mdbox so gegenüber sdbox noch einen signifikanten Performance-Vorteil hat, wage ich daher zu bezweifeln.
Joe User wrote:Bezüglich der Backups: Da Du bereits ZFS einsetzt, drängt sich dessen Snapshot-Fähigkeit geradezu auf. Ist in wenigen Sekunden/Minuten erledigt und mitlerweile genauso (in)stabil wie das Filesystem selbst (zumindest meinem Hörensagen nach).
ZFS habe ich jetzt seit 6 Jahren produktiv (seit FreeBSD 8.0-rc1) im Einsatz, und mittlerweile ist es sehr stabil (eigentlich schon seit 8.1) und performant (seit 9.1 und 8.4). Die Snapshots sind wirklich schnell; das spielt sich eher im Millisekundenbereich ab. Trotzdem müssen die Daten vom Snapshot ja runtergekrazt und auf ein Remote System überspielt werden - sonst wäre das kein Backup, das den Namen auch verdient
. Das passiert natürlich mit geringer Priorität im Hintergrund, damit die eigentlichen Dienste unbehelligt weiterlaufen können, frisst aber ordentlich Zeit, da alle Dateien mindestens einmal mit
stat angefasst werden müssen (Vergleich mit vorhandenem Index - Dateiname, birthtime, ctime, mtime, im Zweifelsfall Bildung eines Hashwerts).
A propos Backup: hier unterscheiden sich die Formate wohl ebenfalls in der Handhabung, insbesondere wenn es um inkrementelle (oder differenzielle) Backups geht, was bei einem großen Mailspeicher durchaus sinnvoll ist:
- Maildir zwingt ein inkrementelles Backup, den Mailinhalt immer wieder zu sichern, auch wenn nur ein Flag verändert wurde. Außerdem müssen sehr viele Dateien abgeglichen werden, die oft innerhalb eines Verzeichnisses liegen, da keine automatische Partitionierung erfolgt. readdir(3) & Co arbeiten je nach Dateisystem mit einem Laufzeitverhalten von normalerweise O(log(n)) (bei ZFS dank Hashed Index sogar etwas besser, dafür platzt hier dann irgendwann der Cache und es kommt zu einer langsamen Aufräumaktion im Cache) - das bedeutet, es dauert (wenn auch nested directories das Problem nicht wirklich lösen)
- sdbox löst das readdir-Problem nicht, sorgt aber immerhin dafür, dass für Flag-Änderungen nur die Index-Datei, nicht aber der eigentliche Mailinhalt noch mal gesichert wird
- mdbox reduziert das readdir-Problem; je stärker dieses jedoch reduziert wird (größere Rotate-Size), desto wahrscheinlicher ist es, dass eine der Datendateien verändert wird (z. B. durch Löschoperationen) und so wieder mit in der inkrementellen Sicherung landet. Um ein inkrementelles Backup effektiv zu halten, müssten Algorithmen ähnlich wie bei rsync eingesetzt werden, um nur ein binäres "diff" einer Datei zu speichern, und nicht die komplette Datei. Das ist aber wieder recht teuer (die diff Operation kostet dabei tatsächlich am meisten(2)).
Bleibt noch ein Blick auf die Robustheit im Schadensfall:
- Der Tod einer Platte hätte überhaupt keine Auswirkung (dank ZFS mirror), egal bei welchem Format.
- Beim gleichzeitigen Tod beider Platten werde ich zwingend auf den Stand des letzten Backups zurückgeworfen, egal mit welchem Format. Selbiges gilt, wenn ZFS einen Totalcrash baut oder ich versehentlich das Dataset massakriere.
- Lediglich bei versehentlichem Löschen vereinzelter Dateien oder bei lokalem ZFS-Verkacken ist Maildir robuster als sdbox, das wiederum robuster ist als mdbox.
Joe User wrote:Ansonsten würde ich wohl mdbox wählen, wenn ich die Konsistenz der Indexfiles sicherstellen könnte.
Meine Bewertung:
- Performance
Die dbox-Formate müssten schneller sein als Maildir, da die Gesamtzahl an I/O Operationen geringer ist. Verglichen mit sdbox erwarte ich bei der Performance durch mdbox allerdings keinen signifikanten Gewinn, da ZFS das readdir-Problem auf dieselbe Weise löst wie mdbox (mit einer Hash Table). Außerdem saugt die erforderliche nächtliche Reorganisation der Storage-Dateien; diese müsste sehr sorgfältig mit den nächtlichen Backup-Jobs und PostgreSQL's Vacuum-Prozessen abgeglichen werden, um das System nicht sturmreif zu schießen.
- Backup
Beim Backup dürfte sdbox die Nase vorn haben, da Mail-Inhalte genau einmal ins Backup aufgenommen werden (besser als Maildir), und kein binäres Diff erforderlich ist (besser als mdbox).
- Robustheit
In dieser Kategorie ist Maildir Sieger. Allerdings lohnt es, bei einer Entscheidung zu betrachten, wie relevant die verschiedenen Ausfallszenarien für das eigene Setup sind
Meine Entscheidung:
Ich habe mich für sdbox entschieden. Meine Beweggründe:
- Ich setze ZFS ein. Unter dieser Voraussetzung scheint mir sdbox mit die beste Performance zu bieten.
- Beim Backup erhoffe ich mir eine Reduzierung des I/O Loads (vielleicht lassen sich die Indexdateien zur Bedarfsermittlung anzapfen) und eine geringere Anzahl zu sichernder Dateien im inkrementellen Modus.
- Der Schadensfall "nervöser Löschfinger" und "lokale Dateisystemkorruption" ist bei mir in den letzten 8 Jahren nicht vorgekommen, dafür aber insgesamt 6 tote Festplatten (in zwei Servern). Mein Backup ist dank Inkrement normalerweise schlimmstenfalls 12 Stunden alt - ein akzeptables Verlustrisiko, betrachte ich die bei mir gegebene Eintrittswahrscheinlichkeit...
Wichtig: Diese Entscheidung basiert auf meinem Setup (ZFS, kein NSF, keine Replikation), meiner eigenen Erfahrung als Admin und Programmierer, sowie den hier zusammengetragenen Informationen. Zur Theorie gibt es viele Quellen (einige habe ich verlinkt, anderes ist Informatik-Wissen, das man sich aus Büchern wie Owsnicki-Klewe's "Algorithmen und Datenstrukturen" anlesen kann oder das man erwirbt, wenn man sich selbst mit systemnaher Programmierung befasst). Praktische Erfahrung mit sdbox habe ich aber bisher nicht gemacht, und echte Erfahrungsberichte sind rar (selbst Timo, Autor von Dovecot betont immer wieder, dass ihm keine Fallstudien aus dem Real Life vorliegen, die eine Migration von Maildir auf dbox tatsächlich vergleichbar darstellen).
Meine Entscheidung darf daher nicht als allgemein gültige Empfehlung aufgefasst werden. Ich hoffe aber, dass die ein oder andere Überlegung, der ein oder andere Link dabei hilft, in die Thematik einzusteigen, wenn jemand für ein anderes Setup diese Entscheidung treffen muss.
(1) ZFS nutzt intern Adelson-Velski-Landis Bäume (AVL), und deren Suchverhalten ist konstant O(log n) - siehe
http://www.open-zfs.org/wiki/Publications (speziell:
http://open-zfs.org/w/images/3/31/Perfo ... Wilson.pdf), sowie
https://de.wikipedia.org/wiki/AVL-Baum
(2) Herausgefunden durch eigene Erfahrungen, siehe
https://github.com/daemotron/libsynctory, insbesondere
https://github.com/daemotron/libsynctory/issues/13 sowie
https://github.com/daemotron/libsynctor ... 4e0d5e80fe
