Developers can now cut git clone times by nearly half and slash build times by over 20% on Windows 11, courtesy of a little-known feature called Dev Drive. Combining a tuned ReFS file system with a Microsoft Defender performance mode, Dev Drive targets the I/O-heavy inner loop of software development—but it requires a specific setup and discipline to use safely and effectively.

What Dev Drive Actually Is

Dev Drive is a purpose-built storage volume in Windows 11, first rolled out through Insider builds and now available in stable releases. It is not a general-purpose drive; Microsoft designed it specifically to host source code repositories, package caches, build outputs, and temporary files commonly generated during development.

At its core, Dev Drive relies on two powerful optimizations:

  1. ReFS with developer-centric tuning. Unlike the default NTFS file system, ReFS reduces metadata bottlenecks and accelerates directory operations. Microsoft engineers have retooled ReFS for the rapid creation and deletion of thousands of small files—the hallmark of a typical build—and added block cloning, a copy-on-write feature that makes duplicating large files nearly instantaneous.

  2. Microsoft Defender Performance Mode. Normally, Defender scans every file as it is opened, adding latency. On a Dev Drive designated as “trusted,” this synchronous scanning is replaced with a deferred, asynchronous model. Files are still protected, but the file-open operation returns immediately, and the scan runs in the background. The result: shorter wait times when toolchains hammer the disk.

These enhancements work together to remove friction from the inner loop of code, build, test, and iterate.

The Speed Gains Are Real—But Variable

Microsoft’s own testing, corroborated by community benchmarks, shows significant performance uplifts for common developer tasks. According to figures published on the Windows Developer Blog, a git clone of the NodeJS repository finished 41% faster on a Dev Drive. Building the OrchardCore project with .NET saw a 22% improvement, shaving about a minute off the total time.

For file-copy-heavy workloads, block cloning can be a game-changer. Microsoft demonstrated multi-second file copies completing in under a second once block cloning kicked in. That’s a huge win if your workflow regularly replicates large blobs or package caches.

However, these numbers are not universal guarantees. The actual boost depends on whether your project is I/O-bound or CPU-bound. A CPU-limited compilation will see only modest gains; meanwhile, a repository with hundreds of thousands of small files will feel the difference more acutely. Before committing, test your own baseline and compare.

Setting Up Your Own Dev Drive

Creating a Dev Drive is straightforward and does not require third-party tools. You have two options:

  • Physical partition: This directly uses unallocated space on your disk and delivers the best raw performance. The downside is less flexibility—it’s tied to that machine.
  • Virtual hard disk (VHD/VHDX): You create a dynamically expanding .vhdx file that mounts as a drive. Slightly slower due to the virtual disk layer, but you can resize it on the fly and back it up easily. Microsoft recommends against moving a VHD-based Dev Drive to a different PC and continuing to use it as a trusted volume, but the portability for backups is convenient.

Prerequisites

  • Windows 11 build with Dev Drive support (available in the latest stable releases).
  • At least 50 GB of free space.
  • 16 GB of RAM recommended (8 GB minimum).
  • Microsoft Defender up to date to enable Performance Mode.

Step-by-step creation

Method 1: Via Settings

  1. Go to Settings > System > Storage > Advanced storage settings > Disks & volumes.
  2. Select Create Dev Drive and follow the wizard. Choose between using unallocated space or creating a VHDX.
  3. Assign a drive letter and launch the drive.

Method 2: Via command line (Admin)

  • Format a physical partition: Format D: /DevDrv /Q
  • Or use PowerShell: Format-Volume -DriveLetter D -DevDrive

After creation, you must trust the drive to activate Defender Performance Mode. In an elevated command prompt, run:

fsutil devdrv trust D:

Verify the trust status with:

fsutil devdrv query D:

Once trusted, Windows automatically applies the asynchronous scanning policy.

What to Store (and What Not to)

Dev Drive’s security model hinges on one rule: only put files you trust on it. Microsoft’s official guidance breaks down clearly:

Good candidates for Dev Drive:

  • Source code repositories (Git clones)
  • Package manager caches (npm, NuGet, Maven)
  • Build outputs, intermediate files, and temporary directories

What should never go on a Dev Drive:

  • Random downloads or email attachments
  • Installed applications like Visual Studio or SDKs (keep those on C:)
  • The operating system itself (you can’t use C: as a Dev Drive anyway)

Stick to this model, and the security risk is minimal. Because the files are created by your toolchain or trusted collaborators, the attack surface is constrained. But if you start dumping unknown binaries onto the drive, you undermine the very mechanism that defers malware scans.

The Fine Print: Security and Limitations

Defender’s changed behavior. Performance mode does not disable Defender—it still scans files, just not synchronously during open/write operations. This means a newly saved malicious file might not be caught until a background scan runs. If you inadvertently download something suspicious directly to the Dev Drive, there could be a window of exposure. Discipline matters.

Performance is not magic. As noted, CPU-bound builds benefit less. Also, ReFS uses slightly more memory than NTFS; on a machine with only 8 GB of RAM, the overhead might be noticeable if you run memory-hungry tools.

Portability caveat. While you can copy a VHD-based Dev Drive to another machine, Microsoft advises against continuing to use it as a trusted Dev Drive on the new hardware without re-creating the trust and possibly reformatting. The intent is to prevent a drive’s trust designation from being exploited across devices.

Enterprise management. If you work in a managed environment, Group Policy or Intune policies may prevent you from designating a drive as trusted. Check with your IT admin before relying on Dev Drive in a corporate setting.

What’s Next for Dev Drive

Microsoft is actively refining the underlying technologies. Block cloning improvements have already appeared in recent Windows updates, and the ReFS team continues to tweak metadata operations for even lower latency. As Dev Drive matures, expect broader compatibility with additional development tools and possibly integration with Dev Home—though the latter app was recently deprecated, the underlying storage features remain a focus.

For now, Dev Drive is a pragmatic, well-supported optimization that can claw back minutes of waiting every day. A short pilot is the best way to see if it fits your workflow. Clone your most I/O-heavy repository onto a Dev Drive, time the usual tasks, and let the numbers decide. If you see a 20-40% improvement, the setup will pay for itself within the first week.