Исправление медленного листинга каталогов S3 в NetDrive

Команда бэкенд-разработки монтирует бакет Amazon S3 как букву диска Windows через NetDrive для своего конвейера CI-фикстур. Всё работает безупречно месяцами — пока рефакторинг не добавляет 40 000 новых объектов тестовых фикстур под одним префиксом S3. На следующее утро сборка зависает на 90 секунд во время настройки тестов, ожидая заполнения каталога фикстур в Проводнике. NetDrive не завис — он делает 40 последовательных вызовов API S3, просто чтобы перечислить содержимое этого одного каталога.

Монтируйте бакеты S3 как нативный диск Windows или macOS

NetDrive показывает Google Drive, OneDrive, S3, SFTP, WebDAV и другие хранилища как обычные диски в Windows и macOS — без синхронизации и полной загрузки файлов.

• Бакеты S3 отображаются как D:, E: или любая другая буква диска в Windows
• Кешированные листинги каталогов для более быстрого повторного доступа после первого монтирования
• Принудительное обновление отдельных папок при изменении объектов в источнике

WindowsmacOS

Скачать NetDrive →

Бесплатный пробный период. Доступны бессрочная лицензия и подписка.

Почему листинг S3 медленнее, чем у локальной файловой системы

S3 — это объектное хранилище, а не иерархическая файловая система. То, что выглядит как папка с именем fixtures/integration/, на самом деле — общий префикс ключа: тысячи ключей объектов, начинающихся с этой строки. Реальных каталогов не существует. NetDrive (как и любой другой инструмент монтирования S3, включая rclone и ExpanDrive) имитирует каталоги, вызывая API S3 ListObjectsV2.

Загвоздка в том, что один вызов ListObjectsV2 возвращает не более 1000 объектов. Префикс с 40 000 ключей требует 40 последовательных вызовов API для полного перечисления. При 50 мс на один round-trip к эндпоинту S3 (разумное значение в пределах одного региона AWS) это 2 секунды чистых накладных расходов на API, прежде чем в Проводнике отобразится первое имя файла. Через корпоративный прокси или в другой регион эти 40 вызовов могут растянуться до 30–90 секунд.

Это не ошибка NetDrive. Так устроен контракт API S3 — то же самое поведение затрагивает aws s3 ls, режим монтирования rclone и любой другой инструмент, листающий большие префиксы S3. Решение лежит в двух местах: в том, как NetDrive кеширует листинги каталогов, и в том, как вы структурируете свой бакет.

Как кеш каталогов в NetDrive снижает накладные расходы при повторном доступе

После первого листинга большого префикса NetDrive кеширует дерево каталогов локально. При следующем переходе любого процесса в D:\fixtures\integration\ NetDrive возвращает кешированный листинг без единого вызова API S3. Этот кеш сохраняется между сессиями: после холодной перезагрузки кеш всё ещё тёплый с предыдущего монтирования, поэтому листинг при повторном запуске мгновенный, даже если вы перезапустили сервер сборки за ночь.

Размер хранилища кеша настраивается вплоть до 1 ТБ (появилось в NetDrive 3.16.589). Для бакета с сотнями тысяч объектов, распределённых по десяткам префиксов, выделение большего объёма кеша позволяет держать больше дерева «тёплым» между запусками CI. Настройте это в параметрах диска в Drive Manager.

Плата за это — устаревание данных. Если коллега или вышестоящий конвейер загружает новые объекты в S3 напрямую — через консоль AWS, отдельный инструмент или другую машину — кешированное представление NetDrive не будет отражать эти изменения, пока кеш не истечёт или вы не запустите обновление вручную. Чтобы обновить конкретную папку: щёлкните по ней правой кнопкой в Проводнике Windows → Refresh. NetDrive заново выполняет вызов ListObjectsV2 для этого префикса, обновляет кеш и возвращает актуальный листинг.

Изменения структуры бакета, снижающие накладные расходы на листинг

Эти исправления требуют изменений в организации вашего бакета S3, но окупаются для любого инструмента, который его читает, — не только для NetDrive.

Упрощайте глубокие иерархии префиксов. Каждый уровень вложенности, по которому вы переходите, запускает отдельный вызов листинга. Путь вида fixtures/integration/service-a/env-staging/2026/05/ имеет шесть уровней — до шести последовательных вызовов API, прежде чем вы дойдёте до объектов. Упростите его: fixtures/integration/service-a-staging-2026-05/ хранит те же данные с одним вызовом листинга для доступа к конечным объектам.

Разбивайте префиксы с высокой кардинальностью по времени или категории. Если один префикс logs/ содержит 80 000 объектов за два года ежедневного вывода, разделите его на logs/2025/ и logs/2026/. Когда NetDrive листает logs/, он видит два подпрефикса за один вызов API. Переход в logs/2026/ затем требует ещё одного вызова только для этого года.

Разделяйте горячие и холодные данные. Держите активно читаемые объекты в ограниченном префиксе — fixtures/active/ — а более старые архивируйте в fixtures/archive/. Конвейеры CI, которые монтируют весь бакет, но читают только fixtures/active/, листают быстро; холодный архив остаётся некешированным и вне критического пути.

Задайте корневой путь диска. В настройках подключения S3 в NetDrive поле Root path позволяет смонтировать определённый префикс как корень диска. Установите его в fixtures/active, и NetDrive будет обрабатывать этот префикс как D:\. Остальная часть бакета никогда не листается в течение сессии монтирования — только тот путь, который действительно нужен вашим инструментам.

Проверьте регион эндпоинта. Откройте подключение S3 в Drive Manager и убедитесь, что регион совпадает с домашним регионом вашего бакета. Межрегиональный запрос добавляет 50–200 мс к каждому вызову API. При 40 постраничных вызовах листинга это до 2–8 секунд лишней сетевой задержки при каждом холодном открытии каталога.

Итог

Медленный листинг каталогов S3 почти всегда является проблемой структуры бакета, а не настройки NetDrive. Лимит API S3 в 1000 объектов на вызов фиксирован; вы же контролируете, сколько вызовов требуется, чтобы добраться до нужных объектов. Упрощайте глубокие иерархии, разбивайте префиксы с высокой кардинальностью, задавайте корневой путь для сужения области монтирования и позволяйте кешу каталогов делать повторные листинги мгновенными.

Если вы сталкиваетесь с ошибками доступа к S3, а не с проблемами производительности, см. Fix S3 Access Denied Error with NetDrive. Если ваш конвейер CI использует Wasabi вместо AWS S3, то же поведение листинга применимо — см. Mount Wasabi on Windows with NetDrive.

— Jay, NetDrive