WSL 1 or WSL 2: Choose by System-Call and Filesystem Workload

WSL 1 and WSL 2 provide a similar shell-and-Windows integration experience, but they implement Linux workloads differently. WSL 1 translates Linux system calls through a compatibility layer in Windows. WSL 2 runs a real Linux kernel inside a managed lightweight virtual machine. That architectural difference changes system-call compatibility, filesystem performance across the Windows/Linux boundary, kernel-dependent features, networking, and the way operators should diagnose failures.

Microsoft currently recommends WSL 2 for most workloads, but its comparison guide describes scenarios where WSL 1 may still be preferable, particularly when Linux tools must work intensively on Windows files. Do not read that recommendation as proof that every application is faster or more compatible in WSL 2. Select the version from a measured workload profile, not from the distribution name or a generic benchmark.

Understand the architecture, not just the version number

WSL 1 does not boot a Linux kernel VM. It translates Linux system calls into Windows behavior through the WSL compatibility implementation. This can make access to files on the Windows filesystem efficient for some cross-OS workflows, but a workload that depends on a Linux kernel facility may behave differently or require a compatibility fix.

WSL 2 places a Microsoft-maintained Linux kernel in a managed utility VM. Linux system calls are handled by that kernel, which enables a broader set of kernel-facing software and kernel features than the translation design. The VM is managed by WSL; users do not administer it as a conventional standalone virtual machine. The distribution still has its own user space and filesystem image.

The two environments share some user-visible behavior, such as running Linux commands from Windows and accessing files across the boundary, but they should not be treated as the same kernel underneath. For a report, always include wsl –list –verbose and identify the per-distribution WSL version. A Windows build or distro name alone is not enough to reproduce a behavior.

System-call and kernel dependency

Start by inventorying the application’s dependencies. Does it need an eBPF program, a kernel module, a specific filesystem feature, a recent Linux syscall, a container runtime, or a device interface? Those questions tend to favor WSL 2 because it runs a Linux kernel, but do not assume every kernel option is enabled or every hardware interface is exposed. Check the actual WSL kernel version and feature configuration.

Conversely, a command-line tool that uses common file and process operations may work well on either version. Compatibility failures often arise in the less common system-call edge cases, not in launching Bash. Test the real suite: install dependencies, run the build, execute integration tests, use file watchers, and verify signal, process, and socket behavior where the workload relies on them.

Do not cite “full compatibility” as an unconditional guarantee. A real Linux kernel broadens compatibility but does not make WSL identical to every bare-metal distribution. The kernel build, virtualized devices, WSL integration, user-space distribution, and Windows host remain part of the effective platform.

Filesystem placement can reverse a simplistic choice

Filesystem performance is a major exception to generic “WSL 2 is faster” claims. Microsoft’s current comparison and filesystem guidance says WSL 1 can offer better performance when Linux tools access files stored on Windows, while WSL 2 performs best when Linux tools work on files stored in the Linux filesystem. WSL 2’s Windows share path crosses a filesystem integration layer, so metadata-heavy workloads can behave differently from large sequential I/O.

For a project stored under /mnt/c, test the operations that dominate the real workflow: Git status, checkout, package installation, recursive scans, small-file builds, file watchers, chmod, and rename. Compare with the same project stored in the Linux filesystem and accessed from Windows through the supported share path. Keep the toolchain and repository revision constant.

Do not use one synthetic copy benchmark to choose a version. A source tree with hundreds of thousands of small files, a database with fsync requirements, and a sequential archive extraction stress different operations. Record warm and cold runs, metadata behavior, and whether the workflow uses Windows or Linux tools to access the files.

Network and device requirements

The managed VM in WSL 2 introduces a virtual networking boundary and networking modes that differ from WSL 1 behavior. WSL 2 has a distinct virtualized architecture; its default networking mode and current mirrored mode have their own host reachability and firewall behavior. Select the network architecture based on the installed WSL and Windows version, not on assumptions from WSL 1.

USB device workflows can use the USB/IP path on WSL 2 with the required Windows-side tooling and a compatible kernel. Serial-port behavior and other device access can differ. If a project depends on hardware, test attach, detach, permissions, recovery after suspend, and the exact application protocol. A device working in a standard Linux VM does not prove the same WSL integration is present.

Similarly, software that expects to create nested virtual machines or run a Linux kernel service needs an explicit WSL 2 compatibility test. Nested virtualization is a separate setting with its own host/guest prerequisites. Do not decide architecture from the word “VM” alone.

Build a decision matrix for the actual project

For each workload, capture an initial matrix:

Requirement	Test in WSL 1	Test in WSL 2
Linux kernel feature or module	Verify actual behavior or unsupported dependency	Verify current kernel configuration and device exposure
Files under Windows mount	Measure metadata-heavy and sequential tasks	Measure same operations on Windows-backed share
Files in Linux home	Measure end-to-end project tools	Measure native Linux filesystem workflow
Container or systemd requirement	Verify feature support and constraints	Test the intended runtime, cgroups, and service lifecycle
Device or network integration	Exercise exact device and reachability	Test WSL networking mode, permissions, and attach lifecycle

Assign a pass/fail condition before running tests. “Builds eventually” is not a performance criterion, and “kernel is present” is not a compatibility result. Capture the test command, exit code, elapsed time, Windows build, WSL package, kernel release, distro release, and file location.

Migration is a separate operational task

Changing a distribution from WSL 1 to WSL 2 or back is a conversion operation, not just a setting toggle. Microsoft warns that conversion can take time and may fail because the architectures differ. Before conversion, use the current conversion guide, back up the distribution using a supported method, confirm disk space, and rehearse on a recoverable copy.

Do not mix migration procedure with architecture selection. A distro can be perfectly suited to WSL 2 but still require a careful conversion plan. Likewise, a WSL 1 workflow can be the correct choice for a specific Windows-filesystem-heavy project even if the rest of the machine uses WSL 2. The global default controls new distributions; the actual version is per distro.

Keep a dual-version test where useful

Some teams benefit from a WSL 1 and WSL 2 test lane. This is useful when supporting cross-platform build tools, packaging scripts, or software that consumes both Windows-mounted files and Linux kernel features. Keep those lanes independent, record the selected version explicitly, and avoid a test runner that silently uses whichever distro is the current default.

On each run, verify the distro identity and WSL version before executing project code. Run a small filesystem test, a representative syscall/kernel-feature test, and an application test. If the same distro is converted between versions, treat each conversion as an environment change and restore the test snapshot before comparing results.

Decision rule

Choose WSL 2 when the project benefits from a real Linux kernel, kernel-dependent features, systemd, or Linux filesystem performance and the measured workflow passes. Consider WSL 1 when the workload is compatible with its syscall layer and its intensive Windows-filesystem access is materially better for the project. If neither meets the requirements, use a full Linux VM or host environment instead of stretching WSL beyond its demonstrated behavior.

The version number is an architectural choice per distribution. Track it as part of the project’s reproducible environment, validate it in CI, and revisit it only with workload evidence. That is more dependable than treating WSL 2 as an automatic upgrade for every use case or assuming old WSL 1 behavior carries over unchanged.

Related:

Sources: