Frage Dateisystem große Anzahl von Dateien in einem einzigen Verzeichnis


OK, nicht so groß, aber ich brauche etwas, wo etwa 60.000 Dateien mit einer durchschnittlichen Größe von 30kb in einem einzigen Verzeichnis gespeichert sind (dies ist eine Voraussetzung, damit nicht einfach Unterverzeichnisse mit einer kleineren Anzahl von Dateien geöffnet werden können).

Auf die Dateien wird nach dem Zufallsprinzip zugegriffen, aber sobald sie erstellt sind, wird es keine Schreibvorgänge mehr in dasselbe Dateisystem geben. Ich verwende derzeit Ext3, finde es aber sehr langsam. Irgendwelche Vorschläge?


25
2017-07-20 18:45


Ursprung


Warum müssen sie in einem Verzeichnis sein? - Kyle Brandt♦
Ich bin auch an einer aktuellen Antwort auf die ursprüngliche Frage interessiert, mit genügend Verbesserungen in xfs und ext4.


Antworten:


Sie sollten XFS in Betracht ziehen. Es unterstützt eine sehr große Anzahl von Dateien sowohl auf Dateisystem- als auch auf Verzeichnisebene, und die Leistung bleibt auch bei einer großen Anzahl von Einträgen aufgrund der B + Baumdatenstrukturen relativ konsistent.

Da ist ein Seite auf ihrem Wiki zu einer großen Anzahl von Papieren und Publikationen, die das Design detaillieren. Ich empfehle Ihnen, es zu versuchen und vergleichen Sie es mit Ihrer aktuellen Lösung.


14
2017-07-20 19:44



Laut den Folien in @ Nelaars Antwort wäre ext4 für diese Aufgabe besser als xfs. - mulllhausen


Eine Milliarde Dateien unter Linux

Der Autor dieses Artikels befasst sich mit einigen Leistungsproblemen in Dateisystemen mit großen Dateien und vergleicht die Leistung verschiedener Dateisysteme ext3, ext4 und XFS. Dies wird als Diashow zur Verfügung gestellt. http://events.linuxfoundation.org/slides/2010/linuxcon2010_wheeler.pdf

time to run mkfs time to create 1M 50kb files File system repair time removing 1m files


14
2017-08-27 10:59



Wir bevorzugen wirklich, dass die Antworten Inhalte enthalten, keine Hinweise auf Inhalte. Während dies theoretisch die Frage beantworten könnte, es wäre vorzuziehen um die wesentlichen Teile der Antwort hier einzubeziehen und den Link als Referenz bereitzustellen. - Iain
@Iain Ich hoffe, das ist besser, als einfach das PDF herunterladen, würde Ihnen die gleichen Informationen geben. - nelaaro
wow das sind einige außergewöhnlich schwer zu lesende Graphen. ~ - ThorSummoner


Viele Dateien in einem Verzeichnis auf ext3 wurden auf der Schwesterseite ausführlich besprochen stackoverflow.com

Meiner Meinung nach sind 60 000 Dateien in einem Verzeichnis auf ext3 alles andere als ideal, aber abhängig von Ihren anderen Anforderungen könnte es gut genug sein.


7
2017-07-20 18:57





OK. Ich habe einige Vorversuche mit ReiserFS, XFS, JFS, Ext3 (dir_hash enabled) und Ext4dev (2.6.26 kernel) gemacht. Mein erster Eindruck war, dass alle schnell genug waren (auf meiner bulligen Workstation) - es stellt sich heraus, dass die entfernte Produktionsmaschine einen ziemlich langsamen Prozessor hat.

Ich habe mit ReiserFS schon beim ersten Testen etwas Seltsames erlebt. Es sieht so aus, als hätte JFS 33% weniger CPU-Bedarf als alle anderen und testet das auf dem Remote-Server. Wenn es gut genug ist, werde ich das verwenden.


5
2017-07-20 22:07





Ich schreibe eine Anwendung, die auch viele und viele Dateien speichert, obwohl meine größer sind und ich 10 Millionen von ihnen habe, die ich über mehrere Verzeichnisse aufteilen werde.

ext3 ist langsam, hauptsächlich wegen der Implementierung der "verknüpften Liste". Wenn Sie also viele Dateien in einem Verzeichnis haben, bedeutet das, dass das Öffnen oder Erstellen eines anderen immer langsamer wird. Es gibt einen sogenannten htree-Index, der für ext3 verfügbar ist und Berichten zufolge die Dinge stark verbessert. Aber es ist nur bei der Erstellung des Dateisystems verfügbar. Siehe hier: http://lonesysadmin.net/2007/08/17/use-dir_index-for-your-new-ext3-filesystems/

Da Sie das Dateisystem sowieso neu aufbauen müssen und aufgrund der ext3-Einschränkungen, ist es meine Empfehlung, dass Sie sich mit ext4 (oder XFS) beschäftigen. Ich denke, ext4 ist ein wenig schneller mit kleineren Dateien und hat schnellere Neuerstellungen. Htree-Index ist standardmäßig auf ext4, soweit ich weiß. Ich habe wirklich keine Erfahrung mit JFS oder Reiser, aber ich habe Leute gehört, die das vorher empfehlen.

In Wirklichkeit würde ich wahrscheinlich mehrere Dateisysteme testen. Warum nicht versuchen, ext4, xfs & jfs und sehen, welche die beste Gesamtleistung gibt?

Etwas, das mir ein Entwickler gesagt hat, der Dinge im Anwendungscode beschleunigen kann, ist nicht ein Aufruf "stat + open", sondern "open + fstat". Der erste ist deutlich langsamer als der zweite. Nicht sicher, ob Sie irgendeine Kontrolle oder Einfluss darauf haben.

Siehe meinen Beitrag hier auf stackoverflow. Speichern und Zugriff auf bis zu 10 Millionen Dateien in Linux Dort gibt es einige sehr nützliche Antworten und Links.


4
2018-02-24 01:34





Die Verwendung von tune2fs zum Aktivieren von dir_index könnte helfen. Um zu sehen, ob es aktiviert ist:

sudo tune2fs -l /dev/sda1 | grep dir_index

Wenn es nicht aktiviert ist:

sudo umount /dev/sda1   
sudo tune2fs -O dir_index /dev/sad1
sudo e2fsck -D /dev/sda1
sudo mount /dev/sda1

Aber ich habe das Gefühl, dass du vielleicht den falschen Weg eingeschlagen hast ... warum nicht einen flachen Index generieren und etwas Code verwenden, um basierend darauf zufällig zu wählen. Sie können dann Unterverzeichnisse für eine optimierte Baumstruktur verwenden.


2
2017-07-20 19:54



war /dev/sad1 absichtlich Kopier- / Nudelfehler verhindern? - Anwar


Sie können Datei-Inodes anstelle von Dateinamen speichern: Der Zugriff auf Inode-Nummern sollte wesentlich schneller sein als das Auflösen von Dateinamen


1
2017-07-20 20:12



Sag es mir jetzt. Wie öffne ich eine Datei nach Inode-Nummer? - Matt
@Matt, Es sieht so aus, als ob sich die Frage geändert hat, nachdem ich geantwortet habe. Oder ich war vor 1,5 Jahren viel dümmer :))) - kolypto


ext3 und darunter unterstützen bis zu 32768 Dateien pro Verzeichnis. ext4 unterstützt bis zu 65536 in der tatsächlichen Anzahl der Dateien, ermöglicht es Ihnen jedoch, mehr zu haben (es speichert sie nur nicht im Verzeichnis, was für die meisten Benutzerzwecke nicht wichtig ist).

Außerdem ist die Art, wie Verzeichnisse auf ext * Dateisystemen gespeichert sind, im Wesentlichen eine einzige große Liste. Auf den moderneren Dateisystemen (Reiser, XFS, JFS) werden sie als B-Bäume gespeichert, die für große Mengen viel effizienter sind.


1
2017-07-20 19:18



Diese Anzahl von Dateien in einem Verzeichnis zu unterstützen, ist nicht dasselbe wie es mit einer angemessenen Geschwindigkeit zu tun. Ich weiß noch nicht, ob ext4 ist besser, aber ext3 verlangsamt sich stark, wenn es mehr als ein paar tausend Dateien in einem Verzeichnis hat, auch mit dir_index aktiviert (es hilft, aber das Problem nicht vollständig beseitigt). - cas


Sie wollen nicht so viele Dateien in ein Verzeichnis stopfen, Sie wollen irgendeine Art von Struktur. Auch wenn es so einfach ist wie Unterverzeichnisse, die mit dem ersten Zeichen der Datei beginnen, können Sie Ihre Zugriffszeiten verbessern. Ein anderer alberner Trick, den ich gerne benutze, besteht darin, das System zu zwingen, seinen Cache zu aktualisieren, wobei Metainformationen regelmäßig aktualisiert werden sollen. In einem Fenster führen Sie slabtop, und in einem anderen Lauf updatedb und Sie werden sehen, viel Speicher wird Caching zugeordnet werden. Es ist viel schneller so.


0
2017-07-24 17:26





Sie haben die Art der Daten in diesen Dateien nicht angegeben. Aber von den Geräuschen her sollten Sie eine Art Datenbank mit Indizierung für schnelle Suchen verwenden.


-1
2017-07-20 18:54





Dateisystem ist wahrscheinlich nicht der ideale Speicher für solche Anforderungen. Eine Art von Datenbankspeicher ist besser. Trotzdem, wenn Sie nicht helfen können, dann versuchen Sie, Dateien in mehreren Verzeichnissen aufzuteilen und unionfs zu verwenden, um diese Verzeichnisse in einem einzigen Verzeichnis zu mounten (binden), wo alle Dateien erscheinen sollen. Ich habe diese Technik nicht zur Beschleunigung benutzt, aber es ist einen Versuch wert.


-1
2017-07-20 19:33