Fehler in der Implementierung des ext4-Features dir_index die Sie auf Ihrem Zieldateisystem verwenden.
Lösung:Dateisystem ohne dir_index neu erstellen. Oder deaktivieren Sie die Funktion mit tune2fs (einige Vorsicht ist geboten, siehe verwandter Link Novell SuSE 10/11:H-Tree Indexing auf einem ext3-Dateisystem deaktivieren, das sich jedoch auf ext3 bezieht kann ähnliche Vorsicht erfordern.
(get a really good backup made of the filesystem)
(unmount the filesystem)
tune2fs -O ^dir_index /dev/foo
e2fsck -fDvy /dev/foo
(mount the filesystem)
- ext4:Mysteriöser „No space left on device“-Fehler
ext4 hat standardmäßig eine Funktion namens dir_index aktiviert, die ziemlich anfällig für Hash-Kollisionen ist.
......
ext4 hat die Möglichkeit, die Dateinamen seines Inhalts zu hashen. Dies verbessert die Leistung, hat aber ein „kleines“ Problem:ext4 vergrößert seine Hashtabelle nicht, wenn sie beginnt, sich zu füllen. Stattdessen wird -ENOSPC oder „no space left on device“ zurückgegeben.
Vorschläge für bessere Alternativen als ext4 zum Speichern von Massen kleiner Dateien:
Wenn Sie das Dateisystem als Objektspeicher verwenden, möchten Sie vielleicht ein darauf spezialisiertes Dateisystem verwenden, möglicherweise auf Kosten anderer Eigenschaften. Eine schnelle Google-Suche ergab Ceph , das Open Source zu sein scheint und als POSIX-Dateisystem gemountet werden kann, auf das aber auch mit anderen APIs zugegriffen werden kann. Ich weiß nicht, ob es sich lohnt, es auf einem einzelnen Host zu verwenden, ohne die Vorteile der Replikation zu nutzen.
Ein weiteres Objektspeichersystem ist Swift von OpenStack . Seine Designdokumente besagen, dass jedes Objekt als separate Datei mit Metadaten in xattrs gespeichert wird. Hier ist ein Artikel darüber. Ihr Bereitstellungsleitfaden sagt, dass sie festgestellt haben, dass XFS die beste Leistung für die Objektspeicherung bietet. Auch wenn die Arbeitslast nicht das ist, was XFS am besten kann, war es anscheinend besser als die Konkurrenz, als RackSpace Dinge testete. Möglicherweise bevorzugt Swift XFS, weil XFS eine gute/schnelle Unterstützung für erweiterte Attribute hat. Es könnte sein, dass ext3/ext4 auf einzelnen Festplatten als Objektspeicher-Backend gut funktionieren würde, wenn keine zusätzlichen Metadaten benötigt würden (oder wenn sie in der Binärdatei aufbewahrt würden).
Swift erledigt die Replikation/den Lastausgleich für Sie und schlägt vor, dass Sie ihm Dateisysteme geben, die auf Raw-Festplatten erstellt wurden, nicht RAID . Es weist darauf hin, dass seine Workload im Wesentlichen der Worst-Case für RAID5 ist (was sinnvoll ist, wenn wir über eine Workload mit Schreibvorgängen kleiner Dateien sprechen. XFS packt sie normalerweise nicht Kopf an Schwanz, also tun Sie es nicht Holen Sie sich Full-Stripe-Schreibvorgänge, und RAID5 muss einige Lesevorgänge durchführen, um den Paritätsstreifen zu aktualisieren.Swift-Dokumente sprechen auch über die Verwendung von 100 Partitionen pro Laufwerk.Ich nehme an, das ist ein Swift-Begriff und spricht nicht davon, 100 verschiedene XFS-Dateisysteme auf jedem zu erstellen SATA-Festplatte.
Das Ausführen eines separaten XFS für jede Festplatte ist tatsächlich ein großer Unterschied . Statt einer gigantischen Free-Inode-Map hat jede Festplatte ein separates XFS mit separaten Free-Listen. Außerdem vermeidet es die RAID5-Strafe für kleine Schreibvorgänge.
Wenn Sie Ihre Software bereits so gebaut haben, dass sie ein Dateisystem direkt als Objektspeicher verwendet, anstatt etwas wie Swift zu durchlaufen, um die Replikation / den Lastenausgleich zu handhaben, können Sie zumindest vermeiden, alle Ihre Dateien in einem einzigen Verzeichnis zu haben. (Ich habe nicht gesehen, dass Swift-Dokumente sagen, wie sie ihre Dateien in mehreren Verzeichnissen anordnen, aber ich bin mir sicher, dass sie es tun.)
Bei fast jedem normalen Dateisystem hilft es, eine Struktur wie
zu verwenden1234/5678 # nested medium-size directories instead of
./12345678 # one giant directory
Wahrscheinlich sind etwa 10.000 Einträge angemessen, daher ist es eine einfache Lösung, gut verteilte 4 Zeichen Ihrer Objektnamen zu verwenden und sie als Verzeichnisse zu verwenden. Es muss nicht sehr gut ausbalanciert sein. Die ungeraden 100.000 Verzeichnisse werden wahrscheinlich kein auffälliges Problem sein, und einige leere Verzeichnisse auch nicht.
XFS ist nicht ideal für große Massen kleiner Dateien. Es tut, was es kann, ist aber besser für das Streaming von Schreibvorgängen größerer Dateien optimiert. Für den allgemeinen Gebrauch ist es aber insgesamt sehr gut. Es hat nicht ENOSPC auf Kollisionen in seiner Verzeichnisindizierung (AFAIK) und kann damit umgehen, ein Verzeichnis mit Millionen von Einträgen zu haben. (Aber es ist immer noch besser, zumindest einen einstufigen Baum zu verwenden.)
Dave Chinner hatte einige Kommentare zur XFS-Leistung mit einer großen Anzahl von zugewiesenen Inodes, was zu langsamen touch führte Leistung. Das Finden eines freien Inodes zum Zuweisen nimmt mehr CPU-Zeit in Anspruch, da die Bitmap des freien Inodes fragmentiert wird. Beachten Sie, dass es hier nicht um ein großes Verzeichnis oder mehrere Verzeichnisse geht, sondern um viele verwendete Inodes im gesamten Dateisystem. Das Aufteilen Ihrer Dateien in mehrere Verzeichnisse hilft bei einigen Problemen, wie dem, an dem ext4 im OP erstickt ist, aber nicht dem Problem der gesamten Festplatte, den freien Speicherplatz im Auge zu behalten. Swifts separates Dateisystem pro Festplatte hilft dabei, im Vergleich zu einem riesigen XFS auf einem RAID5.
Ich weiß nicht, ob btrfs ist gut darin, aber ich denke, es kann sein. Ich denke, Facebook stellt seinen leitenden Entwickler aus einem bestimmten Grund ein. :P Einige Benchmarks, die ich gesehen habe, wie das Entpacken einer Linux-Kernel-Quelle, zeigen, dass btrfs gut funktioniert.
Ich kenne reiserfs wurde für diesen Fall optimiert, wird aber kaum oder gar nicht mehr gepflegt. Reiser4 kann ich wirklich nicht empfehlen. Es könnte jedoch interessant sein, zu experimentieren. Aber es ist bei weitem die am wenigsten zukunftssichere Wahl. Ich habe auch Berichte über Leistungseinbußen bei gealtertem reiserFS gesehen, und es gibt kein gutes Defragmentierungstool. (google filesystem millions of small files , und sehen Sie sich einige der vorhandenen Stackexchange-Antworten an.)
Ich vermisse wahrscheinlich etwas, also letzte Empfehlung:Fragen Sie auf Serverfault danach! Wenn ich jetzt etwas auswählen müsste, würde ich sagen, probieren Sie BTRFS aus, aber stellen Sie sicher, dass Sie Backups haben. (insbesondere wenn Sie die eingebaute Mehrfach-Festplattenredundanz von BTRFS verwenden, anstatt sie auf RAID auszuführen. Die Leistungsvorteile könnten groß sein, da kleine Dateien schlechte Nachrichten für RAID5 sind, es sei denn, es handelt sich um eine Workload mit überwiegendem Lesezugriff.)
Für dieses Problem unten habe ich Folgendes behoben (möglicherweise benötigen Sie sudo-Zugriff für die folgenden Schritte):
-
Der belegte Speicherplatz der Inodes betrug 100 %, was mit dem folgenden Befehl abgerufen werden kann
df -i /
Dateisystem-Inodes IUsed IFree IUse% Eingehängt auf
/dev/xvda1 524288 524288 o 100% /
- Sie müssen das iNoted freigeben, daher müssen Sie die Dateien finden, die hier die Anzahl der i-Knoten haben, indem Sie den folgenden Befehl verwenden:
Versuchen Sie herauszufinden, ob dies ein Inodes-Problem ist mit:
df -ih
Versuchen Sie, Root-Ordner mit einer großen Inodes-Anzahl zu finden:
for i in /*; do echo $i; find $i |wc -l; done
Versuchen Sie, bestimmte Ordner zu finden:
for i in /src/*; do echo $i; find $i |wc -l; done
- Jetzt haben wir den Ordner mit einer großen Anzahl von Dateien auf Null gesetzt. Führen Sie die folgenden Befehle nacheinander aus, um Fehler zu vermeiden (in meinem Fall war der eigentliche Ordner /var/spool/clientmqueue):
find /var/spool/clientmqueue/ -type f -mtime +1050 -exec rm -f {} + find /var/spool/clientmqueue/ -type f -mtime +350 -exec rm -f {} + find /var/spool/clientmqueue/ -type f -mtime +150 -exec rm -f {} + find /var/spool/clientmqueue/ -type f -mtime +50 -exec rm -f {} +