Wie viele Dateien kann ich in einem Verzeichnis kopieren?

https://stackoverflow.com/questions/466521

19-08-2019
|

Frage

Spielt es eine Rolle, wie viele Dateien, die ich in einem einzigen Verzeichnis zu halten? Wenn ja, wie viele Dateien in einem Verzeichnis zu viele, und was sind die Auswirkungen von zu vielen Dateien? (Dies ist auf einem Linux-Server.)

Hintergrund: Ich ein Fotoalbum Website haben, und jedes Bild in ein 8-hex-stellige ID umbenannt hochgeladen (sagen wir, a58f375c.jpg). Dies ist auf Dateinamen Konflikte zu vermeiden (wenn viele „IMG0001.JPG“ Dateien hochgeladen werden, zum Beispiel). Der ursprüngliche Dateiname und nützliche Metadaten werden in einer Datenbank gespeichert. Gerade jetzt, ich habe irgendwo um 1500 Dateien im Verzeichnis images. Dies macht die Dateien im Verzeichnisliste (über FTP oder SSH-Client) ein paar Sekunden dauern. Aber ich kann nicht sehen, dass es keine Auswirkungen außer dass hat. Insbesondere scheint es keine Auswirkungen auf die zu sein, wie schnell eine Bilddatei an den Benutzer bedient wird.

Ich habe darüber nachgedacht, die Anzahl der Bilder zu reduzieren um 16 Unterverzeichnisse machen: 0-9 und A-F. Dann würde ich die Bilder in den Unterordner verschieben auf das, was die erste Hexadezimalzeichens des Dateinamens war. Aber ich bin nicht sicher, dass aus irgendeinem Grund gibt es so außer dem gelegentlichen Auflistung des Verzeichnisses über FTP / SSH zu tun.

Lösung

FAT32 :

Maximale Anzahl der Dateien: 268173300
Maximale Anzahl der Dateien pro Verzeichnis: 2 ¹⁶ - 1 (65.535)
Maximale Dateigröße: 2 GiB - 1 ohne LFS , 4 GiB - 1 mit

NTFS :

Maximale Anzahl der Dateien: 2 ³² - 1 (4294967295)
Maximale Dateigröße
- Umsetzung: 2 ⁴⁴ - 2 ⁶ Bytes (16 TiB - 64 KiB)
- Theoretisch: 2 ⁶⁴ - 2 ⁶ Bytes (16 EiB - 64 KiB)
Die maximale Volumengröße
- Umsetzung: 2 ³² - 1-Cluster (256 TiB - 64 KiB)
- Theoretisch: 2 ⁶⁴ - 1 Cluster (1 yib - 64 KiB)

ext2 :

Maximale Anzahl der Dateien: 10 ¹⁸
Maximale Anzahl der Dateien pro Verzeichnis: ~ 1,3 × 10 ²⁰ (Performance-Probleme letzter 10.000)
Maximale Dateigröße
- 16 GiB (Blockgröße von 1 KB)
- 256 GiB (Blockgröße von 2 KiB)
- 2 TiB (Blockgröße von 4 KiB)
- 2 TiB (Blockgröße von 8 KB)
Die maximale Volumengröße
- 4 TiB (Blockgröße von 1 KB)
- 8 TiB (Blockgröße von 2 KB)
- 16 TiB (Blockgröße von 4 KB)
- 32 TiB (Blockgröße von 8 KiB)

ext3 :

Maximale Anzahl der Dateien: min (volumeSize / 2 ¹³, NumberOfBlocks)
Maximale Dateigröße: gleiche wie ext2
Maximale Lautstärke Größe: gleiche wie ext2

ext4 :

Maximale Anzahl der Dateien: 2 ³² - 1 (4294967295)
Maximale Anzahl der Dateien pro Verzeichnis: unbegrenzt
Maximale Dateigröße: 2 ⁴⁴ - 1 Byte (16 TiB - 1)
Maximale Lautstärke Größe: 2 ⁴⁸ - 1 Bytes (256 TiB - 1)

Andere Tipps

Ich habe mehr als 8 Millionen Dateien in einem einzigen Verzeichnis ext3 habe. Libc readdir() die durch find, ls verwendet wird, und die meisten der anderen in diesem Thread diskutierten Methoden große Verzeichnisse aufzulisten.

Der Grund ls und find in diesem Fall langsam ist, dass readdir() nur 32K von Verzeichniseinträgen zu einem Zeitpunkt liest, so auf langsamen Festplatten wird es viele viele liest benötigen ein Verzeichnis aufzulisten. Es gibt eine Lösung für dieses Problem Geschwindigkeit. Ich schrieb einen ziemlich ausführlichen Artikel darüber unter: http://www.olark.com/spw/2011/08/you-can-list-a-directory-with-8-million-files-but- nicht-mit-ls /

Der Schlüssel wegzunehmen heißt: Verwendung getdents() direkt - http://www.kernel.org/doc/man-pages/online/pages/man2/getdents.2.html eher als alles, was auf libc readdir() basiert, so können Sie die Puffergröße angeben, wenn Lesen Verzeichniseinträge von der Platte.

Ich habe ein Verzeichnis mit 88.914 Dateien darin. Wie Sie selbst wird diese verwendet Thumbnails zum Speichern und auf einem Linux-Server.

Listed Dateien per FTP oder eine PHP-Funktion sind langsam ja, aber es ist auch eine Performance-Einbußen, die Datei auf der Anzeige. z.B. www.website.com/thumbdir/gh3hg4h2b4h234b3h2.jpg hat eine Wartezeit von 200 bis 400 ms. Als Vergleich auf einer anderen Seite, die ich mit rund 100 Dateien in einem Verzeichnis habe das Bild nach nur ~ 40 ms des Wartens angezeigt wird.

Ich habe diese Antwort gegeben, wie die meisten Menschen, wie Verzeichnis Suchfunktionen durchführen wird geschrieben haben, die Sie nicht auf einem Daumen-Ordner verwenden - nur Dateien statisch anzeigt, wird aber in der Leistung, wie die Dateien interessiert sein können tatsächlich verwendet werden.

Es hängt ein wenig von dem spezifischen Dateisystem im Einsatz auf dem Linux-Server. Heute ist die Standardeinstellung ext3 mit dir_index, die sehr schnell große Verzeichnisse macht die Suche.

So Geschwindigkeit sollte kein Problem sein, andere als die, die Sie bereits erwähnt, das ist, dass Inserate länger dauern wird.

Es gibt eine Grenze für die Gesamtzahl der Dateien in einem Verzeichnis. Ich scheine es auf jeden Fall zu erinnern, zu 32000 Dateien Aufarbeitung.

Beachten Sie, dass auf Linux, wenn Sie ein Verzeichnis mit zu vielen Dateien haben, kann nicht die Shell können Platzhalter erweitern. Ich habe dieses Problem mit einem Fotoalbum auf Linux gehostet. Es speichert alle verkleinerten Bilder in einem einzigen Verzeichnis. Während das Dateisystem viele Dateien verarbeiten kann, kann die Schale nicht. Beispiel:

-shell-3.00$ ls A*
-shell: /bin/ls: Argument list too long

oder

-shell-3.00$ chmod 644 *jpg
-shell: /bin/chmod: Argument list too long

Ich arbeite gerade an einem ähnlichen Problem jetzt. Wir haben eine hierarchische Verzeichnisstruktur und verwenden Bild-IDs als Dateinamen. Zum Beispiel wird ein Bild mit id=1234567 platziert in

..../45/67/1234567_<...>.jpg

letzte 4 Stellen, um festzustellen, wo die Datei geht.

Mit ein paar tausend Bilder, könnten Sie eine one-Level-Hierarchie verwenden. Unsere Sysadmin vorgeschlagen, nicht mehr als einige tausend Dateien in einem bestimmten Verzeichnis (ext3) für Effizienz / backup / was auch immer andere Gründe, die er im Sinn hatte.

Für das, was es wert ist, habe ich nur ein Verzeichnis auf einem ext4 Dateisystem mit 1.000.000 Dateien darin, dann zugegriffen zufällig diese Dateien über einen Webserver. Ich habe keine Prämie feststellen, die über auf den Zugriff auf (sagen wir) nur 10 Dateien mit dort.

Dies ist radikal unterscheidet sich von meiner Erfahrung auf ntfs ein paar Jahren zu tun.

Das größte Problem, das ich habe laufen in ist auf einem 32-Bit-System. Sobald Sie eine bestimmte Anzahl passieren, Tools wie aufhören zu arbeiten ‚ls‘.

Der Versuch, etwas mit diesem Verzeichnis zu tun, wenn Sie, dass Schranke passieren ein großes Problem wird.

Es hängt absolut auf dem Dateisystem. Viele moderne Dateisysteme verwenden anständige Datenstrukturen den Inhalt von Verzeichnissen zu speichern, aber ältere Dateisysteme oft hinzugefügt nur die Einträge in einer Liste, so das Abrufen einer Datei war ein O (n) -Operation.

Auch wenn das Dateisystem es richtig macht, ist es noch absolut möglich für Programme, die Liste Verzeichnisinhalte zu vermasseln und ein O tun (n ^ 2) sortieren, so auf der sicheren Seite zu sein, würde ich begrenzen immer die Nummer von Dateien pro Verzeichnis auf nicht mehr als 500.

Es hängt wirklich von dem Dateisystem verwendet wird, und auch einige Fahnen.

Zum Beispiel ext3 können viele Tausende von Dateien haben; aber nach ein paar tausend, es war früher sehr langsam. Meistens, wenn die Auflistung ein Verzeichnis, sondern auch, wenn eine einzelne Datei zu öffnen. Vor ein paar Jahren, gewann sie die ‚htree‘ Option, die die benötigte Zeit bekommen einen Inode gegeben einen Dateinamen dramatisch verkürzt.

Persönlich benutze ich Unterverzeichnisse den meisten Ebenen unter tausend oder so Artikel zu halten. In Ihrem Fall würde ich 256 Verzeichnisse mit den beiden letzten hexadezimalen Ziffern der ID erstellen. Verwenden Sie die letzte und nicht die ersten Ziffern, so dass Sie die Last ausgeglichen bekommen.

Wenn die Zeit involviert in ein Verzeichnis Partitionierungsschema Durchführung minimal ist, bin ich für sie. Das erste Mal, müssen Sie ein Problem debuggen, die ein 10000-Dateiverzeichnis über die Konsole beinhalten Manipulieren Sie werden verstehen.

Als Beispiel F-Spot speichern Fotodateien als YYYY \ MM \ DD \ filename.ext, die das größte Verzeichnis bedeutet, das ich je hatte mit Weile beschäftigt manuell meine ~ 20000-Fotosammlung zu manipulieren sind etwa 800 Dateien. Dies macht auch die Dateien leichter durchsuchbar von einer Drittanbieter-Anwendung. Niemals davon ausgehen, dass Ihre Software die einzige Sache ist, dass Ihre Software-Dateien zugreifen.

Die Frage kommt auf, was Sie mit den Dateien tun werden.

Unter Windows beliebiges Verzeichnis mit mehr als 2k Dateien neigt für mich in Explorer langsam zu öffnen. Wenn sie alle Bilddateien sind, mehr als 1k neigen dazu, sehr langsam in Miniaturansicht zu öffnen.

Zu einer Zeit, das System auferlegte Grenze war 32.767. Es ist jetzt höher, aber auch das ist viel zu viele Dateien auf einmal in den meisten Fällen zu behandeln.

ext3 in der Tat haben Verzeichnisgröße Grenzen, und sie hängen von der Blockgröße des Dateisystems. Es gibt keine pro-Verzeichnis „maximale Anzahl“ von Dateien, sondern eine pro-Verzeichnis „max Anzahl der Blöcke zum Speichern von Dateieinträge verwendet“. Insbesondere hängt die Größe des Verzeichnisses selbst nicht über einen b-Baum der Höhe wachsen kann 3 und die Auffächerung des Baumes auf der Blockgröße. Siehe diesen Link für einige Details.

https://www.mail-archive.com/cwelug@ googlegroups.com/msg01944.html

wurde ich durch das kürzlich auf einem Dateisystem gebissen mit 2K Blöcke formatiert, die aus unerklärlichen Gründen Verzeichnis voll Kernel-Meldungen warning: ext3_dx_add_entry: Directory index full! war immer, wenn ich von einem anderen ext3-Dateisystem kopiert wurde. In meinem Fall ein Verzeichnis mit gerade einmal 480.000 Dateien konnte nicht in das Ziel kopiert werden.

Ich habe das gleiche Problem gehabt. Der Versuch, Millionen von Dateien in einem Ubuntu-Server in ext4 zu speichern. Beendet meine eigene Benchmarks. Fand heraus, dass flaches Verzeichnis Weg zu besseren Ergebnissen führt, während sie Art und Weise einfacher zu verwenden:

Schrieb ein Artikel .

Ich erinnere läuft ein Programm, das eine riesige Menge von Dateien am Ausgang wurde zu schaffen. Die Dateien wurden bei 30000 pro Verzeichnis sortiert. Ich erinnere mich noch keine Leseprobleme haben, wenn ich die erzeugte Ausgabe wieder verwenden musste. Es war auf einem 32-Bit-Ubuntu Linux Laptop und sogar Nautilus den Verzeichnisinhalt angezeigt, wenn auch nach einigen Sekunden.

ext3-Dateisystem. Ähnlicher Code auf einem 64-Bit-System behandelt und mit 64.000 Dateien pro Verzeichnis

Ich respektiere diese Antwort nicht ganz Ihre Frage, wie viele zu viele, aber eine Idee für die langfristige Problemlösung besteht darin, dass die ursprüngliche Datei-Metadaten zusätzlich zu speichern, auch speichern, die Ordner auf dem Datenträger gespeichert ist in - normalisiert das Stück von Metadaten aus. Sobald ein Ordner über eine gewisse Grenze wächst sind Sie mit für die Leistung komfortabel, ästhetisch oder welche Gründe auch immer, die Sie gerade einen zweiten Ordner erstellen und Dateien starten dort fallen ...

Ich lief in ein ähnliches Problem. Ich habe versucht, mit mehr als 10.000 Dateien in ein Verzeichnis mit zuzugreifen. Es war zu lange dauern würde, um die Dateiliste zu erstellen und jede Art von Befehlen auf eine der Dateien ausgeführt werden.

dachte ich einen kleinen PHP-Skript auf diese für mich zu tun und versuchte, einen Weg finden, um es im Browser von Zeit heraus zu verhindern.

Im Folgenden ist der PHP-Skript, das ich schrieb, das Problem zu lösen.

Listing Dateien in einem Verzeichnis mit zu vielen Dateien für FTP

Wie es hilft jemand

Ich ziehe es auf die gleiche Weise wie @armandino . Dafür verwende ich diese kleine Funktion in PHP-IDs in einen Dateipfad zu konvertieren, die 1000 Dateien pro Verzeichnis Ergebnisse:

function dynamic_path($int) {
    // 1000 = 1000 files per dir
    // 10000 = 10000 files per dir
    // 2 = 100 dirs per dir
    // 3 = 1000 dirs per dir
    return implode('/', str_split(intval($int / 1000), 2)) . '/';
}

oder man könnte die zweite Version verwenden, wenn Sie alphanumerische verwenden möchten:

function dynamic_path2($str) {
    // 26 alpha + 10 num + 3 special chars (._-) = 39 combinations
    // -1 = 39^2 = 1521 files per dir
    // -2 = 39^3 = 59319 files per dir (if every combination exists)
    $left = substr($str, 0, -1);
    return implode('/', str_split($left ? $left : $str[0], 2)) . '/';
}

Ergebnisse:

<?php
$files = explode(',', '1.jpg,12.jpg,123.jpg,999.jpg,1000.jpg,1234.jpg,1999.jpg,2000.jpg,12345.jpg,123456.jpg,1234567.jpg,12345678.jpg,123456789.jpg');
foreach ($files as $file) {
    echo dynamic_path(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
1/123.jpg
1/999.jpg
1/1000.jpg
2/1234.jpg
2/1999.jpg
2/2000.jpg
13/12345.jpg
12/4/123456.jpg
12/35/1234567.jpg
12/34/6/12345678.jpg
12/34/57/123456789.jpg

<?php
$files = array_merge($files, explode(',', 'a.jpg,b.jpg,ab.jpg,abc.jpg,ddd.jpg,af_ff.jpg,abcd.jpg,akkk.jpg,bf.ff.jpg,abc-de.jpg,abcdef.jpg,abcdefg.jpg,abcdefgh.jpg,abcdefghi.jpg'));
foreach ($files as $file) {
    echo dynamic_path2(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
12/123.jpg
99/999.jpg
10/0/1000.jpg
12/3/1234.jpg
19/9/1999.jpg
20/0/2000.jpg
12/34/12345.jpg
12/34/5/123456.jpg
12/34/56/1234567.jpg
12/34/56/7/12345678.jpg
12/34/56/78/123456789.jpg
a/a.jpg
b/b.jpg
a/ab.jpg
ab/abc.jpg
dd/ddd.jpg
af/_f/af_ff.jpg
ab/c/abcd.jpg
ak/k/akkk.jpg
bf/.f/bf.ff.jpg
ab/c-/d/abc-de.jpg
ab/cd/e/abcdef.jpg
ab/cd/ef/abcdefg.jpg
ab/cd/ef/g/abcdefgh.jpg
ab/cd/ef/gh/abcdefghi.jpg

Wie Sie für die $int-Version sehen können jeder Ordner enthält bis zu 1000 Dateien und bis zu 99 Verzeichnisse mit 1000 Dateien und Verzeichnissen 99 ...

Aber vergessen Sie nicht, dass zu viele Verzeichnisse Ihre Backup-Prozess beschleunigen unten können. Fühlen Sie sich frei von 1.000 bis 10.000 Dateien pro Verzeichnis zu testen, aber fügen Sie nicht viel mehr als Sie sehr lange Zugriffszeiten haben, wenn Sie das Verzeichnis Datei für Datei lesen (FTP-Clients, Dateilesefunktionen, usw.).

Schließlich sollten Sie darüber nachdenken, wie die Anzahl der Dateien insgesamt zu reduzieren. Abhängig von Ihrem Ziel können Sie CSS-Sprites verwenden, um mehrere kleine Bilder wie Avatare, Icons, Smilies zu kombinieren, usw., oder wenn Sie viele kleine Dateien nicht-Medien verwenden, betrachten kombiniert sie zum Beispiel im JSON-Format. In meinem Fall hatte ich Tausende von Mini-Caches und schließlich habe ich beschlossen, sie in Packungen von 10 zu verbinden.

Was die meisten Antworten nicht oben zeigen, dass es keine „Einheitsgröße“ ist die Antwort auf die ursprüngliche Frage.

Im heutigen Umfeld wir ein großes Konglomerat unterschiedlicher Hardware und Software haben - einige 32-Bit, einige ist 64 Bit, einige Kante schneidet und einige ist altbewährten - zuverlässig und ändert nie. Hinzu kommt eine Vielzahl von älteren und neueren Hardware, ältere und neuere Betriebssysteme, verschiedene Anbieter (Windows, Unix-Varianten, Apfel, etc.) und eine Vielzahl von Werkzeugen und Servern, die entlang gehen. Als Hardware verbessert und Software auf 64-Bit-Kompatibilität umgewandelt hat es zwangsläufig erhebliche Verzögerung gewesen, alle Teile dieser sehr großen und komplexen Welt in immer schön mit dem rasanten Tempo der Veränderungen zu spielen.

IMHO gibt es keine eine Möglichkeit, um ein Problem zu beheben. Die Lösung ist, die Möglichkeiten zu erforschen und dann durch Versuch und Irrtum finden, was am besten für Ihre speziellen Bedürfnisse funktioniert. Jeder Benutzer muss bestimmen, was für ihr System funktioniert, anstatt ein Ausstecher Ansatz.

ich zum Beispiel habe einen Medienserver mit einem paar sehr großen Dateien. Das Ergebnis ist nur etwa 400 Dateien mit einem 3-TB-Laufwerk zu füllen. Nur 1% der Inodes werden verwendet, aber 95% des gesamten Raumes verwendet wird. Jemand anderes, mit vielen kleineren Dateien kann aus Inodes läuft, bevor sie kommen in der Nähe, um den Raum zu füllen. (Bei ext4-Dateisysteme als Faustregel gilt: 1 Inode für jede Datei / Verzeichnis verwendet wird.) Während theoretisch die Gesamtzahl der Dateien, die fast unendlich in einem Verzeichnis enthalten sein können, ist, Praktikabilität bestimmt, dass die Gesamtnutzung realistisch Einheiten bestimmt, nicht nur Fähigkeiten Dateisystem.

Ich hoffe, dass alle die verschiedenen Antworten über Gedanken und Problem gefördert haben lösen, anstatt eine unüberwindbare Barriere darstellt, um die Fortschritte.

Nicht eine Antwort, aber nur einige Vorschläge.

Wählen Sie ein geeigneteren FS (Dateisystem). Da von einem historischen Standpunkt aus, alle Ihre Fragen weise genug waren, um einmal im Mittelpunkt FSs über Jahrzehnte weiterentwickelt. Ich meine modernere FS besser Ihre Fragen unterstützen. Zunächst einen Vergleich Entscheidungstabelle machen auf der Grundlage Ihrer Endzweck von FS Liste .

Ich denke, seine Zeit, um Ihre Paradigmen zu verschieben. So persönlich schlage ich vor, ein verteilten System bewusst FS , die bei all in Bezug auf Größe keine Grenzen bedeuten , die Anzahl der Dateien und usw. Ansonsten werden Sie früher oder später durch neue unvorhergesehene Probleme in Frage gestellt.

Ich bin zu arbeiten, nicht sicher, aber wenn Sie einige Experimente nicht erwähnen, gebe AUF über Ihr aktuelles Dateisystem eines Versuch. Ich denke, es Einrichtungen mehrere Ordner als einen einzelnen virtuellen Ordner zu imitieren hat.

Um die Grenzen der Hardware überwinden Sie RAID-0 verwenden können.

Es gibt keine einzige Figur, die „zu viele“, ist, solange es nicht die Grenzen des OS nicht überschreitet. Je mehr Dateien in einem Verzeichnis, unabhängig von den OS, desto länger dauert es jedoch jede einzelne Datei zuzugreifen, und auf den meisten Betriebssystemen, die Leistung ist nichtlinear, so eine Datei, um herauszufinden, von 10.000 mehr als 10-mal länger dauert dann eine Datei in 1000 zu finden.

Sekundär Probleme im Zusammenhang mit einer Menge von Dateien in einem Verzeichnis umfassen Wild Card Expansion Ausfälle. Um die Risiken zu verringern, sollten Sie überlegen, Ihre Verzeichnisse nach dem Datum ihrer oder einer anderen nützlichen Teil der Metadaten zu bestellen.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow