I've been noticing whole-machine slow downs whenever I heavily use my Dev Drive (for example, building source) that are just unacceptable.
A common example is I'll start a full build in Visual Studio and then go to type in Windows Terminal and everything I type will be delayed by multiple seconds. Even pasting will show only a few characters at a time.
@bradwilson Have you tried creating a physical partition for #devdrive or just a virtual disk? I’ve only tried a virtual drive, and am curious if a partition would help.
Found my first issue with using a Dev Drive, and wanting to have access to it from WSL: apparently the way Dev Drives mount in Windows is not compatible with the WSL auto-mounting.
Why does this matter? Docker Desktop (in WSL 2 mode) can't mount a Dev Drive folder.
Do I dump WSL 2 mode for Docker? Or do I dump Dev Drive? Tough choice, but I suspect I dump the Dev Drive.
First time poking around with Dev Drives, so doing a little performance testing by measuring dotnet build after git clean -xdf for @xunit (main branch).
On NVMe (NTFS): 17.5s
On SATA (NTFS): 17.9s
On VHDX (ReFS): 14.4s
On VHDX (ext4): 11.7s
The top 3 are built in Windows, and the bottom 1 is built in WSL 2 (Ubuntu 22.04). I wanted to be able to compare the two VHDX options.
Looks like Dev Drive is a win, but not as big as moving to Linux & ext4.
The absolute best thing I can say about #DevDrive is that I enabled it about 6 weeks ago and promptly "forgot" about it. It's just worked, no hiccups.
It contains my source and my NuGet package cache, mounted under C:\Dev. I've been running it as a half-terabyte raw ReFS partition on a SATA SSD. It's way over-provisioned but I had the space to spare, so why not?