Langsame S3-Verzeichnisauflistung bei NetDrive beheben

Ein Backend-Team mountet einen Amazon-S3-Bucket über NetDrive als Windows-Laufwerksbuchstabe für seine CI-Fixture-Pipeline. Monatelang läuft alles reibungslos — bis ein Refactoring 40.000 neue Test-Fixture-Objekte unter einem einzigen S3-Präfix ablegt. Am nächsten Morgen hängt der Build 90 Sekunden während des Testaufbaus, während der Fixture-Ordner im Explorer befüllt wird. NetDrive hängt nicht; es führt 40 sequenzielle S3-API-Aufrufe aus, nur um dieses eine Verzeichnis aufzulisten.

S3-Buckets als natives Windows- oder macOS-Laufwerk mounten

Mit NetDrive erscheinen Google Drive, OneDrive, S3, SFTP, WebDAV und mehr als native Laufwerke unter Windows und macOS — ohne Synchronisation, ohne vollständige Downloads.

• S3-Buckets erscheinen als D:, E: oder ein beliebiger Laufwerksbuchstabe unter Windows
• Gecachte Verzeichnisauflistungen für schnelleren Wiederzugriff nach dem ersten Mount
• Erzwungene Aktualisierung bestimmter Ordner bei Änderungen der Objekte im Backend

WindowsmacOS

NetDrive herunterladen →

Kostenlose Testversion. Lifetime- und Abo-Pläne verfügbar.

Warum S3-Auflistung langsamer ist als ein lokales Dateisystem

S3 ist Objektspeicher, kein hierarchisches Dateisystem. Was wie ein Ordner namens fixtures/integration/ aussieht, ist ein gemeinsames Schlüsselpräfix — Tausende von Objektschlüsseln, die zufällig mit dieser Zeichenfolge beginnen. Es gibt keine echten Verzeichnisse. NetDrive (und jedes andere S3-Mount-Tool, einschließlich rclone und ExpanDrive) simuliert Verzeichnisse durch Aufrufe der S3-API ListObjectsV2.

Der Haken: Ein ListObjectsV2-Aufruf liefert höchstens 1.000 Objekte zurück. Ein Präfix mit 40.000 Schlüsseln benötigt 40 sequenzielle API-Aufrufe zur vollständigen Auflistung. Bei 50 ms pro Roundtrip zum S3-Endpunkt (realistisch innerhalb derselben AWS-Region) sind das 2 Sekunden reiner API-Overhead, bevor der erste Dateiname im Explorer erscheint. Über einen Unternehmensproxy oder zu einer anderen Region können sich diese 40 Aufrufe auf 30–90 Sekunden ausdehnen.

Das ist kein NetDrive-Fehler, sondern der S3-API-Vertrag — dasselbe Verhalten betrifft aws s3 ls, den Mount-Modus von rclone und jedes andere Tool, das große S3-Präfixe auflistet. Die Lösung liegt an zwei Stellen: wie NetDrive Verzeichnisauflistungen cacht und wie Sie Ihren Bucket strukturieren.

Wie der Verzeichnis-Cache von NetDrive wiederholten Overhead reduziert

Nach der ersten Auflistung eines großen Präfixes cacht NetDrive den Verzeichnisbaum lokal. Wenn ein Prozess das nächste Mal zu D:\fixtures\integration\ navigiert, liefert NetDrive die gecachte Auflistung ohne einen einzigen S3-API-Aufruf. Dieser Cache bleibt sitzungsübergreifend erhalten: Nach einem Kaltstart ist der Cache noch vom vorherigen Mount warm, sodass die Auflistung beim zweiten Durchlauf sofort erfolgt, selbst wenn Sie den Build-Server über Nacht neu gestartet haben.

Die Cache-Speichergröße ist bis zu 1 TB konfigurierbar (eingeführt in NetDrive 3.16.589). Bei einem Bucket mit Hunderttausenden von Objekten, verteilt auf Dutzende Präfixe, hält mehr Cache-Speicherplatz mehr vom Baum zwischen CI-Läufen warm. Passen Sie dies in den Laufwerkseinstellungen im Drive Manager an.

Der Kompromiss ist Veraltung. Wenn ein Kollege oder eine vorgelagerte Pipeline neue Objekte direkt zu S3 hochlädt — über die AWS-Konsole, ein separates Tool oder eine andere Maschine —, spiegelt die gecachte Ansicht von NetDrive diese Änderungen erst wider, wenn der Cache abläuft oder Sie eine Aktualisierung auslösen. Um einen bestimmten Ordner zu aktualisieren: Rechtsklick darauf im Windows Explorer → Refresh. NetDrive gibt den ListObjectsV2-Aufruf für dieses Präfix erneut aus, aktualisiert den Cache und liefert die aktuelle Auflistung zurück.

Bucket-Strukturänderungen, die den Auflistungs-Overhead reduzieren

Diese Korrekturen erfordern Änderungen daran, wie Sie Ihren S3-Bucket organisieren, zahlen sich aber für jedes Tool aus, das ihn liest — nicht nur für NetDrive.

Tiefe Präfix-Hierarchien abflachen. Jede Verschachtelungsebene, die Sie durchqueren, löst einen eigenen Auflistungsaufruf aus. Ein Pfad wie fixtures/integration/service-a/env-staging/2026/05/ hat sechs Ebenen — bis zu sechs sequenzielle API-Aufrufe, bevor Sie die Objekte erreichen. Flachen Sie ihn ab: fixtures/integration/service-a-staging-2026-05/ speichert dieselben Daten mit einem Auflistungsaufruf bis zum Blatt.

Präfixe mit hoher Kardinalität nach Zeit oder Kategorie partitionieren. Wenn ein einzelnes logs/-Präfix 80.000 Objekte über zwei Jahre täglicher Ausgabe umfasst, teilen Sie es in logs/2025/ und logs/2026/ auf. Wenn NetDrive logs/ auflistet, sieht es zwei Unterpräfixe in einem einzigen API-Aufruf. Die Navigation in logs/2026/ erfordert dann nur einen weiteren Aufruf für dieses Jahr.

Heiße und kalte Daten trennen. Halten Sie aktiv gelesene Objekte in einem begrenzten Präfix — fixtures/active/ — und archivieren Sie ältere in fixtures/archive/. CI-Pipelines, die den gesamten Bucket mounten, aber nur fixtures/active/ lesen, listen schnell; das kalte Archiv bleibt ungecacht und außerhalb des kritischen Pfads.

Einen Root-Pfad auf dem Laufwerk festlegen. In den S3-Verbindungseinstellungen von NetDrive lässt Sie das Feld Root path ein bestimmtes Präfix als Wurzel des Laufwerks mounten. Setzen Sie es auf fixtures/active, und NetDrive behandelt dieses Präfix als D:\. Der Rest des Buckets wird während der Mount-Sitzung nie aufgelistet — nur der Pfad, den Ihre Tools tatsächlich benötigen.

Die Endpunkt-Region überprüfen. Öffnen Sie die S3-Verbindung im Drive Manager und bestätigen Sie, dass die Region mit der Heimatregion Ihres Buckets übereinstimmt. Eine regionsübergreifende Anfrage fügt 50–200 ms pro API-Aufruf hinzu. Über 40 paginierte Auflistungsaufrufe sind das vermeidbare 2–8 Sekunden Netzwerklatenz bei jedem kalten Verzeichnisaufruf.

Fazit

Langsame S3-Verzeichnisauflistung ist fast immer ein Bucket-Strukturproblem, kein NetDrive-Konfigurationsproblem. Das Limit der S3-API von 1.000 Objekten pro Aufruf ist fest vorgegeben; was Sie kontrollieren, ist die Anzahl der Aufrufe, die nötig sind, um die von Ihren Tools benötigten Objekte zu erreichen. Flachen Sie tiefe Hierarchien ab, partitionieren Sie Präfixe mit hoher Kardinalität, legen Sie einen Root-Pfad fest, um den Mount einzugrenzen, und lassen Sie den Verzeichnis-Cache wiederholte Auflistungen sofort verfügbar machen.

Für Teams, die auf S3 eher Berechtigungsfehler als Leistungsprobleme haben, siehe S3 Access Denied Fehler mit NetDrive beheben. Wenn Ihre CI-Pipeline Wasabi statt AWS S3 verwendet, gilt dasselbe Auflistungsverhalten — siehe Wasabi unter Windows mit NetDrive mounten.

— Jay, NetDrive