Speichern von Dateien in einem Verzeichnis … gibt es Grenzen?

Speichern von Dateien in einem Verzeichnis … gibt es Grenzen?

Ich verwende CentOS 5 mit Plesk 9 (64-Bit) und betreibe eine Site, auf der Benutzer Bilder hochladen. Gibt es bei einem 64-Bit-Betriebssystem irgendwelche Beschränkungen hinsichtlich der Anzahl der Dateien, die ich speichern kann? Mir geht es nur um die Leistung und darum, die Dateien bereitzustellen. Ich möchte nicht 4 Verzeichnisse mit verstreuten Dateien haben. Ich hoffe jedoch, dass ich irgendwann 200.000 bis 300.000 Bilder haben kann.

Antwort1

Wenn du bistmit ext3, Ich fanddieses Zitat(Warnung: spanischsprachige Site)

"Es gibt eine Beschränkung von 32.000 (32.768) Unterverzeichnissen in einem einzigen Verzeichnis, eine Beschränkung, die wahrscheinlich nur von akademischem Interesse ist, da viele Leute nicht einmal so viele Dateien haben (obwohl große Mailserver dies möglicherweise berücksichtigen müssen). Die Inode-Spezifikation von ext2 erlaubt die Speicherung von über 100 Billionen Dateien in einem einzigen Verzeichnis."

Weiterführende Literaturzeigte, dass ext3nichthaben eine 32K-Beschränkung, die empirisch nachgewiesen werden kann mit

a=0; i=1; while [ $a == 0 ]; do touch $i; a=$?; let i++; done

aber eshatein 32K Ordnerlimit für Ordner, das getestet werden kann mit

a=0; i=1; while [ $a == 0 ]; do mkdir $i; a=$?; let i++; done

Diese (unbegründete) Behauptungsagt, dass

ReiserFS hat überhaupt keine Probleme mit Hunderttausenden von Dateien in einem einzigen Verzeichnis. flabdablet - 1. Februar 2007

Diese Fragevon der Schwesterseite stackoverflow.com könnte auch helfen.

Allgemein:

  • DortIsteine Begrenzung der Anzahl von Verzeichnissen,
  • DusollenHalten Sie Ihre Dateien/Verzeichnisse unter 32 KB, aberdürfenviel weiter gehen,
  • Das von Ihnen verwendete Dateisystem ist wichtig.

Antwort2

Dies hängt stark von dem von Ihnen verwendeten Dateisystem ab. Bestimmte ältere Versionen von ext3 waren diesbezüglich furchtbar, wodurch die Btrees entstanden. Reiser ist bei großen Mengen von Dateien wie diesen viel leistungsfähiger. Früher hatte ich aufgrund eines GroupWise-Fehlers ein Novell NSS-Verzeichnis auf einem NetWare-Server mit 250.000 4-KB-Dateien darin und es funktionierte einwandfrei. Das Auflisten des Verzeichnisses war ziemlich nervig, aber der Zugriff auf eine bestimmte Datei in diesem Verzeichnis funktionierte so schnell, wie man es sich erhofft. Da dies vor 8 Jahren war, muss ich davon ausgehen, dass moderne Linux-Dateisysteme dies problemlos bewältigen können.

Antwort3

Dies hängt vom verwendeten Dateisystem ab, nicht von der 64-Bit-Version des Betriebssystems. Bei jedem Dateisystem gibt es einen Punkt, an dem die Big-O-Kosten des zum Durchsuchen des Verzeichnisses verwendeten Algorithmus den Computer überfordern.

Wenn Sie die Dateihierarchie auch nur in eine zwei (2) Ebenenhierarchie aufteilen können, erzielen Sie eine bessere langfristige Skalierbarkeit.

Antwort4

Wenn Sie mehr als ein paar Hundert Bilder benötigen, sollten Sie unbedingt zwei Dinge bedenken:

  1. Verschachtelte Hierarchien mit gehashten Dateinamen;
  2. Ich verwende kein ext3

Ich empfehle die Verwendung von XFS oder, falls das nicht möglich ist, ReiserFS mit einer zwei- oder dreistufigen Verzeichnishierarchie, die in Zwei-Byte-Paare unterteilt ist. Beispiel:

11/2f/112f667c786eac323e300632b5b2a78d.jpg
49/2f/49ef6eb6169cc57d95218c842d3dee5c.jpg
0a/26/0a26f9f363f1d05b94ceb14ff5f27284.jpg

Dadurch erhalten Sie 256 Verzeichnisse in den ersten Ebenen und verteilen die Bilder auf insgesamt 65.535 separate Verzeichnisse (was für 100.000 bis 200.000 Bilder und mehr mehr als ausreichend ist). Dadurch wird alles viel schneller und skalierbarer und ist später auch viel einfacher zu warten.

verwandte Informationen