Docker and WSL2 Performance: RAM Disk and Disk Cache Tips

Running Linux containers on Windows 11 means running a small Linux system underneath, and that system keeps everything in virtual disk files: an ext4.vhdx for WSL2 and a separate data disk for Docker. Those files grow into tens of gigabytes, are read and written constantly, and sit on whatever drive your profile happens to live on. When containers feel sluggish or builds crawl, storage is usually the reason.

This guide explains where the I/O actually goes, how to cache the drive that holds those virtual disks, and how to move short-lived build traffic into memory where it belongs.

PAGE CONTENT

• Why Docker and WSL2 Are Storage-Heavy
• Where the Bottleneck Comes From
• Step 1: Cache the Drive That Holds the Virtual Disks
• Step 2: Keep Project Files in the Linux File System
• Step 3: Move Build Temp into Memory
• Step 4: Trim, Exclude, and Measure
• FAQs About Docker and WSL2 Speed
• Back Up Windows Before You Change Settings

Why Docker and WSL2 Are Storage-Heavy

Neither tool is a normal application that reads a few files and runs. WSL2 boots a real Linux kernel in a lightweight virtual machine, and Docker Desktop runs on top of it. Both keep their entire file system inside a virtual disk that Windows sees as one enormous file.

That single file is where the trouble starts:

• Every operation inside Linux becomes I/O on that file. Installing a package, extracting a layer, or writing a log all translate into reads and writes on the host disk.
• The file grows and rarely shrinks. Deleted data inside Linux does not automatically return space to Windows, so the vhdx keeps expanding.
• Containers are built from layers. Pulling an image writes many files, and building one writes them again.
• Build caches accumulate. Package caches, image layers, and dependency stores add up to gigabytes that are read repeatedly.

Where the Bottleneck Comes From

Before changing anything, know which of these applies to you:

• The drive holding the virtual disks is slow. By default WSL2 and Docker data live on the system drive. If that is a hard drive, or a full SSD, everything is slow.
• Files are accessed across the Windows and Linux boundary. Working on code that sits in C:\Users\... from inside Linux means every file operation crosses two file systems, which is dramatically slower than working natively inside Linux.
• Antivirus scans the virtual disk. Real-time scanning of a multi-gigabyte vhdx file adds work to every operation.
• Build temp and caches are on disk. Compilers and package managers create large amounts of short-lived data that does not need to survive anything.
• Nothing is ever pruned. Old images, stopped containers, and unused volumes sit on disk and in the cache.

Step 1: Cache the Drive That Holds the Virtual Disks

Caching the drive that contains the WSL2 and Docker virtual disks speeds up every container and every build, because it accelerates the repeated reads those files generate.

Step 1. Download and install Qiling Fast Cache.

• Free Download
• Windows 11/10/8/7, 100% Secure

Step 2. Open the program and click the + button to create a cache task.

Step 3. Select the drive that holds your WSL2 and Docker data, set the cache size, and add the SSD tier if you have a spare SSD so the cache stays warm across reboots.

Step 4. Click OK and work normally. Check the hit rate after a day of container work to confirm the cache is covering your reads.

If your system drive is small, you can also move Docker's disk image to a roomier drive in Docker Desktop under Settings > Resources > Advanced > Disk image location, then cache that drive instead.

Step 2: Keep Project Files in the Linux File System

This single change often delivers a bigger improvement than any cache, and it costs nothing.

• Clone repositories inside the Linux file system, for example under /home/yourname/projects, rather than reading them from a Windows path. Native Linux paths avoid the cross-file-system translation that makes every read and write slow.
• Use the Linux side for build output. Build directories, dependency folders, and test artifacts should all live where the code lives.
• Reserve Windows paths for things you must edit in Windows tools. When you need both, keep a copy in Linux for building and sync changes deliberately.

Step 3: Move Build Temp into Memory

WSL2 already provides a memory-backed file system, so you can give build temp files the fastest storage available without installing anything inside Windows.

Step 1. Open your WSL2 terminal and create a mount point, for example sudo mkdir -p /mnt/buildtmp.

Step 2. Mount a temporary file system there with a size limit: sudo mount -t tmpfs -o size=8G tmpfs /mnt/buildtmp. Adjust the size to fit your memory.

Step 3. Point your build tools at that path. Set TMPDIR to /mnt/buildtmp in the shell that runs your build, and configure compiler or bundler caches to use subfolders inside it.

Step 4. Remember that a tmpfs is cleared when WSL restarts, which is exactly what you want for intermediate build data.

On the Windows side, a RAM disk created with Qiling Disk Master is the equivalent for Windows-hosted tools, and it is best used for the Windows-side temporary files your editor or terminal produce.

Step 4: Trim, Exclude, and Measure

• Prune regularly. Run docker system prune to remove stopped containers, unused networks, and dangling images, and prune build cache when it grows large. Space you never use still costs time during scans.
• Compact the virtual disk. Shut WSL down with wsl --shutdown, then compact the disk so space freed inside Linux is returned to Windows.
• Exclude the virtual disks from antivirus scanning. Adding the vhdx files and your project folders to the exclusion list removes a large amount of redundant work.
• Give WSL2 enough memory and CPUs. A .wslconfig file lets you set how much memory and how many processors the Linux VM may use, which prevents builds from starving.
• Measure a real build. Time the same clean build before and after each change; the combination of native Linux paths, a cached drive, and tmpfs build temp is usually a large, obvious difference.

FAQs About Docker and WSL2 Speed

Why is Docker so slow on Windows compared with Linux?

Because it runs inside a virtual machine with its own file system. Every operation crosses a virtualization boundary, and files accessed from Windows paths cross two file systems at once.

Does caching the drive really help containers?

Yes. Containers read the same library and layer files repeatedly, which is the pattern a block-level cache handles best. A hit rate above 50 percent is a good sign.

Can I put the whole WSL2 disk image on a RAM disk?

No. The virtual disk is many gigabytes and must survive reboots. Use a RAM disk or tmpfs for build temp only, and cache the drive that holds the virtual disks.

Why does my ext4.vhdx keep growing?

Because deleting files inside Linux does not return space to Windows automatically. Shut down WSL and compact the disk to reclaim it.

Is /mnt/c really slower than a native Linux path?

Yes, significantly. Cross-file-system access goes through an extra translation layer, so builds that touch thousands of files are much slower there.

Will a disk cache help if my system drive is already an NVMe SSD?

The gain is smaller but still present, especially with a RAM tier, because memory access is faster than even the best SSD and the cache also absorbs repeated metadata reads.

Back Up Windows Before You Change Settings

Cache settings and WSL configuration changes are low risk, but your development environment is worth protecting. Qiling Disk Master creates a full Windows image you can restore from if anything goes wrong.

• Free Download
• Windows 11/10/8/7, 100% Secure

Part 1: Create a Full System Backup

Step 1. Install and open Qiling Disk Master. On the home screen, open "Backup and Recovery" and choose "System Backup". This option automatically includes Windows and the hidden boot partitions, so you do not have to select them one by one.

Step 2. Check the source. The disk where Windows is installed and its system partitions are already ticked for you. If you only need your personal documents, run a separate "File Backup" task instead.

Step 3. Click the destination box and choose where the image should be saved. Use an external HDD or SSD, a NAS, or any drive other than the one Windows is installed on, and make sure it has enough free space.

Step 4. Review the task summary and click "Proceed". Wait until the progress bar reaches 100%. Do not unplug the drive or turn off the PC while the backup is running.

Part 2: Restore Windows from the Backup

Step 1. Open Qiling Disk Master again, go to "Backup and Recovery", and select the recovery option. Your backup images are listed, so pick the one you created before the changes began.

Step 2. Choose the target disk or partition. Normally you restore to the original system disk. If the drive was replaced, select the new disk instead, and the restore rebuilds Windows together with its boot partitions.

Step 3. Preview the restore plan, click "Proceed", and confirm the warning. The PC restarts to finish the job, and Windows comes back exactly as it was on the day the image was created, with your files and programs intact.

Conclusion

Docker and WSL2 are slow for structural reasons, not because your PC is weak. Everything lives inside large virtual disk files, and every operation crosses a virtualization boundary. Cache the drive that holds those files with Qiling Fast Cache to accelerate the repeated reads, keep your code natively inside the Linux file system, mount a tmpfs for build temp so short-lived data never touches disk, and prune the images and caches you no longer use. Those four changes together turn a sluggish container workflow into a responsive one.

Protect your PC with Qiling Backup—create a system image before your next round of settings changes.

For more Windows 11 performance guides, see Speed Up Programming Builds with a RAM Disk, Windows 11 Fast Cache, Speed Up Virtual Machines with a Disk Cache, Move the TEMP Folder to a RAM Disk, and How to Check Cache Hit Rate.

Related Articles

• How to Speed Up Programming Builds with a RAM Disk
  Package and compiler cache settings for the Windows side of your toolchain.
• How to Speed Up Virtual Machines with a Disk Cache
  WSL2 is a VM too, so the same caching logic applies.
• Windows 11 Fast Cache: Speed Up HDD with RAM and SSD Cache
• How to Create a RAM Disk in Windows 11
• How to Use Extra RAM (16GB/32GB) to Speed Up Your PC
• Windows 11 Dev Drive vs Disk Cache: Which Is Faster?

Is this information helpful?   Yes   No

This information is not relevant.

This information is not easy to understand.

This information is not deep enough.

What can we do to improve this information? (Optional)

Refresh Please enter the verification code!