layout: ../../../layouts/BlogLayout.astro title: “Die Dateianzahl-Lüge: Warum 1,2 Millionen Dateien dir nicht sagen, wie lange die Migration dauert” description: “Die Dateianzahl allein garantiert schlechte Migrationsschätzungen. Lerne, wie du dein Dataset nach Größenverteilung profilierst, IOPS- vs. Throughput-Engpässe berechnest und deinem Chef eine Zahl gibst, die du verteidigen kannst.” date: “2026-03-04” author: “syncopio Team” category: “Best Practices” readingTime: “9 min” slug: “file-count-migration-planning” locale: “de” tags: [“Migrationsplanung”, “Migrationszeit schätzen”, “NAS-Migration”, “IOPS”, “Datenmigration Sizing”, “Dateigrößenverteilung”, “Sysadmin”, “Performance”]

Dein Chef fragt: “Wie lange dauert die Migration?” Du prüfst die Dateianzahl. 1,2 Millionen Dateien. Du schätzt vier Stunden. Es dauert neunzehn.

Oder andersherum. Du sagst deinem Chef neunzehn Stunden, blockierst das Wochenende, verschickst die Wartungsankündigung an 400 User. Die Migration ist nach zwei Stunden fertig. Du wirkst, als hättest du keine Ahnung, was du tust.

Beides passiert, weil die Dateianzahl allein eine nutzlose Zahl ist. Sie sagt dir fast nichts darüber, wie lange die Migration tatsächlich dauern wird.

Eine Million Dateien können 80 GB oder 1,5 TB sein

Hier liegt das Problem. “1,2 Millionen Dateien” kann bedeuten:

• 1,2 Millionen winzige Config-Dateien mit durchschnittlich 4 KB. Gesamt: etwa 5 GB. Hauptsächlich Metadaten-Overhead.
• 1,2 Millionen Video-Renders mit durchschnittlich 400 MB. Gesamt: etwa 480 TB. Hauptsächlich reiner Durchsatz.

Gleiche Dateianzahl. Völlig andere Workloads. Völlig andere Zeitpläne. Völlig andere Engpässe.

Die Zahl, die wirklich zählt, ist die Größenverteilung: Wie viele Dateien fallen in welche Größenklasse, und wie viele Bytes entfallen auf jede Klasse?

Kleine Dateien: Tod durch tausend Opens

Wenn der Großteil deiner Daten aus kleinen Dateien (unter 128 KB) besteht, ist der eigentliche Datentransfer trivial. Eine Gigabit-Leitung schiebt 5 GB in unter einer Minute durch. Daran liegt es nicht.

Jede Datei erfordert:

1. open() auf der Quelle
2. stat() für Metadaten
3. open() + create() auf dem Ziel
4. write() der Daten (schnell, ist ja winzig)
5. chmod() für Berechtigungen
6. chtimes() für Timestamps
7. close() auf beiden Seiten

Mindestens sieben Syscalls pro Datei. Über NFS ist jeder davon ein Netzwerk-Round-Trip. Bei 1 ms pro Round-Trip (typisch im lokalen 10-GbE-Netz; bei Cross-Site-Links oder ausgelasteten Speichern eher 5–20 ms) sind das 7 ms pro Datei. Multipliziert mit einer Million Dateien: fast zwei Stunden reiner Overhead, bei kaum Datenvolumen.

Workloads mit kleinen Dateien sind IOPS-limitiert. Festplatte und Netzwerk schaffen die Bytes locker. Sie ersticken an den Operationen. Dein NAS schafft vielleicht 10.000 IOPS. Deine Million kleiner Dateien braucht 7 Millionen Operationen. Das sind fast 12 Minuten allein an IOPS, bei null Contention. In der Praxis, mit Metadaten-Journaling und Verzeichnis-Updates, verdreifache das.

Hinweis: Das sind zwei separate Engpässe — NFS-Netzwerklatenz und Storage-IOPS — und der schlimmere von beiden bestimmt dein tatsächliches Limit. Im lokalen LAN dominieren meist die Storage-IOPS. Über ein WAN die Netzwerklatenz.

Große Dateien: die Bandbreiten-Mauer

Dreh es um. Du hast 50.000 Dateien mit durchschnittlich 2 GB. Das sind 100 TB. Der Per-File-Overhead ist vernachlässigbar: 50.000 Opens und Closes sind nichts. Der Engpass ist der reine Durchsatz.

Auf einer 10-Gbps-Leitung liegt das theoretische Maximum bei etwa 1,1 GB/s. In der Praxis, mit NFS-Overhead, siehst du 400 bis 700 MB/s. Bei 500 MB/s dauern deine 100 TB etwa 55 Stunden. Keine IOPS-Optimierung ändert diese Zahl. Du brauchst schnellere Leitungen oder mehrere parallele Streams pro Datei.

Workloads mit großen Dateien sind durchsatzlimitiert. Mehr Worker helfen kaum, es sei denn, jeder Worker kann seinen eigenen Stream auslasten. Was hilft: größere TCP-Windows, größere NFS Read/Write-Sizes (rsize/wsize) und sicherstellen, dass dein Netzwerk nicht der Flaschenhals ist.

Die Verteilung ist entscheidend

Hier ein realistisches Beispiel von einem mittelgroßen Engineering-NAS:

Schau dir diese Zahlen an. 56 % der Dateien sind kleiner als 128 KB und machen gerade mal 1 % der Daten aus. Gleichzeitig entfallen auf 0,4 % der Dateien (die 1-GB+-Klasse) fast ein Viertel der Bytes. Deine Zeitschätzung muss beide Workloads berücksichtigen, die gleichzeitig laufen.

Profiliere dein Dataset, bevor du schätzt

Bevor du dich auf ein Cutover-Fenster festlegst, führe diese Befehle auf der Quelle aus. Dauert ein paar Minuten, erspart dir eine schlechte Schätzung.

Schnelle Dateianzahl nach Größenklasse:

find /path/to/data -type f -printf '%s\n' | awk '
  { s=$1;
    if (s < 4096)           { a++; ab+=s }
    else if (s < 131072)    { b++; bb+=s }
    else if (s < 10485760)  { c++; cb+=s }
    else if (s < 1073741824){ d++; db+=s }
    else                    { e++; eb+=s }
    total += s;
  }
  END {
    g=1073741824;
    printf "< 4KB:    %8d files  %8.1f GB\n", a, ab/g;
    printf "4K-128K:  %8d files  %8.1f GB\n", b, bb/g;
    printf "128K-10M: %8d files  %8.1f GB\n", c, cb/g;
    printf "10M-1G:   %8d files  %8.1f GB\n", d, db/g;
    printf "> 1GB:    %8d files  %8.1f GB\n", e, eb/g;
    printf "\nTotal: %d files, %.1f GB\n", a+b+c+d+e, total/g;
  }'

Top 20 der größten Dateien (dein Durchsatz-Engpass):

find /path/to/data -type f -printf '%s %p\n' | sort -rn | head -20

Verzeichnis mit den meisten Dateien (dein IOPS-Hotspot):

# Achtung: langsam bei großen Verzeichnisbäumen — startet eine Subshell pro Verzeichnis.
# Bei 100K+ Verzeichnissen kannst du mit 10-30 Minuten rechnen. Lohnt sich trotzdem.
find /path/to/data -type d -exec sh -c 'echo "$(find "$1" -maxdepth 1 -type f | wc -l) $1"' _ {} \; | sort -rn | head -10

Wie die Verteilung deine Tool-Konfiguration verändert

Wenn du deine Verteilung kennst, kannst du die Migration richtig tunen.

Überwiegend kleine Dateien (IOPS-limitiert):

• Mehr parallele Worker (8 bis 16). Jeder Worker bearbeitet ein anderes Verzeichnis.
• Kleinere Puffergrößen. Es bringt nichts, 64-MB-Puffer für 4-KB-Dateien zu allokieren.
• Dateien nach Verzeichnis gruppieren, um die Dentry-Cache-Lokalität auszunutzen.
• noatime-Mount-Optionen in Betracht ziehen, um Metadaten-Writes zu reduzieren.

Überwiegend große Dateien (durchsatzlimitiert):

• Weniger Worker (2 bis 4) mit größeren Stream-Puffern.
• NFS rsize/wsize auf 1 MB erhöhen (Standard ist oft 64 KB oder 256 KB).
• Netzwerk vorher mit iperf3 prüfen. Wenn die Leitung die Rate nicht halten kann, verursachen mehr Worker nur Congestion.
• Jumbo Frames aktivieren, wenn deine Switches das unterstützen. 9000 MTU reduziert den Per-Packet-Overhead deutlich bei großen sequentiellen Writes.

Gemischt (bimodal):

• Das sind die meisten realen Datasets. Du brauchst Worker, die beides können.
• Den Workload wenn möglich aufteilen: Verzeichnisse mit kleinen Dateien auf eine Gruppe Worker, Verzeichnisse mit großen Dateien auf eine andere.
• Die Gesamtzeit ist ungefähr: max(kleine_dateien_zeit, große_dateien_zeit), nicht die Summe, wenn du parallelisieren kannst.

Eine grobe Schätzformel

Das wird nicht perfekt, aber es ist besser als eine Schätzung allein auf Basis der Dateianzahl.

Für den Kleindateien-Anteil:

time_small = (dateianzahl × ops_pro_datei × latenz_pro_op) / parallele_worker

Aus der Tabelle oben: 670.000 Dateien unter 128 KB, 7 Ops pro Datei, 1,5 ms durchschnittliche NFS-Latenz, 8 Worker:

(670.000 × 7 × 0,0015) / 8 = 879 Sekunden ≈ 15 Minuten

Für den Großdateien-Anteil:

time_large = bytes_gesamt / (durchsatz_pro_stream × parallele_streams)

Aus der Tabelle: ~786 GB in Dateien über 10 MB, 400 MB/s pro Stream, 4 Streams:

786.000 MB / (400 × 4) = 491 Sekunden ≈ 8 Minuten

Gesamtschätzung: max(15, 8) = etwa 15 Minuten, wenn beides parallel läuft. Addiere 20 bis 30 % für Overhead (Verzeichniserstellung, Retries, Verifizierung). Nenne es 20 Minuten.

Vergleiche das mit der naiven Schätzung: “1,2 Millionen Dateien bei 2.000 Dateien/Sekunde = 10 Minuten.” Hier um den Faktor 2 daneben — und bei einem anderen Dataset könnte die naive Schätzung um den Faktor 5 daneben liegen.

Die richtige Antwort auf “Wie lange?”

Wenn dein Chef das nächste Mal fragt, sag nicht “1,2 Millionen Dateien.” Sag stattdessen:

Das ist eine Antwort, die du verteidigen kannst. “1,2 Millionen Dateien” ist es nicht.

Dein Chef muss nicht verstehen, was IOPS oder Throughput sind. Er muss sehen, dass du das Problem aufgeschlüsselt hast, den Engpass identifiziert hast und eine Zahl hast, die auf echten Daten basiert. Das Profilieren dauert fünf Minuten. Die Glaubwürdigkeit, die es dir bringt, ist den Aufwand wert.

Weiterführende Lektüre:

• NFS Mount Options Cheat Sheet (Tuning von rsize/wsize und Mount-Optionen)
• rsync vs rclone vs Robocopy (wie jedes Tool Parallelismus handhabt)
• 5 Signs Your Migration Tool Is Slowing You Down
• NFS vs SMB: Performance, Sicherheit & wann du was nutzt