Dev Drive & Defender

Moving Your Repo/Package Caches to Dev Drive Safely

Developers and power users spend a lot of time pulling source, compiling, unpacking archives, and shuttling tiny files around. On Windows 11, the Dev Drive feature is designed specifically to accelerate those workloads by combining a ReFS-based volume with Microsoft Defender’s optimized scanning path known as Defender Performance Mode. This guide shows you how to safely move your code repositories and package caches onto a Dev Drive so you get the performance benefits without breaking your workflow.

We’ll cover what Dev Drive is, when it helps, how to set it up, how to migrate common language and build caches (npm, pnpm, yarn, pip, NuGet, vcpkg, cargo, Gradle, Maven, Go, Android SDK, etc.), troubleshooting tips, and best practices. The goal is a safe, repeatable migration that’s easy to maintain.

Contents show

What is Dev Drive and why it matters

Dev Drive is a developer-focused volume type in Windows 11 built on ReFS (Resilient File System). It’s optimized for developer workloads that create, delete, and modify many small files rapidly—think Git repos, node_modules, package registries, build outputs, and intermediate files. Dev Drive integrates with Microsoft Defender’s Performance Mode to reduce overhead from real-time antivirus scans while maintaining protection.

Typical benefits:

  • Faster Git operations (clone, checkout, status on repos with many small files)
  • Speedier Node/Java/.NET/Rust/Python builds and installs
  • Reduced I/O overhead for dependency caches
  • More predictable build times on CI-like developer machines

This guide helps you safely migrate the “churn” — repos and caches — to a Dev Drive, so you can realize gains without making your system fragile.

When Dev Drive helps: common scenarios

  • Large repos and monorepos (e.g., web frontends with tens of thousands of source files)
  • Toolchains that unpack large dependency graphs (npm/pnpm/yarn, pip, NuGet, Gradle/Maven, vcpkg, cargo)
  • Build systems that produce many intermediate files (C/C++, Unreal, Java/Kotlin, Rust)
  • CI-like local workflows that repeatedly clean and rebuild

Quick reference: commands and checks

Command Purpose Example Output
winver Check Windows version/build Version 23H2 (OS Build 22631.XX)
Get-ComputerInfo -Property OsName,OsVersion,OsBuildNumber Check detailed OS info OsName: Microsoft Windows 11 Pro; OsBuildNumber: 22631
Get-Volume List volumes, confirm drive letter and FS DriveLetter D FileSystem ReFS HealthStatus Healthy
New-DevDriveVolume -DriveLetter D -Size 200GB -Label “DevDrive” Create a Dev Drive via PowerShell (if available) Returns a MSFT_Volume object with FileSystem = ReFS
fsutil integrity query D:\ Verify integrity streams (should be disabled for performance) “Integrity streams are disabled”
fsutil behavior query DisableDeleteNotify Confirm TRIM (SSD) is enabled ReFS: 0 (Disabled = TRIM enabled)
Get-MpComputerStatus Defender status (real-time on?) RealTimeProtectionEnabled: True
npm config get cache See current npm cache path C:\Users\you\AppData\Local\npm-cache
pip cache dir Show pip cache location C:\Users\you\AppData\Local\pip\Cache
dotnet nuget locals all –list Show NuGet caches global-packages: C:\Users\you.nuget\packages
cargo env Show cargo home CARGO_HOME not set, defaulting to C:\Users\you.cargo
See also  Dev Drive “Trust” Requirements Explained (and How to Satisfy Them)

Setup and key concepts

Prerequisites

  • Windows 11, ideally version 23H2 or later
  • Administrative rights to create volumes or VHDX files
  • At least 50 GB of available storage for a dedicated Dev Drive (Microsoft’s guidance)
  • Preferably an SSD/NVMe drive for best results
  • Microsoft Defender Antivirus running in active mode to enable Defender Performance Mode (you can still use Dev Drive without it, but with less benefit)

To check version:

  • Press Win+R, type winver, press Enter.
  • Or PowerShell: Get-ComputerInfo -Property OsName,OsVersion,OsBuildNumber

What Dev Drive actually does

  • Uses ReFS, which is optimized for reliability and large-scale file operations.
  • Sets volume defaults for developer workloads (like disabling ReFS integrity streams on user data paths to reduce overhead).
  • Enables Defender Performance Mode automatically when Microsoft Defender is the active AV engine. This reduces the cost of scanning enormous numbers of ephemeral small files without disabling your protection.

Note: Not every NTFS feature exists on ReFS. Most developer workflows are unaffected, but if a specific tool requires an NTFS-only feature, consider keeping that tool’s data on NTFS or testing first.

Enabling Dev Drive and Defender Performance Mode

There are multiple paths to create a Dev Drive:

  • Settings: System > Storage > Advanced storage settings > Disks & volumes > Create Dev Drive
  • Dev Home app (Microsoft’s developer dashboard) > Machine configuration > Dev Drive
  • PowerShell cmdlets (New-DevDriveVolume) on supported builds
  • Creating a VHDX and formatting it as a Dev Drive through the wizard

To confirm Defender Performance Mode:

  • Open Windows Security > Virus & threat protection > Manage settings.
  • Ensure “Performance mode for Dev Drive” is On.
  • If using third-party AV, Performance Mode may not activate. You can still use Dev Drive but consider switching to Defender active mode if you want the full performance benefit.

Step-by-step: Create a Dev Drive and migrate repos/caches

1) Create the Dev Drive

Option A: Settings UI (recommended for most users)

  1. Open Settings > System > Storage.
  2. Click Advanced storage settings > Disks & volumes.
  3. Click Create Dev Drive and follow the wizard.
  4. Choose size (e.g., 200 GB), drive letter (e.g., D:), and label (e.g., DevDrive).

Option B: PowerShell (if the cmdlet is available on your build)

  • Run PowerShell as Administrator:

Example: create a 200 GB Dev Drive on free space (if supported)

New-DevDriveVolume -DriveLetter D -Size 200GB -Label “DevDrive”

Option C: Create a VHDX-backed Dev Drive (works well on laptops)

  • Run PowerShell as Administrator:

1) Create a dynamic VHDX

New-VHD -Path “C:\DevData\DevDrive.vhdx” -SizeBytes 250GB -Dynamic

2) Mount it

Mount-VHD -Path “C:\DevData\DevDrive.vhdx”

3) Initialize and create a partition

$disk = Get-Disk | Where-Object PartitionStyle -Eq ‘RAW’ | Select-Object -First 1
Initialize-Disk -Number $disk.Number -PartitionStyle GPT
New-Partition -DiskNumber $disk.Number -DriveLetter D -UseMaximumSize | Out-Null

4) Use the Dev Drive wizard in Settings/Dev Home to format as Dev Drive (ReFS)

If not available, format ReFS (if your SKU allows), then set Dev Drive properties via UI.

Notes:

  • On some editions, formatting arbitrary ReFS volumes from command-line may be restricted. Prefer the Dev Drive wizard, which handles policy and correct defaults.
  • If PowerShell New-DevDriveVolume is not present, your system may not have the module; use the Settings or Dev Home route.

2) Verify ReFS integrity settings and SSD TRIM

Integrity streams should be disabled on your Dev Drive data paths for performance

fsutil integrity query D:\

TRIM should be enabled for ReFS (0 = enabled)

fsutil behavior query DisableDeleteNotify

If needed, you can disable integrity on specific hot folders (most Dev Drives do this automatically):

fsutil integrity set D:\repos disable
fsutil integrity set D:\pkgcache disable

3) Create a sensible folder layout

Keep paths short to avoid MAX_PATH issues and to speed up deep directory operations.

  • D:\repos
  • D:\pkgcache\npm
  • D:\pkgcache\pnpm
  • D:\pkgcache\yarn
  • D:\pkgcache\pip
  • D:\pkgcache\nuget
  • D:\pkgcache\vcpkg
  • D:\pkgcache\cargo
  • D:\pkgcache\gradle
  • D:\pkgcache\maven
  • D:\pkgcache\go
  • D:\sdk\android
  • D:\tools (optional)
See also  Dev Drive vs NTFS: Real-World Git/Node Build Benchmarks

mkdir D:\repos
mkdir D:\pkgcache
mkdir D:\sdk

4) Migrate package caches (safe and reversible)

Use the official configuration knobs for each tool so your change survives updates and is easy to undo. If a tool doesn’t support changing paths, you can fall back to a junction/symlink.

Node.js

  • npm:

npm config set cache D:\pkgcache\npm –global
npm config set prefix D:\pkgcache\npm-global –global

Optional: node-gyp devdir (headers)

npm config set devdir D:\pkgcache\node-gyp –global

  • pnpm:

pnpm config set store-dir D:\pkgcache\pnpm

Global executables: set PNPM_HOME env var

setx PNPM_HOME D:\pkgcache\pnpm-home

  • yarn (v1):

yarn config set cacheFolder D:\pkgcache\yarn

Python

  • pip (config or env var):

Show current cache

pip cache dir

Set via config

pip config set global.cache-dir D:/pkgcache/pip

Or via environment:

setx PIP_CACHE_DIR D:\pkgcache\pip

  • Poetry:

setx POETRY_CACHE_DIR D:\pkgcache\poetry

  • pipenv (uses pip cache); you can also set virtualenv location if desired:

setx WORKON_HOME D:\pkgcache\virtualenvs

.NET and NuGet

  • NuGet global packages and HTTP cache:

Show current

dotnet nuget locals all –list

Set via environment variables

setx NUGET_PACKAGES D:\pkgcache\nuget\packages
setx NUGET_HTTP_CACHE_PATH D:\pkgcache\nuget\http

  • Or set globalPackagesFolder/httpCache path in a global NuGet.config if you prefer configuration over env vars.

C/C++ and CMake ecosystems

  • vcpkg:

setx VCPKG_DEFAULT_BINARY_CACHE D:\pkgcache\vcpkg\binarycache
setx VCPKG_DOWNLOADS D:\pkgcache\vcpkg\downloads

Rust

  • cargo and rustup:

setx CARGO_HOME D:\pkgcache\cargo
setx RUSTUP_HOME D:\pkgcache\rustup

Java/Kotlin

  • Gradle:

setx GRADLE_USER_HOME D:\pkgcache\gradle

  • Maven (edit settings.xml or set env var for local repo):

Option A: environment variable for user repo:

setx M2_REPO D:\pkgcache\maven\repository

Option B: define D:\pkgcache\maven\repository in %USERPROFILE%.m2\settings.xml

Go

  • module cache lives under GOPATH:

setx GOPATH D:\pkgcache\go

Android

  • Android SDK/NDK:

setx ANDROID_SDK_ROOT D:\sdk\android
setx ANDROID_HOME D:\sdk\android

Bazel

setx BAZEL_OUTPUT_BASE D:\pkgcache\bazel

After setting environment variables, close and reopen terminals/IDEs so changes take effect. For some tools, moving existing cache content to the new location can save re-download time:

robocopy C:\Users\%USERNAME%\AppData\Local\npm-cache D:\pkgcache\npm /E /MOVE

Fallback: junctions/symlinks if a tool ignores config

  • Identify the current cache folder.
  • Move it to Dev Drive, then create a junction pointing to the new location:

Example for a stubborn cache at C:\Users\you\AppData\Local\tool\cache

robocopy “C:\Users\you\AppData\Local\tool\cache” “D:\pkgcache\tool” /E /MOVE
mklink /J “C:\Users\you\AppData\Local\tool\cache” “D:\pkgcache\tool”

Tip: Enable Developer Mode in Windows to create symlinks without elevation (Settings > System > For developers).

5) Move your repos

The simplest approach is to clone new repositories directly to D:\repos.

To migrate existing repos:

  • Close any IDEs/terminals using the repo.
  • Move the repo directory:

robocopy C:\work\myrepo D:\repos\myrepo /E /MOVE

  • Update any scripts or tools that reference absolute paths.

6) Optional: Git performance tunings

On top of Dev Drive, these Git settings often help on Windows:

Enable built-in FSMonitor to speed up status

git config –global core.fsmonitor true

Improve performance when there are many files

git config –global feature.manyFiles true

Allow long paths if you still use deep trees

git config –system core.longpaths true

Benchmark example (PowerShell):

Measure clone time on C: vs D:

Measure-Command { git clone https://github.com/microsoft/vcpkg C:\temp\vcpkg-c }
Measure-Command { git clone https://github.com/microsoft/vcpkg D:\repos\vcpkg-d }

Measure npm install in a repo

cd D:\repos\yourwebapp
Measure-Command { npm ci }

Example (illustrative) output:

  • Clone to C:: 00:01:38.452
  • Clone to D: (Dev Drive): 00:01:09.213
  • npm ci on C:: 00:02:47.005
  • npm ci on D:: 00:02:03.774

Your mileage will vary based on hardware, antivirus, and repo size.

Troubleshooting

Cannot create Dev Drive in Settings (button greyed out)

  • Ensure you’re on Windows 11 23H2 or later.
  • You need at least ~50 GB free contiguous space or use a VHDX-backed Dev Drive.
  • Some enterprise policies may restrict ReFS/Dev Drive. Contact your admin.

Dev Drive created but “trust not satisfied” or Performance Mode off

  • Defender Performance Mode requires Microsoft Defender Antivirus to be the active AV. If a third-party AV is active, Performance Mode won’t engage.
  • Open Windows Security > Virus & threat protection > Manage settings and check for Performance Mode. If managed by your organization or disabled by other AV, consider switching to Defender active mode (or accept reduced benefit).

ReFS format fails from command line

  • Some SKUs block ad-hoc ReFS formatting. Use the Dev Drive wizard in Settings or Dev Home, which provisions the volume with the right policies even when generic ReFS formatting is restricted.

Git status or checkout still slow

  • Enable Git FSMonitor:

git config –global core.fsmonitor true

  • Ensure your repo is on the Dev Drive, not just your caches.
  • Avoid placing the repo in a folder with inherited EFS encryption or compression policies.
  • Verify Defender Performance Mode is on; avoid adding blanket exclusions that reduce safety.

NPM/Python/Gradle still using old cache path

  • Close and reopen your shell/IDE after setting environment variables.
  • Confirm with each tool’s “show config” command:
    • npm config get cache
    • pip config list / pip cache dir
    • gradle properties (look for Gradle user home)
  • If needed, use a junction/symlink as a compatibility backstop.
See also  Speed Up pnpm/npm/yarn Caches with ReFS Dev Drive

Permission or path issues after moving

  • Avoid spaces and very long paths in cache roots (e.g., D:\pkgcache…).
  • Fix permissions if needed:

icacls D:\pkgcache /grant %USERNAME%:(OI)(CI)F

  • Enable long paths system-wide if you work with deep trees:
    • Local Group Policy: Computer Configuration > Administrative Templates > System > Filesystem > Enable Win32 long paths = Enabled
    • Or registry: HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled = 1

Symlinks/junctions fail to create

  • Enable Developer Mode (Settings > System > For developers).
  • Or run Command Prompt as Administrator.
  • Verify:

fsutil behavior query SymlinkEvaluation

Performance tips & best practices

Recommended folder layout

  • Keep a short, flat structure: D:\repos and D:\pkgcache\.
  • Avoid deep nesting and long file names in dependency trees when possible.
  • Use a dedicated Dev Drive for repos and caches; keep system files on C:.

Leverage Defender Performance Mode, do not disable protection

  • The core benefit is that Defender Performance Mode reduces scanning overhead on Dev Drive workloads while maintaining security.
  • Avoid blanket exclusions of entire drives in Defender; rely on Performance Mode to balance performance and safety.

ReFS integrity streams

  • For hot paths like node_modules, NuGet packages, and build outputs, ensure ReFS integrity streams are disabled (Dev Drive defaults do this).
  • Check and set per-folder if needed:

fsutil integrity query D:\pkgcache\npm
fsutil integrity set D:\pkgcache\npm disable

Use SSD/NVMe and keep TRIM enabled

  • Check TRIM:

fsutil behavior query DisableDeleteNotify

  • ReFS: 0 indicates TRIM enabled.

Prefer configuration over symlinks

  • Changing tool config (env vars or config files) is more maintainable than junctions/symlinks.
  • Use junctions/symlinks only when a tool cannot be configured.

Benchmark method

  • Use PowerShell’s Measure-Command for apples-to-apples comparisons.
  • Test representative workloads: git clone, npm ci, gradle build, dotnet restore/build.
  • Run each test 2–3 times and take the best/median to minimize noise.

Keep paths stable

  • Choose a drive letter and keep it consistent (e.g., D:).
  • If using a VHDX Dev Drive, configure it to auto-mount at boot.

Be mindful of ReFS vs NTFS differences

  • Most dev workflows work fine on ReFS-based Dev Drive.
  • If a tool explicitly requires NTFS-only features, keep that data on NTFS and move only compatible repos/caches to Dev Drive.

Maintenance

  • Periodically clear stale caches to save space:

npm cache clean –force
pip cache purge
dotnet nuget locals all –clear

  • Monitor space with:

Get-ChildItem D:\pkgcache -Recurse | Measure-Object -Property Length -Sum

Conclusion

Moving your repositories and package caches to a Dev Drive on Windows 11 is one of the highest-impact changes you can make for everyday developer performance. You’ll reduce I/O overhead and get the benefit of Defender Performance Mode without sacrificing security. By using the official configuration settings for each tool, the migration is safe, reversible, and easy to maintain. With the step-by-step guidance above, you can create a Dev Drive, move your hot paths, and immediately start seeing faster clones, installs, and builds.

FAQ

Do I need Microsoft Defender for Dev Drive to help?

Dev Drive works with any antivirus, but its biggest gains come when Microsoft Defender is the active AV so Performance Mode can kick in. If you use a third-party AV, Dev Drive still helps (ReFS layout and integrity defaults), just expect smaller improvements.

Can I create a Dev Drive on Windows 11 Home?

The Dev Drive feature is in Windows 11 23H2 and later. Creation via the Settings/Dev Home wizard is the most reliable method across editions. Direct ReFS formatting from command line may be restricted on some SKUs; use the Dev Drive wizard.

Is ReFS safe for my source code and builds?

Yes. ReFS is designed for reliability. Dev Drive disables integrity streams for user data folders to improve performance, which is fine for ephemeral build artifacts and caches. Your data remains protected by Defender; Performance Mode is optimized, not disabled protection.

Should I move my entire development environment to Dev Drive?

Move the “churn”: repos, caches, and build outputs. Keep Windows, Program Files, and other system components on C:. If a tool is sensitive to specific file system semantics, test it on Dev Drive before fully migrating.

What if a tool doesn’t let me change cache paths?

Use a junction or symlink as a backstop: move the folder to Dev Drive, then create a junction at the original path pointing to the new location. Prefer official tool configuration when available for long-term maintainability.

About the author

Jonathan Dudamel

Jonathan Dudamel

I'm Jonathan Dudamel, an experienced IT specialist and network engineer passionate about all things Windows. I have deep expertise in Microsoft project management, virtualization (VMware ESXi and Hyper-V), and Microsoft’s hybrid platform. I'm also skilled with Microsoft O365, Azure ADDS, and Windows Server environments from 2003 through 2022.

My strengths include Microsoft network infrastructure, VMware platforms, CMMS, ERP systems, and server administration (2016/2022).