惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
V
Visual Studio Blog
IT之家
IT之家
博客园 - 聂微东
The Cloudflare Blog
月光博客
月光博客
阮一峰的网络日志
阮一峰的网络日志
S
SegmentFault 最新的问题
Apple Machine Learning Research
Apple Machine Learning Research
酷 壳 – CoolShell
酷 壳 – CoolShell
爱范儿
爱范儿
H
Help Net Security
博客园 - 叶小钗
V
V2EX
WordPress大学
WordPress大学
J
Java Code Geeks
Hugging Face - Blog
Hugging Face - Blog
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
博客园_首页
C
Check Point Blog
B
Blog
D
DataBreaches.Net
美团技术团队
罗磊的独立博客

Hacker News

GitHub - SeanFDZ/macmind: Single-layer transformer in HyperTalk for the classic Macintosh Show HN: Agent-cache – Multi-tier LLM/tool/session caching for Valkey and Redis Bonsai 1-bit WebGPU - a Hugging Face Space by webml-community Moving a large-scale metrics pipeline from StatsD to OpenTelemetry / Prometheus GitHub - Nightmare-Eclipse/RedSun: The Red Sun vulnerability repository GitHub - SethPyle376/hiraeth: Local AWS emulator focused on fast integration testing, with SQS support, SQLite-backed state, and a debug-friendly web UI. GitHub - macOS26/Agent: Any AI, replaces Claude Code, Cursor, OpenClaw. Over 18 LLM providers (Claude, OpenAI, Gemini, Ollama, Zai, HF, Qwen) wired into a native Mac app that writes code, builds Xcode projects, bumps versions, manages git, automates Safari, use AppleScript, JS or Accessibility, extend Agent! w/ MCP Servers, run tasks from your iPhone via Messages. YouTube now lets you turn off Shorts I Made a Terminal Pager Burgers | マクドナルド公式 Commands — HackerNews CLI documentation ChatGPT for Excel PiCore - Raspberry Pi Port of Tiny Core Linux Live Nation illegally monopolized ticketing market, jury finds Google Broke Its Promise to Me. Now ICE Has My Data. Founding Engineer at Adaptional | Y Combinator CRISPR takes important step toward silencing Down syndrome’s extra chromosome GitHub - saffron-health/libretto: The AI toolkit for building reliable browser automations US v. Heppner (S.D.N.Y. 2026) no attorney-client privilege for AI chats [pdf] Retrofitting JIT Compilers into C Interpreters IPv6 – Google The Accursèd Alphabetical Clock Cybersecurity Looks Like Proof of Work Now Fragments: April 14 Cal.com Goes Closed Source: Why AI Security Is Forcing Our Decision | Cal.com - Scheduling Software for Online Bookings Laravel raised money and now injects ads directly into your agent When moving fast, talking is the first thing to break Too much Discussion of the XOR swap trick – Heather Cafe Introduction to Spherical Harmonics for Graphics Programmers The Grand Line
WSL 2 is getting faster Windows file system access
Hayden Barnes · 2026-06-01 · via Hacker News
WSL

From DrvFs in WSL 1 to Plan 9 to virtiofs, cross-OS file access in WSL 2 has improved with each generation. A new change gives each virtio device its own dedicated DMA pool, removing the last major contention point on the virtiofs path.

WSL 2 is getting faster Windows file system access

If your workflow crosses the Windows/Linux boundary, file I/O performance in WSL 2 has been getting steadily better. A change landed in WSL 2 in May 2026 that removes one of the last remaining bottlenecks on the virtiofs path. To understand why it matters, it helps to follow how cross-OS file access has evolved.

How we got here

WSL 1 (2016) handled Windows drive access through DrvFs, a custom filesystem driver running inside the Windows NT kernel. Because WSL 1 ran Linux processes directly on the Windows kernel through a compatibility layer, file operations on /mnt/c could reach NTFS almost directly. Performance was good for file-heavy workloads.

WSL 2 (May 2019) replaced that model with a full Linux kernel in a lightweight Hyper-V VM. That was the right trade: real Linux kernel calls, proper syscall compatibility, and much better performance for Linux-native workloads. For cross-OS access, the VM boundary meant a different approach was needed. Microsoft built a Plan 9 (9P) file server into the Windows-side WSL service. Your Linux session connects to it over a Hyper-V socket at boot, and file operations on /mnt/c travel through that 9P protocol channel.

9P over a Hyper-V socket works, but it has protocol overhead: each operation is bounded by a message size parameter (msize=65536, 64 KB). File-heavy workloads that hit many small files carry that overhead on every round trip. Microsoft has been iterating on this since WSL 2 launched.

Around 2021, virtiofs arrived as an experimental opt-in. Virtiofs uses the VirtIO transport for shared-memory file access, reducing serialization overhead compared to 9P. You enable it in the [wsl2] section of your .wslconfig with virtiofs=true. It has been working its way through incrementally since then: device reuse improvements in PR #40298, shared mmap support without DAX in PR #40426, and now the DMA layer fix.

The DMA layer

Virtual machines on Hyper-V perform DMA for I/O through bounce buffers: a reserved memory region below the 4 GB DMA boundary that hardware can address directly. The Linux kernel calls this the SWIOTLB pool. Until recently, all virtio devices in a WSL 2 session shared one global pool. A virtiofs mount for /mnt/c, one for /mnt/d, and the virtio network adapter all queued into the same buffer, contending with each other during heavy I/O.

PR #40654, authored by Ben Hillis and merged May 27, 2026, gives each virtio device its own dedicated DMA pool. The kernel allocates a contiguous physical range below 4 GB at boot, publishes its address through sysfs (/sys/bus/vmbus/drivers/hv_pci/swiotlb_base and swiotlb_size), and the WSL service reads those values and injects a per-device swiotlb= option into each virtio device at creation time. No more shared queue between drives and the network adapter.

Note: this requires kernel Microsoft.WSL.Kernel 6.18.26.3-1, shipping with WSL 2 DeviceHost 1.2.29-0. If you are on an older kernel, WSL will tell you: "The running kernel is missing a patch that significantly improves virtio device performance. Update to a more recent WSL kernel to enable this optimization."

What this means in practice

The scenarios that benefit most are the file-heavy cross-OS workflows: working in a project that lives on a Windows drive but builds in Linux. If you keep your code under C:\Users\you\code and run cargo build, npm install, or mvn package from /mnt/c, every file read pays a cross-OS I/O cost. The per-device pool removes one of the remaining contention points on the virtiofs path.

VirtioProxy networking also benefits, since it shares the same DMA infrastructure and gets its own pool too.

To get the most out of this:

  • Set virtiofs=true in the [wsl2] section of your .wslconfig.
  • Update to the latest WSL kernel with wsl.exe --update --pre-release.
  • Keep your WSL 2 session RAM above 1 GB. The SWIOTLB pool needs at least 64 MB of headroom.

Virtiofs remains opt-in for now: the default transport is still Plan 9 over a Hyper-V socket.

The longer arc

WSL filesystem performance across the OS boundary has gotten better with each generation. WSL 1's DrvFs was fast because there was no VM boundary. WSL 2 introduced the VM and the shift to 9P. Virtiofs closed most of the gap. Per-device SWIOTLB pools remove contention at the DMA layer. The gap keeps narrowing.

The default is still Plan 9 over a Hyper-V socket. Virtiofs is still opt-in. The work is ongoing in the open at github.com/microsoft/WSL.