Wenn du mit Speicherkarten arbeitest, ist dir vielleicht schon aufgefallen, dass das Schreiben oder Kopieren vieler kleiner Dateien oft länger dauert als bei einer einzelnen großen Datei. Das passiert in der Fotografie beim Ablegen tausender RAW-Bilder. Es tritt bei Videoaufzeichnungen auf, wenn die Kamera viele kurze Clips speichert. Es betrifft Smartphone-Backups, Überwachungskameras, USB-Sticks und sogar SD-Karten in Drohnen. Du siehst die Verzögerung beim Kopieren, beim Starten von Programmen oder beim Stitchen von Bildern.
Die Ursachen sind meist wiederkehrend. Wichtig sind Metadaten-Overhead. Jedes File braucht Einträge im Dateisystem. Wichtig sind auch zufällige Zugriffe im Gegensatz zu sequentiellen Zugriffen. Kleine Dateien führen oft zu vielen kleinen I/O-Operationen. Weiter spielt die Blockgröße und die interne Erase-Größe der Karte eine Rolle. All das kann zu Leistungsverlust führen, ohne dass die Karte selbst defekt ist.
In diesem Artikel lernst du, warum viele kleine Dateien langsamer sind. Du erfährst, welche Karte und welches Dateisystem für deine Anwendung sinnvoller sind. Du bekommst einfache Messmethoden und praktische Optimierungen. Außerdem zeige ich typische Einsparpotenziale. Erwarten kannst du spürbare Verbesserungen. Oft reichen schon einfache Einstellungen, um Lade- und Schreibzeiten um einige zehn Prozent zu reduzieren. In manchen Szenarien sind größere Gewinne möglich. Bleib dran, wenn du zuverlässigere Performance bei deinem Workflow willst.
Analyse: Warum kleine Dateien anders performen
Beim Umgang mit Speicherkarten sind zwei Zugriffsarten entscheidend. Sequentielle Zugriffe schreiben oder lesen Daten in einer fortlaufenden Reihenfolge. Das ist ideal für große Dateien. Zufällige Zugriffe springen zwischen vielen kleinen Blöcken hin und her. Das ist typisch bei vielen kleinen Dateien. Jede Datei bringt zusätzlichen Verwaltungsaufwand. Das Dateisystem legt Metadaten an. Jeder Eintrag erzeugt I/O. Zusätzlich bestimmt die physikalische Block- und Erase-Größe der NAND-Chips, wie viel intern tatsächlich geschrieben wird. Kleine Dateien können daher zu mehreren internen Schreibvorgängen führen. Das erhöht Latenz und Write Amplification. Auch das Wear-Leveling greift häufiger ein. Insgesamt sinkt die effektive Durchsatzrate.
| Aspekt |
Kleine Dateien |
Große Dateien |
| Zugriffsart |
Viele zufällige Lese-/Schreiboperationen |
Überwiegend sequentiell |
| Metadaten-Overhead |
Hoch. Jede Datei braucht Dateisystemeinträge. |
Niedrig. Weniger Einträge pro MB Daten. |
| Latenz |
Höher. Mehr I/O-Operationen mit Overhead. |
Niedriger. Kontinuierlicher Durchsatz. |
| Einfluss Dateisystem / Clustergröße |
Kleinere Cluster reduzieren Platzverlust. Größere Cluster senken Verwaltungsaufwand. |
Große Cluster oft ideal. Weniger Metadaten, bessere sequentielle Performance. |
| Wear-Leveling / Write Amplification |
Tendenziell schlechter. Viele kleine Schreibvorgänge erhöhen Write Amplification. |
Besser. Kontinuierliche Writes sind effizienter für NAND-Management. |
| Typische Benchmarks / realistische Messwerte |
Random 4K IOPS variieren stark. Effektive Durchsätze oft deutlich unter den sequenziellen Angaben. Beispiel: Random-Write-Werte können um mehrere Zehnerprozentpunkte niedriger ausfallen. |
Sequentielle Werte entsprechen eher den Herstellerangaben. Schreib-/Leseraten im Bereich von mehreren 10 bis 100+ MB/s je nach Karte. |
| Empfehlungen je Anwendungsfall |
Fotografie mit vielen RAWs: größere Cluster, schnelles Dateisystem, evtl. Archivierung in Containerdateien. |
Videoaufzeichnung: fokus auf sequentielle Schreibgeschwindigkeit und hohe Sustained-Rate. |
Pro und Contra bei vielen kleinen Dateien
Pro
- Einfachere Dateiverwaltung. Einzelne Dateien lassen sich gezielt entfernen.
- Flexible Nutzung. Einzelne Assets können direkt geöffnet oder bearbeitet werden.
Contra
- Höherer Metadatenaufwand. Das bremst bei Kopiervorgängen.
- Schlechtere Flash-Effizienz. Mehr Write Amplification und höhere Latenz.
- Bei Backup/Sync: viele kleine Dateien erhöhen die Zeit für Verzeichnis-Scans.
Zusammenfassend leidet die Performance bei vielen kleinen Dateien meist unter zusätzlichem Verwaltungsaufwand und der internen Arbeitsweise von NAND-Flash. Du kannst mit geeigneten Dateisystemeinstellungen, angepasster Clustergröße und geeigneten Workflows viel verbessern. In vielen Fällen reichen einfache Maßnahmen, um spürbar schneller zu arbeiten.
Hintergrund: Wie Flash funktioniert und warum das bei vielen kleinen Dateien wichtig ist
Empfehlung
31,99 €35,99 €
Preis inkl. MwSt., zzgl. Versandkosten
Empfehlung
19,99 €30,81 €
Preis inkl. MwSt., zzgl. Versandkosten
Empfehlung
6,69 €
Preis inkl. MwSt., zzgl. Versandkosten
Wie NAND-Flash aufgebaut ist
Flash-Speicher besteht aus vielen Speicherzellen, die in einer Hierarchie organisiert sind. Die kleinste adressierbare Einheit ist die Page. Mehrere Pages bilden einen Block. Daten werden sequentiell in Pages geschrieben. Gelöscht wird aber nur auf Block-Ebene. Das heißt, bevor eine Page neu beschrieben werden kann, muss der gesamte Block gelöscht werden. Moderne NAND-Generationen nutzen Pages von typischerweise einigen Kilobyte und Blocks mit mehreren hundert Kilobyte bis einigen Megabyte.
Page, Block und Erase-Granularität
Die Erase-Granularität beschreibt, dass Löschen nur pro Block möglich ist. Wenn du eine kleine Datei änderst, schreibt der Controller die neue Page an eine freie Stelle. Die alte Page bleibt zunächst bestehen. Später löscht der Controller den Block mit vielen Pages. Dieser Ablauf führt zu zusätzlicher Arbeit, wenn viele kleine Änderungen erfolgen.
Write Amplification und Wear-Leveling
Write Amplification bedeutet, dass intern mehr geschrieben wird als vom Betriebssystem gefordert. Ein kleiner 4 KB-Schreibzugriff kann dazu führen, dass mehrere hundert Kilobyte physisch bewegt werden. Das erhöht die Schreibmenge und reduziert die Lebensdauer des NAND. Deshalb gibt es Wear-Leveling. Der Controller verteilt Schreibzugriffe auf alle Blöcke, damit sich Abnutzung gleichmäßiger verteilt. Wear-Leveling hilft der Lebensdauer, erzeugt aber zusätzlichen internen Traffic, besonders bei vielen kleinen Dateien.
Cluster und Metadaten-IO im Dateisystem
Das Dateisystem teilt Speicher in Allocation Units oder Cluster ein. Übliche Clustergrößen sind 4 KB, 16 KB oder 32 KB. Kleine Cluster reduzieren Platzverschwendung bei vielen kleinen Dateien. Größere Cluster reduzieren dafür den Verwaltungsaufwand des Dateisystems. Jede Datei erzeugt Metadaten. Beispiele sind Verzeichnis-Einträge, Dateizuordnungen oder Journaleinträge. Das Lesen und Schreiben dieser Metadaten erzeugt zusätzliche I/O-Operationen. Bei vielen kleinen Dateien summiert sich das. Verzeichnis-Scans und Aktualisierungen der Zuordnungstabellen sorgen für zusätzlichen zufälligen Zugriff.
Unterschiede zwischen SD/SDHC/SDXC/UHS und USB-Flash
Die Begriffe SD, SDHC und SDXC beziehen sich vor allem auf Kapazitäts- und Formatgrenzen. Wichtiger für die Performance sind die Busstandards, zum Beispiel UHS-I, UHS-II oder UHS-III, und neuere Varianten wie SD Express. Sie bestimmen die maximale sequentielle Bandbreite. USB-Sticks nutzen die USB-Schnittstelle. Dort spielt die USB-Version eine Rolle und vor allem der interne Controller. Bei SD-Karten sind hochwertige Controller und Zwischencache üblich. Das verbessert sequentielle und teils auch zufällige Performance. Viele günstige USB-Sticks sparen an Controller und Cache. Sie erreichen oft akzeptable sequentielle Raten, liefern aber schlechte Random-IO-Leistung. Für Anwendungen mit vielen kleinen Dateien ist die Random-IO-Performance entscheidend.
Kurz gesagt, die Kombination aus physikalischer Erase-Granularität, Controller-Strategien und Dateisystem-Design erklärt, warum viele kleine Dateien langsamer sind. Wenn du das Zusammenspiel verstehst, kannst du Entscheidungen treffen, die Schreiblast und Latenz reduzieren.
Häufige Fragen: Viele kleine Dateien vs. große Dateien
Verlangsamen viele kleine Dateien meine SD-Karte?
Ja, das ist häufig der Fall. Viele kleine Dateien erzeugen zusätzlichen Metadaten-IO und viele zufällige Zugriffe, was die Latenz erhöht. Das liegt an der internen Page- und Block-Struktur von NAND-Flash und am Dateisystem. Oft ist die Karte nicht defekt, sondern die Arbeitsweise von Flash und Dateisysteme sorgt für den Leistungsverlust.
Empfehlung
19,99 €30,81 €
Preis inkl. MwSt., zzgl. Versandkosten
Empfehlung
39,99 €49,99 €
Preis inkl. MwSt., zzgl. Versandkosten
Empfehlung
31,99 €35,99 €
Preis inkl. MwSt., zzgl. Versandkosten
Wie messe ich den Leistungsverlust?
Du kannst standardisierte Benchmarks und einfache Kopiertests kombinieren. Nutze Tools wie CrystalDiskMark (Windows), Blackmagic Disk Speed Test (macOS), fio oder fio-Skripte auf Linux und teste sowohl sequentielle als auch Random-4K-IOPS. Ergänze das mit einem realen Test, etwa dem Kopieren von 10.000 kleinen Dateien gegenüber einer großen Datei gleicher Gesamtgröße. Achte darauf, einen Cardreader zu verwenden, der den Kartenbus (z. B. UHS) unterstützt.
Welche Dateisysteme helfen?
Die Wahl hängt vom Einsatz ab. Für SD-Karten in Kameras ist exFAT üblich und praktisch bei großen Dateien. Bei reinen Linux-Workflows bietet ext4 bessere Optionen zur Feinjustierung von Inodes und Clustergrößen. Generell gilt: Dateisysteme mit geringem Verwaltungsaufwand und passende Clustergrößen verbessern die Performance bei vielen Dateien.
Kann ich durch Formatieren oder Partitionieren verbessern?
Ja, formatieren kann helfen, wenn du passende Allocation-Unit-Größen wählst. Kleinere Cluster reduzieren Platzverlust, größere Cluster reduzieren Metadaten-Aufwand, also musst du den Kompromiss für deinen Anwendungsfall wählen. Partitionieren kann sinnvoll sein, um verschiedene Workloads zu trennen. Sichere vorher alle Daten, denn Formatieren löscht Dateien und bewirkt zusätzlichen Verschleiß, wenn du es zu oft machst.
Was soll ich beim Kauf beachten?
Achte nicht nur auf die beworbene sequentielle Geschwindigkeit. Für viele kleine Dateien sind Random-IOPS, die App-Klassen A1/A2 und eine gute Sustained-Write-Rate entscheidend. Such nach Karten mit aktuellem UHS- oder V-Klassen-Label und etablierten Herstellern wie SanDisk oder Samsung. Wenn möglich, lies realistische Tests zu Random-Performance statt nur Herstellerangaben.
Typische Anwendungsfälle: Wann die Dateigröße entscheidend ist
Serienbildfotografie
Bei Serienaufnahmen entstehen oft hunderte RAW- oder hochauflösende JPG-Dateien in kurzer Zeit. Jede Datei ist einzeln zu schreiben. Die Kamera füllt dazu einen internen Puffer. Ist die Schreibgeschwindigkeit der Karte zu niedrig, leert sich der Puffer nicht schnell genug. Das führt zu Verzögerungen zwischen den Serien oder zu Abbrüchen. Für dich bedeutet das weniger nutzbare Aufnahmen und eine schlechtere Trefferquote bei schnellen Motiven.
Empfehlung
26,99 €29,99 €
Preis inkl. MwSt., zzgl. Versandkosten
Empfehlung
18,99 €23,99 €
Preis inkl. MwSt., zzgl. Versandkosten
Empfehlung
6,69 €
Preis inkl. MwSt., zzgl. Versandkosten
4K-Videoaufzeichnung und lange Clips
Video arbeitet überwiegend sequentiell. Ein einzelner großer Container wird kontinuierlich beschrieben. Das ist freundlich für NAND-Flash. Solange die Sustained-Write-Rate der Karte ausreicht, gibt es kaum Probleme. Droht ein Leistungsabfall, entstehen Aufnahmeabbrüche oder Fragmentierung des Streams. Für Filmer sind konstante Schreibraten wichtiger als kurze Spitzenwerte.
Dashcams und Überwachungskameras
Hier werden viele kurze Clips oder kleine Dateiblöcke gespeichert. Häufige Schreib- und Löschzyklen sind die Norm. Das erhöht Write Amplification. Die Folge sind schnellerer Verschleiß und gelegentliche Verzögerungen beim Überschreiben alter Clips. In kritischen Situationen kann das dazu führen, dass relevante Sequenzen nicht lückenlos gespeichert werden. Langfristig kannst du die Lebensdauer der Karte spürbar reduzieren.
Mobile Apps und Cache-Dateien
Smartphones und Tablets legen viele kleine Cache- und Konfigurationsdateien an. Beim App-Start sind häufig tausende kleine Zugriffe nötig. Das wirkt sich auf App-Startzeiten und die Reaktionsgeschwindigkeit aus. Beim Wechsel von Speicher auf SD-Karten können Apps spürbar träger werden. Für Nutzer mit ausgeprägter Multitasking-Nutzung ist das ein echtes Komfortproblem.
Software-Distribution und Backup/Sync
Installer und Repositorien enthalten oft sehr viele kleine Dateien, Bibliotheken und Metadaten. Beim Kopieren oder Synchronisieren dauert das deutlich länger als bei wenigen großen Archiven. Backups und Cloud-Syncs brauchen mehr Zeit. Praktische Folgen sind längere Wartungsfenster, größere Ausfallzeiten bei Deployments und höhere Belastung beim Durchsuchen von Verzeichnissen.
In allen Szenarien ist das gemeinsame Problem dass viele kleine Dateien mehr Metadaten-IO erzeugen und mehr zufällige Zugriffe provozieren. Die Konsequenzen sind verzögerte Schreibvorgänge, höhere Latenz und schnellerer Verschleiß. Wenn du den konkreten Einsatzzweck kennst, kannst du gezielt Karten mit guter Random-Performance wählen oder Workflows so anpassen, dass Daten vor dem Schreiben gebündelt werden.
Entscheidungshilfe: Sollst du für viele kleine oder wenige große Dateien optimieren?
Welche Art von Zugriff dominiert deinen Workflow?
Überlege, ob du meist sequentiell große Dateien schreibst oder viele kleine Dateien verwaltest. Bei Videoaufnahmen ist der Zugriff sequentiell. Bei Fotoserien, App-Caches oder Software-Repos dominieren kleine zufällige Zugriffe. Die Antwort entscheidet über die wichtigsten Optimierungen.
Welche Hardware- und Softwaregrenzen gibt es?
Prüfe, ob deine Kamera, dein Smartphone oder dein Cardreader UHS-I, UHS-II oder höher unterstützt. Manche Geräte begrenzen die Schreibrate. Auch das Betriebssystem und das Dateisystem auf dem Zielgerät spielen eine Rolle. Wird die Hardware zum Flaschenhals, bringen Software-Änderungen wenig.
Wieviel Aufwand willst du in Anpassungen investieren?
Einfachere Maßnahmen sind Archivieren kleiner Dateien vor dem Kopieren oder das Verwenden schnellerer Kartenleser. Tiefere Eingriffe sind Formatieren mit anderen Clustergrößen oder Wechsel des Dateisystems. Wähle Maßnahmen nach Aufwand und erwarteter Nutzen.
Konkrete Empfehlungen
Für viele kleine Dateien: Nutze, wenn möglich, ein Dateisystem mit guter Random-IO wie ext4 oder f2fs auf Linux. Wähle Clustergrößen um 4 KB bis 8 KB, wenn Platzverlust ein Problem ist. Suche SD-Karten mit guter Random-IO und App-Klassen A1/A2. Verwende einen Cardreader, der den Kartenbus vollständig unterstützt.
Für große, sequentielle Dateien: Verwende exFAT auf SDXC für maximale Kompatibilität. Achte auf Karten mit hoher Sustained-Write-Rate und UHS- oder V-Klasse passend zur Auflösung (z. B. V30, V60).
Backup-Strategie: Bündle viele kleine Dateien in Archive (tar, zip) oder verwende inkrementelle Tools wie rsync oder deduplizierende Backups. Plane regelmäßige Backups und monitor die Kartenlebensdauer.
Unsicherheiten und praktische Tipps
Wenn Messdaten fehlen, führe einen einfachen Vergleichstest durch. Kopiere eine große Datei und dieselbe Datenmenge als viele kleine Dateien auf die Karte. Messe die Zeiten. Beachte Gerätelimitationen. Wenn die Hardware langsam ist, lohnt ein neues Karten- oder Reader-Modell mehr als langwierige Format-Experimente.
Do’s & Don’ts: So vermeidest du Leistungsverluste bei vielen kleinen Dateien
Die Tabelle fasst bewährte Maßnahmen zusammen, die die Performance bei vielen kleinen Dateien verbessern. Zu jeder sinnvollen Handlung steht das, was du vermeiden solltest.
| Do |
Don’t |
| Wähle passende Cluster- bzw. Allocation-Unit-Größe. Beim Formatieren Clustergröße an Dateigrößen anpassen, z. B. 4 KB bis 16 KB für viele kleine Dateien. |
Standardcluster ungeprüft lassen. Das führt zu unnötigem Metadaten-Overhead oder zu viel Platzverschwendung. |
| Bündle viele kleine Dateien vor dem Kopieren. Nutze Archive oder Containerdateien für Transport und Backup. |
Viele Einzeldateien direkt kopieren. Das verlängert Kopierzeiten und erhöht Metadaten-IO. |
| Setze auf Karten mit guter Random-IO und App-Klassen. Achte auf A1/A2 Ratings und realistische Random-IO-Tests. |
Billige No-Name-Karten kaufen. Günstige Modelle sparen am Controller und liefern oft schlechte Random-Performance. |
| Nutze einen schnellen, bus-kompatiblen Cardreader. Ein Reader mit UHS-Unterstützung verhindert Flaschenhälse. |
Alte USB2-Reader oder langsame Leser verwenden. Das limitiert die real erreichbare Geschwindigkeit. |
| Regelmäßig sichern und Karte pflegen. Alte Dateien löschen, Backups planen und Karten nicht dauerhaft voll laufen lassen. |
Karte dauerhaft voll lassen ohne Pflege. Volle Karten erhöhen Fragmentierung und Schreiblatenz. |
| Optimier Workflows für weniger Random-Writes. Verwende Caches, lokale Datenbanken oder batchweises Schreiben. |
Ständig kleine Write/Delete-Zyklen provozieren. Häufige Einzeloperationen erhöhen Write Amplification und Verschleiß. |
