Question: recommended setup when source code must stay on the Windows filesystem (performance, file change notifications, containers)

[汤圆大哥 (flowerwOw0316)]

I'm a developer with a single Windows 11 Pro machine (currently build 26300). I'd like to ask the WSL team for advice, or a pointer to plans, about a setup I couldn't make work. Most of the problems below already have their own issues, and I link them. I'm putting them together because they block my workflow together, and fixing only one of them doesn't change the outcome.

Background

My repositories mix .NET Framework 4.8 projects and Windows-only tools with Node and PHP code in the same tree. Because of that, the source has to stay on the Windows filesystem, and I don't want to keep a second writable copy inside a Linux filesystem. I know the general recommendation is to move code into the Linux filesystem. This question is about users who can't do that.

In September I tried WSL 2.9.11 (Ubuntu 26.04.1, kernel 6.18.40.1) as my main development environment, and then went back to native Windows. For containers I use Docker Desktop with the Hyper-V backend, with the Windows source folder bind-mounted into a Compose stack (PHP-FPM, OpenResty, MySQL, PostgreSQL, Redis).

What I measured on this machine

Same Windows sample folder, same distro and runtime. Each figure is the median of 5 runs, taken after one warm-up run:

1. Stat 1000 files: 9p 2097 ms, virtiofs 635 ms
2. Read 1000 x 1 KiB files: 9p 2895 ms, virtiofs 1274 ms
3. Rewrite 100 x 1 KiB files: 9p 472 ms, virtiofs 226 ms
4. Read one 16 MiB file: 9p 69 ms, virtiofs 25 ms

On a real repository with about 1,660 tracked files, git status from Linux over 9p took about 9.0 s, compared with 0.13 s for Git for Windows on the same tree.

Change notifications: edits made from Windows (in-place write, create, atomic replace) produced no inotify event in Linux within 2 seconds, on both 9p and virtiofs, although the new content was readable. Writes made from inside Linux did produce events on virtiofs. In a similar test, Docker Desktop 4.88.1 on the Hyper-V backend (gRPC FUSE) did deliver an inotify event for an edit made from Windows.

Pain points

1. Windows-path performance. virtiofs helps a lot, but it is still opt-in for distros (related: [wsl2] filesystem performance is much slower than wsl1 in /mnt #4197).
2. Edits made from Windows don't trigger inotify, on either 9p or virtiofs (related: [WSL2] File changes made by Windows apps on Windows filesystem don't trigger notifications for Linux apps #4739).
3. Two toolchains. With one source tree used from both sides, Node and pnpm have to be installed on both, platform-specific dependencies can't be shared, and every command needs a decision about which side runs it. I don't expect WSL to remove this, but I'd like to know whether there is a recommended pattern.
4. Cross-OS details on /mnt: without the metadata option, files show as root:root 0777; case sensitivity and CRLF behave differently; Windows PowerShell started from WSL printed its output in the system code page (GB2312 here), which broke UTF-8 decoding on the Linux side.
5. Networking behind a local proxy: in NAT mode I had to point each tool at the Windows proxy through the gateway address myself.
6. wslc as a Docker Desktop replacement: there is no Compose support yet (Compose support in WSLc #40948) and no Docker API compatible endpoint ([Feature Request] Support DOCKER_HOST via Docker Engine API-compatible endpoint in WSLC #40976), and Windows-path bind mounts are slow and get no change notifications (wslc: Provide a high-performance, full-featured way to mount disks #41751).

Questions

1. For users whose source must stay on Windows, what setup does the team recommend today?
2. Is change notification for edits made from Windows on virtiofs mounts on the roadmap, for both distros and wslc? Docker Desktop's Hyper-V backend delivers these events, so is a similar host-side forwarding approach possible?
3. Is there a plan or timeline for making virtiofs the default for distros, and are there known issues I should watch?
4. Can Consommé networking be used with regular distros, and is that recommended?
5. Until these are available, what workaround would you suggest: polling-based watchers, an SMB mount, a sync tool, or something else?

I'm not asking for all of this to be fixed at once. Any pointers or partial answers would help me decide whether to try WSL again. I can share the raw measurements if they are useful. Thanks.

[github-actions[bot]]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use .\collect-wsl-logs.ps1 -LogProfile networking instead, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[汤圆大哥 (flowerwOw0316)]

/question

[github-actions[bot]]

Diagnostic information

Found '/question', adding tag 'question'