Dateisystem für Mails

[Colttt]

Hallo,

unser mailserver hat noch ein ext3 am laufen wo ein fsck schonmal gute 2h dauern kann(440GB ca 6mio Mails), jetzt wollen wir wechseln. Da stellt sich mir die Frage wohin.. btrfs ist mir noch zu unsicher/instabil.. bleiben eigentlich fast nur noch der "quasi"-standard ext4 oder xfs.. aber als ich folgendes las: https://www.heinlein-support.de/sites/d ... ance_0.pdf dann doch nur noch ext4 oder wie seht ihr das? Was würdet ihr empfehlen als Mail-Dateisystem?

Vielen Dank vorab!

[schorsch_76]

Wenn dir ein stabiles Filesystem wichtig ist, interessiert dich vielleicht auch das hier:

http://events.linuxfoundation.org/sites ... 2016_0.pdf

Tip: ext4 scheint wohl am stabilsten zu sein

[Colttt]

War das jetzt ironisch gemeint? Weil Bug nach 5s gefunden und bei xfs hats 1:45h gedauert..

Hat evtl noch jmd Erfahrungswerte?

[NAB]

Weil Bug nach 5s gefunden

Hmm? Astigmatismus?

[Colttt]

Ok das Wort kenn ich nicht und Google sagt Hornhautverkrümmung.. ehm was hat das damit zu tun?

[NAB]

Oh, verzeihung, das war zu knapp von mir ...

Schau dir die Tabelle noch mal an. Du hast wohl schief geguckt

[schorsch_76]

War das jetzt ironisch gemeint?

Nein, das war nicht ironisch gemeint.

[heisenberg]

Ich kann mich jetzt nur an 1 Server erinnern, der mit ext3 immer 1 Stunde im FS-check hing. Nach der Umstellung auf ext4 habe ich nicht mehr gemerkt, dass da überhaupt noch ein Plattencheck stattfand.(VM mit 1 TB HDD)

[wanne]

Sinnvoller weise optimiert man beim Dateiformat. Ansonsten ist bei maildir ext4 mir einem riesen abstand das performanteste.
Ich bin ein großer fan von btrfs aber wenn es um performance geht, hast du da keine chance.
ext3 ist btw. auch nur ein ext4. Du kannst einen fließenden Umstieg machen, indem du einfach ext4 statt ext3 in die fstab schreibst.
Dann nutzen neu angelegte Dateien gleich viele Vorteile von ext4.

[MSfree]

unser mailserver hat noch ein ext3 am laufen wo ein fsck schonmal gute 2h dauern kann

Da ist aber etwas grundsätzlich faul. ext3 (wie ext4) ist ein journaling Dateisystem, das nach einem Crash in sekundenschnelle wieder da sein sollte.

Eine Ursache könnte sein, daß das ext3-Dateisystem ohne Journal angelegt wurde, das kann man aber nachholen.

Eventuell wird auch ein voller Dateisystemcheck durchgeführt, weil Mountcount oder Mountintervall erreicht wurden. Beide Kriterien sind meiner Meinung nach überflüssig und können via tune2fs abgeschaltet werden.

[Colttt]

ext3 ist btw. auch nur ein ext4. Du kannst einen fließenden Umstieg machen, indem du einfach ext4 statt ext3 in die fstab schreibst.

schon erledigt, trotzdem dauert der fsck ewig weil es ja aktuell viele alte daten sind..

Schau dir die Tabelle noch mal an. Du hast wohl schief geguckt

ohh ich sehe ext4 hat 2h gebraucht.. aber ist Bug nicht schwerwiegender als soft lockup?

Nein, das war nicht ironisch gemeint.

ok also bei einem reinen ext4 bleiben scheint dann wohl das beste zu sein?! dann nur so aus neugier, warum nimmt RedHat xfs als standard wenn ext4 besser ist?

Eventuell wird auch ein voller Dateisystemcheck durchgeführt, weil Mountcount oder Mountintervall erreicht wurden. Beide Kriterien sind meiner Meinung nach überflüssig und können via tune2fs abgeschaltet werden.

jup genau das ist der fall.. und überflüssig wüýde ich jetzt nicht sagen hat uns vor 1-2 wochen erst gerettet, da wurde das dateisystem als readonly gemountet weil es dort fehler gab und fsck die wieder ganz gemacht hat

[MSfree]

jup genau das ist der fall.. und überflüssig wüýde ich jetzt nicht sagen hat uns vor 1-2 wochen erst gerettet, da wurde das dateisystem als readonly gemountet weil es dort fehler gab und fsck die wieder ganz gemacht hat

Wenn das Dateisystem read-only gemountet wurde, dann, weil es als dirty markiert war und nicht, weil Mountcount oder Mountintervall erreicht waren. Die Kiste ist also unsauber runtergefahren.

Ein sauberers Shutdown setzt das Clean-Flag im Dateisystem, so daß es beim nächsten Boot nicht gecheckt werden muß. Ist trotz des Clean-Flags Mountcount bzw. Mountintervall erreicht, wird dennoch gecheckt. Das ist meiner Meinung nach einfach überflüssig.

[heisenberg]

ext3 ist btw. auch nur ein ext4. Du kannst einen fließenden Umstieg machen, indem du einfach ext4 statt ext3 in die fstab schreibst.
Dann nutzen neu angelegte Dateien gleich viele Vorteile von ext4.

Vor der Entscheidung stand ich auch irgendwann - und rein intuitiv habe ich mich entschieden, lieber das FS komplett neu zu erstellen und alle Daten dort hinein zu kopieren, damit alle Features komplett aktiv waren ohne mich mit irgendwelchen Details rumschlagen zu müssen. "Oh da muss jetzt auf allen Dateien noch dies oder jenes Kommando ausgeführt werden."

Da ist aber etwas grundsätzlich faul. ext3 (wie ext4) ist ein journaling Dateisystem, das nach einem Crash in sekundenschnelle wieder da sein sollte.

Das habe ich mir bei meinem ext3-System damals auch gedacht. Trotzdem hat es ewig gedauert. Wobei jedoch bei mir das FS jedes mal definitiv "dirty" war(Server war instabil).

[catdog2]

schon erledigt, trotzdem dauert der fsck ewig weil es ja aktuell viele alte daten sind..

Einfach mit ext4 mounten ändert auch nix. Du musst explizit die ext4 Features mit tune2fs setzen und den entsprechenden e2fsck Befehl ausführen. --> https://ext4.wiki.kernel.org/index.php/UpgradeToExt4

[NAB]

ohh ich sehe ext4 hat 2h gebraucht.. aber ist Bug nicht schwerwiegender als soft lockup?

Das würde ich auch vermuten, aber so richtig gut erklären sie das nicht. Und die streuen ja absichtlich wirre Fehler in den Programmcode ein. Wie auch immer, Ext4 und XFS scheinen an der Spitze zu liegen, was Stabilität angeht.

Die spannende Frage wäre nun, welches mit deinen 6 Mio Dateien fixer ist.

Ach, mal über ne SSD nachgedacht? Eventuell im Raid1 mit einer HDD? Macht natürlich nur Sinn, wenn die CPU beim fsck nicht auf 100% steht.

[hec_tech]

Wie wäre es wenn man auf (m)dbox wechselt? Du hast ja eh den Link von heinlein gepostet.

Damit brauchst du auch wesentlich weniger IOPs für Mailzugriff und außerdem hast du weniger Files. Das führt auch wieder zu schnelleren checks.

Denk aber auch an Backups also brauchst du etwas mit dem du Snapshots erzeugen kannst anders kannst du mdbox nicht sichern.

lg
Gregor

[wanne]

Die spannende Frage wäre nun, welches mit deinen 6 Mio Dateien fixer ist.

Definitiv ext4.
XFS hat minimale performancevorsprünge bei extrem großen Partitionen mit großen Dateien.

[heisenberg]

Also maildir ist in der Handhabung bei abermillionen Dateien hässlich. Soweit volle Zustimmung.

(m)dbox aber ist da eher hinsichtlich Backup etwas hässlich. Sehr grosse Dateien, die sich grundsätzlich immer ändern, am besten noch in einem Binärformat, das man nicht diffen kann.

Hinsichtlich Backupfreundlichkeit würde ich mir da ein Format wünschen, das sich kontinuierlich um handhabbare Dateigrössen erweitert. Also vielleicht so in der Grösse von jeweils 50 / 100 / 200 / 500 MB. Dazu noch eine Indexdatei, in der Mails markiert werden, z. B. als gelöscht. Volle Datendateien werden grundsätzlich gar nicht mehr automatisch angefasst, so dass diese immer exakt so wie sie sind im Backup landen(oder auch nicht, weil sie da schon sind). Die bisher geschriebenen Datendateien können gelegentlich mal neu erstellt werden, wobei alle gelöschten Mails bei diesem Vorgang verworfen werden. Diesen Rebuild könnte man regelmässig einmal im Monat zu geringen Lastzeiten durchführen.

[Colttt]

Ich glaube da wäre sdbox deine Wahl. Hier hat mal jmd dazu was zusammen gefasst: https://www.rootforum.org/forum/viewtopic.php?t=54663

[wanne]

Du solltest dir vielleicht auch mal btrfs angucken. Das kann inkrementelle backups und das eben auch auf Binärdateien. Performant ist das nicht, aber die backups bleiben wunderbar einfach – Egal welches Dateiformat du nutzt.

[Dimejo]

Also maildir ist in der Handhabung bei abermillionen Dateien hässlich. Soweit volle Zustimmung.

Maildir hat ab einer bestimmten Größe Schwächen, da habt ihr Recht. Aber ein paar Millionen Mails sollten kein Problem sein. Zumindest wenn die Hardware nicht nur aus 5.4k SATA-Platten besteht.

(m)dbox aber ist da eher hinsichtlich Backup etwas hässlich. Sehr grosse Dateien, die sich grundsätzlich immer ändern, am besten noch in einem Binärformat, das man nicht diffen kann.

Hinsichtlich Backupfreundlichkeit würde ich mir da ein Format wünschen, das sich kontinuierlich um handhabbare Dateigrössen erweitert. Also vielleicht so in der Grösse von jeweils 50 / 100 / 200 / 500 MB. Dazu noch eine Indexdatei, in der Mails markiert werden, z. B. als gelöscht. Volle Datendateien werden grundsätzlich gar nicht mehr automatisch angefasst, so dass diese immer exakt so wie sie sind im Backup landen(oder auch nicht, weil sie da schon sind). Die bisher geschriebenen Datendateien können gelegentlich mal neu erstellt werden, wobei alle gelöschten Mails bei diesem Vorgang verworfen werden. Diesen Rebuild könnte man regelmässig einmal im Monat zu geringen Lastzeiten durchführen.

Kann es sein, dass Du mbox und mdbox (multiple-dbox) verwechselst?

mbox ist ein sehr altes Format, und verwendet eine Datei pro Postfach/Ordner. Entsprechend groß werden diese Dateien dann auch.
mdbox ist eine Entwicklung von Dovecot, und unterteilt ein Postfach in mehrere kleine Dateien (Größe einstellbar).

Du solltest dir vielleicht auch mal btrfs angucken. Das kann inkrementelle backups und das eben auch auf Binärdateien. Performant ist das nicht, aber die backups bleiben wunderbar einfach – Egal welches Dateiformat du nutzt.

Dem TE war BTRFS zu experimentell und instabil. Dieser Meinung kann ich mich auch nur anschließen. Vor allem dann, wenn als Format sdbox/mdbox eingesetzt wird, das auf eine fehlerfreie Index-Datei angewiesen ist.

Zurück zum eigentlichen Thema:
Die Frage ob XFS oder ext4 ist wohl eher eine Geschmacksfrage, der Performanceunterschied dürfte auf diesem System wahrscheinlich nicht spürbar sein. Ich persönlich verwende fast immer ext4, da es einfach ein gutes Allround-Dateisystem ist, mit dem man nichts falsch machen kann. Gegenüber XFS hat es auch den Vorteil, dass man das Dateisystem im Notfall verkleinern kann. Das hat sich bereits ein paar Mal als nützlich erwiesen.

In jedem Fall kann mich sich bei beiden Dateisystemen den Einsatz von noatime überlegen. Das bringt immer ein wenig mehr Performance.