Frage: Welches FS für Millionen kleiner Dateien

[tbol]

Hallo liebe Gemeinde,

Welches FS eignet sich am besten zum ablegen von Millionen kleiner Files?

Im Speziellen geht es um Mails. Diese sind im Durchschnitt 0,5-2k groß.



Bei z.B.: NTFS wird per default eine Blocksize von 4k vorgegeben.


Habt ihr einen Vorschlag?


Grüße,

tbol

 

[Opticum]

dafür eignet sich eine Datenbank, kein Filesystem.

 

[P4LL3R]

Theoretisch würde es mit NTFS eh gehen, da do dort ca. 4 Milliarden Files in einen Ordner ablegen kannst. Es wird arschlangsam, aber es geht.

 

[Morpheus2200]

ReiserFS ist eigentlich genau für den Fall gedacht

 

[VirtuGuy]

NTFS ist dafür eher schlecht zu gebrauchen, auf Windows Basis würde ich hierzu gleich ReFS verwenden. Die Performance bei vielen Dateien ist deutlich besser, zudem kann man 2^64 Dateien speichern (NTFS => 2^32).

 

[gea]

Das Ziel ist nicht das schnellste Dateisystem sondern eines das möglichst sicher ist und möglichst viel Last vom Dateisystem fernhält.

Mit ausreichend RAM (32 GB - 256GB)) als Readcache ist ZFS wohl die sicherste und schnellste Option zumal ZFS auch beim Schreiben vieler kleiner Dateien durch den bis 4GB großen Schreibcache nicht einbricht.

Dateianzahl, Dateigröße und Poolgröße ist bei einem 128bit Dateisystem eh kein Limit mehr.
Man sollte aber unbedingt ein Logdevice mit Powerloss Protection haben, z.B. Intel DC 3700 oder eine NVMe.

Blocksize bei ZFS ist per default 128k, würde ich in dem Fall kleiner machen z.B. 32k.
Duch die Wandlung vieler kleiner Random Writes in ein großes sequentielles Write ist das aber nicht ganz kritisch. Beim Lesen geht dann eh fast alles aus dem RAM Readcache oder einem eventuellen SSD/NVMe L2Arc Lesecache.

 

[Holt]

Datenbanken wäre dafür denkbar ungünstig, bei Oracle würden mindestens 8k pro Blob drauf gehen, außerdem sind die eher nicht für die Aufnahme unstrukturierter Daten geeignet. Wäre nicht btrfs genau wegen der B-Trees für solche Fälle optimal? NTFS wird ja sehr lahm, wenn es sehr viele Dateien oder Unterverzeichnisse in einem Verzeichnis gibt.

Und die 4k pro Cluster wird man kaum kommen und bei halbwegs aktuellen HDDs mit 4k physikalischer Sektorgröße ist das auch nicht sinnvoll, ebensowenig bei SSDs, da auch diese auf 4k Zugriffe optimiert sind.

 

[Nemac]

Was ist denn der Hintergrund dazu?
Die ganzen Mails zb in eine *.PST kippen geht nicht? Wäre dann mit Outlook lesbar

 

[KurzGedacht]

Du willst mehrere Millionen Mails in einer pst Verwalten? Das Outlook das das packt muss erst noch erfunden werden. Outlook wird doch schon bei um die 20 GB quasi unbenutzbar.

Würde zfs oder eventuell auch einfach ext4 mit möglichst geringer Block size nutzen.

 

[Trambahner]

Wenn es nur um Textemails geht, braucht man ja nicht wirklich BLOBs bei Oracle. Bis knapp 4kb könnte man mit Varchar2(4000) bzw. Nvarchar2(4000) für UTF durchaus arbeiten, 12c kann ja sogar bis Varchar2(32767) verwenden.
Dann eine PLSQL-Prozedur, die versucht bestimmte Textelemente wie Header-Infos oder typische Suchbegriffe auszulesen und in eine 2. Table schreibt. Damit ließe sich dann auch indizieren.

 

[martingo]

Sprechen wir von einem stinknormalen Mailserver? So wahnsinnig viel finde ich "Millionen von Mails" eigentlich nicht.

Und was genau ist das Problem? Hast Du aktuell Performance Probleme? Oder geht es Dir um "den verschwendeten Speicherplatz"? Oder was ist Dein Anliegen?

 

[iagm]

Das klingt für mich irgendwie nach nem Mail-Server, der Maildir zum speichern der Mails verwendet. Courier oder so.

 

[Rahvin]

Für Unix-Dateisysteme auch über die Mount-Option "noatime" nachdenken - das kann die Zugriffe auf sehr viele kleine Dateien deutlich beschleunigen, da dann keine Informationen mehr gespeichert werden wann die Datei das letze mal geöffnet wurde.

Rahvin

 

[Trambahner]

Entsprechend bei ZFS. (#zfs set atime=off pool|dataset)

 

[tbol]

Was ist denn der Hintergrund dazu?
Die ganzen Mails zb in eine *.PST kippen geht nicht? Wäre dann mit Outlook lesbar

Der Hintergrund dazu ist folgender:

Wir haben eine Mail-Archive-Appliance, die das Backup der Mails per CIFS-Share auf einem NetApp-System ablegt. Das Problem ist, dass mir inodes ausgehen und auf Grund der 4K Blocksize teilweise bis zu 50% Speicherplatz verloren gehen. Da die Appliance von Haus aus verschlüsselt bringen mir die Dedup & Compression Features des Filers nichts und dabei ist die Appliance schon so klug um Mail-Duplikate zu erkennen und Anhänge auch nur einmal vorzuhalten. Dazu noch eine mehr oder weniger sinvolle Richtlinie, dass archivierte Mails für immer aufgehoben werden sollen (bitte nicht hauen, ich mag das selber nicht) und schwupps ist das Desaster komplett.

Glücklich bin ich damit nicht. Gibt es denn eine Möglichkeit (zb ein FS mit geringer blocksize) viele kleine Dateien abzulegen ohne zu verschwenden?

 

[P4LL3R]

Seit Ontap 9.1 gibt es ja eine Inline-Compaction, die die Blöcke solange sammelt, bis ein 4K-Block voll ist. Vielleicht hilft das ja.

 

[tbol]

Seit Ontap 9.1 gibt es ja eine Inline-Compaction, die die Blöcke solange sammelt, bis ein 4K-Block voll ist. Vielleicht hilft das ja.

Schon im Fokus, fahren aber im Moment noch 7-Mode Systeme... da ist bei 8.2 Schluss

 

[Elioth]

Hallo tbol, in einer Hinsicht stehe ich momentan auf dem SchLauch - wenn Ihr die Dateien per Cifs auf dem Netapp ablegt, ist das Filesystem am Storage doch durch die Netapp vorbestimmt, oder? Für ein eigenes Filesystem aus der Appliance heraus (so diese denn selbst was sinnvolleres beherrscht) benötigst Du Storagezugriff auf Blockebene (iScsi) würde ich behaupten.
Generell wäre für so kleine Dateien ein DB-System eventuell effektiver als Ablageziel. Welche Storage-Optionen bietet das Appliance außer CIFS denn noch?

Ansonsten im Linuxoiden Umfeld sinds die üblichen Verdächtigen, wenn an die Dateien keine Appends erfolgen - bei Backup Ablage unwahrscheinlich . Also Reiser oder XFS. Haben jedoch auch alle ihre Kehrseiten. Zu kleine Blockgrößen optimieren dann aber zwar die Speichernutzung, der Speed wird dennoch lahmer. Eventuell kannst Du die Appliance noch dazu überreden, die Logs in einem File-Container vor dem Ablegen zu sammeln oder sie anderweitig packen. Mini-Dateinen erscheinen mir eh nicht so die prickelnde Ablageform. Einer der Gründe, weshalb auch Logfiles oft eher appenden, als dedizierte Einzelablage machen.

 

[P4LL3R]

Netapp unterstützt CIFS, NFS und iSCSI.
Als Dateisystem hat Netapp WAFL, das nur 4K-Blöcke speichern kann. Wenn man was anderes haben möchte, muss man, wie du bereits sagtest, eine iSCSI LUN am Server einbinden und diese entsprechend formatieren.

Gesendet von meinem SM-G928F mit Tapatalk

 

[gea]

Mir ist jetzt immer noch nicht klar, was optimiert werden soll

1. Tatsächlicher minimaler Platzverbrauch auf der Platte
Hier würde ich die "physical sectorsize" als Kriterium sehen.

Bei 512B Platten sind das 512Byte, bei aktuellen 4k Platten eben 4Kbyte.
Aktuelle große PLatten sind aber alle 4k weil man dann weniger Blöcke je Datei verwalten muss und das schneller ist (weniger random io). Ich sehe das aber nicht als Problem. Selbst bei einer Million kleiner 1K Dateien, bei denen man je 3Kilobyte "verschwendet würde " ergeben lediglich 6 Gbyte "Verschnitt. Bei Terabyte Platten unerheblich. Problematischer ist das nur wenn der Verschnitte je Raid-Stripe anfällt. Dann kann das schon im einstelligen Prozentbereich liegen.

2. "Logische Blocksize", Clustersize etc des Dateisystems. Das ist entweder fest z.B. 8k oder wie z.B. bei ZFS dynamisch bis 1Mbyte. Eine Datei wird dann in derartige Blöcke aufgeteilt, der Rest dann dynamisch in kleinere. Bei vielen kleinen Dateien und parallelem Zugriff wird das schneller wenn man die nicht zu groß wählt. Besonders kleine Werten sind aber von der allgemeinen Performance auch nicht optimal (viel random io). Im Falle ZFS würd ich da 32k statt der default 128k nehmen.

3. Performance
Beim Lesen/Schreiben sehr kleiner Dateien/ Cluster/ physikalischer Blöcke bricht die Performance generell sehr stark ein. Das lässt sich vom Dateisystem oder der Platte schlecht optimieren. Die Lösung heisst da massive Schreibcaches, bei ZFS z.B. bis zu 4GB damit eben immer große sequentielle Writes statt kleiner random writes anfallen. Beim Lesen ist es genauso. Wenn z.B. ein 64GB RAM Lesecache vorhanden ist werden fast alle Reads kleiner Dateien/ Blöcke/ Metadaten aus dem RAM bedient.

Bei ZFS ist das so und bei dem dazu sehr ähnlichen WAFL sollte es ähnlich sein. Sicherheit (CopyOnWrite. Prüfsummen, Snaps) wäre mir sowieso das wichtigere Kriterium. Un da sind sich WAFL und ZFS ähnlich.

 

[tbol]

Mir ist jetzt immer noch nicht klar, was optimiert werden soll

1. Tatsächlicher minimaler Platzverbrauch auf der Platte
Hier würde ich die "physical sectorsize" als Kriterium sehen.

Bei 512B Platten sind das 512Byte, bei aktuellen 4k Platten eben 4Kbyte.
Aktuelle große PLatten sind aber alle 4k weil man dann weniger Blöcke je Datei verwalten muss und das schneller ist (weniger random io). Ich sehe das aber nicht als Problem. Selbst bei einer Million kleiner 1K Dateien, bei denen man je 3Kilobyte "verschwendet würde " ergeben lediglich 6 Gbyte "Verschnitt. Bei Terabyte Platten unerheblich. Problematischer ist das nur wenn der Verschnitte je Raid-Stripe anfällt. Dann kann das schon im einstelligen Prozentbereich liegen.

Ja, das ist vollkommen richtig. Ich hatte mal rund 20 GiB Verschnitt ausgerechnet. Vielleicht nicht so der Rede wert, aber Verschnitt bleibt Verschnitt Hätte ja sein können, dass es ein FS gibt, dass mir dieses Problem bestmöglichst löst.

2. "Logische Blocksize", Clustersize etc des Dateisystems. Das ist entweder fest z.B. 8k oder wie z.B. bei ZFS dynamisch bis 1Mbyte. Eine Datei wird dann in derartige Blöcke aufgeteilt, der Rest dann dynamisch in kleinere. Bei vielen kleinen Dateien und parallelem Zugriff wird das schneller wenn man die nicht zu groß wählt. Besonders kleine Werten sind aber von der allgemeinen Performance auch nicht optimal (viel random io). Im Falle ZFS würd ich da 32k statt der default 128k nehmen.

Danke für den Hinweis.

3. Performance
Beim Lesen/Schreiben sehr kleiner Dateien/ Cluster/ physikalischer Blöcke bricht die Performance generell sehr stark ein. Das lässt sich vom Dateisystem oder der Platte schlecht optimieren. Die Lösung heisst da massive Schreibcaches, bei ZFS z.B. bis zu 4GB damit eben immer große sequentielle Writes statt kleiner random writes anfallen. Beim Lesen ist es genauso. Wenn z.B. ein 64GB RAM Lesecache vorhanden ist werden fast alle Reads kleiner Dateien/ Blöcke/ Metadaten aus dem RAM bedient.

Bei ZFS ist das so und bei dem dazu sehr ähnlichen WAFL sollte es ähnlich sein. Sicherheit (CopyOnWrite. Prüfsummen, Snaps) wäre mir sowieso das wichtigere Kriterium. Un da sind sich WAFL und ZFS ähnlich.

Das sehe ich ebenso. Mir ist Datenintegrität auch wichtiger als paar mehr GB Platz.

 

[passat3233]

Die Blockgröße von NTFS spielt bei so kleinen Dateien so gut wie keine Rolle!
Dateien bis ca. 1kb Größe werden bei NTFS nicht im Filesystem abgelegt, sondern in der MFT selbst.

 

[Colttt]

Also unser Mailserver setzt auf ext4 und es rennt.. xfs ist bei Stromausfall gefährlicher als ext4 und btrfs ist mir zu unstabil..

Gesendet von meinem Pixel mit Tapatalk