Everything about WSL 1 you want to know

关于 WSL 1 入门，你应该知道这些

如有错误，欢迎指出

---

参考：

• WSL 文档
• VMware Workstation Pro 文档

概述

通过 WSL 2 来认识 WSL 1

什么是 WSL 2？

WSL 2 是适用于 Linux 的 Windows 子系统体系结构的一个新版本，它支持适用于 Linux 的 Windows 子系统在 Windows 上运行 ELF64 Linux 二进制文件。 它的主要目标是提高文件系统性能，以及添加完全的系统调用兼容性。

这一新的体系结构改变了这些 Linux 二进制文件与Windows 和计算机硬件进行交互的方式，但仍然提供与 WSL 1（当前广泛可用的版本）中相同的用户体验。

单个 Linux 分发版可以在 WSL 1 或 WSL 2 体系结构中运行。 每个分发版可随时升级或降级，并且你可以并行运行 WSL 1 和 WSL 2 分发版。 WSL 2 使用全新的体系结构，该体系结构受益于运行真正的 Linux 内核。

比较 WSL 1 和 WSL 2

WSL 2 使用最新、最强大的虚拟化技术在轻量级实用工具虚拟机 (VM) 中运行 Linux 内核。 但是，WSL 2 不是传统的 VM 体验。

比较功能

功能	WSL 1	WSL 2
Windows 和 Linux 之间的集成
启动时间短
占用的资源量少
可以与当前版本的 VMware 和 VirtualBox 一起运行
托管 VM
完整的 Linux 内核
完全的系统调用兼容性
跨 OS 文件系统的性能

从上述比较表中可以看出，除了跨操作系统文件系统的性能外，WSL 2 体系结构在多个方面都比 WSL 1 更具优势。

WSL 2 中的新增功能

完整的 Linux 内核

WSL 2 中的 Linux 内核是 Microsoft 根据最新的稳定版分支（基于 kernel.org 上提供的源代码）构建的。此内核已专门针对 WSL 2 进行了调整，针对大小和性能进行了优化，以便在 Windows 上提供良好的 Linux 体验。 内核将由 Windows 更新提供服务，这意味着你将获得最新的安全修补程序和内核改进功能，而无需自行管理它。

提升了文件 IO 性能

如果使用 WSL 2，文件密集型操作（如 git 克隆、npm 安装、apt 更新、apt 升级等）的速度都明显更快。

完全的系统调用兼容性

Linux 二进制文件使用系统调用来执行访问文件、请求内存、创建进程等功能。 虽然 WSL 1 使用的是由 WSL 团队构建的转换层，但 WSL 2 包括了自己的 Linux 内核，具有完全的系统调用兼容性。 优点包括：

• 可以在 WSL 内部运行的一组全新应用，例如 Docker 等。
• 对 Linux 内核的任何更新都立即可供使用。 （无需等待 WSL 团队实现更新并添加更改）。

在启动时使用的内存量更少

WSL 2 在实际 Linux 内核上使用轻量级实用工具 VM，内存占用量很小。 该实用工具将在启动时分配虚拟地址支持的内存。 它已经过配置，在启动时使用的内存占比小于 WSL 1 所需的内存占比。

WSL 1 会被弃用吗？

我们目前没有计划弃用 WSL 1。 你可以并行运行 WSL 1 和 WSL 2 发行版，还可以随时升级和降级任何发行版。

WSL 2 与 VMware

WSL 2 使用 Hyper-V 体系结构来实现其虚拟化。

冲突与兼容

ref1

VMware Workstation 15.5.5 Pro 发行说明 在“新增功能”中指出：

支持 Windows 10 主机 VBS： 现在，VMware Workstation 15.5.5 可在启用了 Hyper-V 功能（例如：基于虚拟化的安全性）的 Windows 主机上运行。

ref2

VMware Workstation Pro 产品文档 在“在启用了 Hyper-V 的主机上运行 Workstation”中指出：

传统的 Workstation Pro 实施依赖于对 x86 微处理器特定硬件功能的直接访问。

这些功能（通常称为 Intel VT 或 AMD-V）也由支持 Hyper-V 的最新版本的 Windows 使用，所以无法在启用了 Hyper-V 功能的 Windows 主机上运行传统 Workstation Pro。

在其子项“主机 VBS 模式与 Windows 版本的兼容性”中，说到：

在启用了 Hyper-V 的具有适当功能的 Windows 10（或更高版本）主机上启动 Workstation Pro 时，将自动启用主机 VBS 模式。

如果禁用 Hyper-V， Workstation Pro 将以其传统模式运行。如果启用 Hyper-V，但 WHP 功能版本不够新或未安装， Workstation Pro 将无法启动。

另外，与在传统模式下运行的 Workstation Pro 虚拟机相比，在主机 VBS 模式下运行的虚拟机存在一些功能限制。（参见子项“主机 VBS 模式的限制”）

ref3

在VMware Workstation 15.5 Now Supports Host Hyper-V Mode中，有关于 Hyper-V 与 VMM 的更详细的说明。如：

• 解释了为何旧版本的 Workstation 无法在启用了 Hyper-V 功能的 Windows 10 主机上运行：

How does VMware Workstation work before version 15.5.5?

VMware Workstation traditionally has used a Virtual Machine Monitor (VMM) which operates in privileged mode requiring direct access to the CPU as well as access to the CPU’s built in virtualization support (Intel’s VT-x and AMD’s AMD-V). When a Windows host enables Virtualization Based Security (“VBS“) features, Windows adds a hypervisor layer based on Hyper-V between the hardware and Windows. Any attempt to run VMware’s traditional VMM fails because being inside Hyper-V the VMM no longer has access to the hardware’s virtualization support.

• 如何处理了这个兼容性问题：

Introducing User Level Monitor

To fix this Hyper-V/Host VBS compatibility issue, VMware’s platform team re-architected VMware’s Hypervisor to use Microsoft’s Windows Hypervisor Platform (WHP) APIs. This means changing our VMM to run at user level instead of in privileged mode, as well modifying it to use the WHP APIs to manage the execution of a guest instead of using the underlying hardware directly.

另外，也说到：

If you don’t use Hyper-V at all, VMware Workstation is smart enough to detect this and the VMM will be used.

这正好呼应了上面“主机 VBS 模式与 Windows 版本的兼容性”中的内容。

ref4

在 WSL 2 FAQ 中，问题 我是否能够运行 WSL 2 和其他第三方虚拟化工具 的回答，也提到了关于这一兼容问题的解决：

我们一直在开发解决方案以支持 Hyper-V 的第三方集成。 例如，我们向第三方虚拟化提供商公开了一组称为虚拟机监控程序平台的 API，可以用来使其软件与 Hyper-V 兼容。 这使得应用程序可以将 Hyper-V 体系结构用于其模拟。

小结

总而言之，15.5.5 之后，在使用了 WSL 2、Docker for Windows 的同时，仍可以使用 Workstation。但在虚拟机性能上，会有些损耗；另外，也无法再使用嵌套的虚拟化（已知问题）。

所以我选择使用：

WSL 1 + Workstation 15.5.2

VMware 官方只提供每个主版本的最新版本的下载，所以要想下载 15.5.2，只能另寻门路了。

WSL 1 的使用

开启功能支持

1. 打开“控制面板”
2. 打开“程序和功能”
3. 在窗口左侧，打开“启用或关闭 Windows 功能”
4. 选中“适用于 Linux 的 Windows 子系统”
5. 点击“确认”

文件系统

概述

参见 File systems in WSL

WSL 必须将各种 Linux 文件系统操作翻译成 NT 内核操作，为此，WSL 仿照 Linux 下的 VFS，设计了一个 VFS 组件。下图展示了它的架构：

VFS 定义了多个文件系统插件：用于展示硬盘中文件的 VolFs 和 DrvFs，内存中的文件系统 TmpFs，以及伪文件系统，如 ProcFs，SysFs，和 CgroupFs。

VolFs 被设计用来提供对 Linux 文件系统特性的完全支持；DrvFs 被设计用来与 Windows 交互。

如今通过执行mount命令，将会发现 VolFs 已经消失了，取而代之的是 WslFs。至于 WslFs 是什么，网上并没有搜到太多有价值的资料。

• What’s new for WSL in Windows 10 version 1903?
• GitHub/wslfs
• What does /upgrade do? · Issue #280 · MicrosoftDocs/WSL

文件权限

参见

• Chmod/Chown WSL Improvements
• WSL 的文件权限

Linux 文件的权限信息作为额外的元数据，在默认的挂载中是不被支持的。这也就意味着，如 Chmod/Chown 这样的命令实际上不会起到任何作用。对于没有元数据的文件，WSL 根据 Windows 下文件的“属性-安全”信息来推测该文件在 WSL 中的权限。

为此，WSL 团队针对 DrvFs 引入了挂载选项 metadata，以对文件和目录提供 Linux 元数据支持。这将在 Windows NT 文件上添加扩展属性，并对其进行解释，以提供 Linux 文件系统权限。

启用了元数据后，新创建的文件将带有默认的元数据，并且同一文件在 Windows 和 Linux 下的权限也将不再保持同步，但注意，同一文件在 WSL 下的访问权限不能多于其在 Windows 下具有的访问权限。

另外，可以通过挂载选项来设定初始权限，这些选项有：

• 指定文件的用户 ID 的 uid
• 指定文件的组 ID 的 gid
• 用于设置权限掩码的：
  • 应用于所有文件的 umask
  • 只应用于目录的 dmask
  • 只应用于文件的 fmask

实例如：

sudo mount -t drvfs C: /mnt/c -o metadata,uid=1000,gid=1000,umask=22,fmask=111

关于权限掩码，需要知道，文件的默认权限为 666，目录的默认权限为 777，而后与掩码进行计算，才最终得到真正的默认权限（或者说”初始权限“更准确）。

挂载移动存储

参见 File System Improvements to the Windows Subsystem for Linux

WSL 只会在启动时自动挂载固定的 NTFS 驱动器；同时，也允许用户手动挂载系统中存在的任意驱动器。

这意味着，对于可在 Windows 中访问到的任何存储，包括 removable USB sticks or CDs, and any network location等，都同样可在 WSL 访问到。

以挂载可移动驱动器 D: 为例，执行如下命令以挂载：

sudo mkdir /mnt/d
sudo mount -t drvfs D: /mnt/d

执行如下命令卸载：

sudo umount /mnt/d

不过要注意的是，对于 FAT 格式的可移动介质，DrvFs 表现为不支持硬链接和符号链接，同时对大小写不敏感。

高级操作

命令行参考

运行 Linux 命令

• 不带参数

  启动默认发行版，使用默认的 shell

• --distribution, -d <Distro>

  运行指定的发行版

• --user, -u <UserName>

  以指定用户的身份运行

• --exec, -e <CommandLine>

  执行指定的命令，但不使用默认的 Linux shell

  我不知道这到底意味着什么。

  在执行wsl -e printenv后，我看到SHELL被设置为printenv；

• --

  按原样传递剩余的命令行

管理 WSL

• --set-default, -s <Distro>

• --unregister <Distro>

• --list, -l

  • --all

  • --running

  • --quiet, -q

    只显示分发名称。

  • --verbose, -v

• --export <Distro> <FileName>

  将该分发版导出为 tar 文件。

• --import <Distro> <InstallLocation> <FileName>

  从 tar 文件中导入分发版，Distro 用于命名该分发版，InstallLocation 指定了安装位置。

  • --version <versionNumber>

    指定用于新分发的版本（WSL 1 or 2）。

• --set-default-version <versionNumber>

  更改新分发的默认安装版本。

• --set-version <Distro> <versionNumber>

  更改指定分发的版本。

• --shudown

  终止所有分发。

• --terminate, -t <Distro>

  终止指定分发。

忘记了密码

1. 使用命令wsl [-d distribution] -u root 进入分发版根目录；
2. 使用 passwd <WSLUsername> 重置密码。

取消注册和重新安装

使用 wsl --unregister <Distro> 注销一个分发版后，与该分发关联的所有数据、设置和软件都将永久丢失。也就是说，wsl -l 不会再列出该分发，硬盘中也不再有该分发相关的文件。

但注意，通过 Microsoft Store 安装的分发在注销后，仍可在 Win 应用列表中看到，这时右击图标，卸载即可。若要重新安装以获取原始副本，那么左击该图标即可，或者运行 bash 或 wsl 命令。

移动（导出和导入）

WSL 默认将发行版存储在系统盘，且无法在资源管理器中直接访问到其文件。对于默认的安装，在启动了一个分发后，可以在命令行中执行explorer.exe .以在资源管理器中访问其文件，或直接在资源管理器地址栏中输入\\wsl$，即可看到该分发。

可以结合使用 wsl.exe 的 --export 和 --import 选项来移动一个分发，而后便可在资源管理器中对其进行直接访问，即便该分发没有在运行中。

1. 导出默认分发

   wsl --export <DefaultDistro> \path\to\defaultDistro.tar

2. （可选）注销默认分发

   wsl --unregister <DefaultDistro>

3. 导入分发

   wsl --import <DistroName> <FSLocation> \path\to\defaultDistro.tar

4. （可选）设置新位置的分发为默认分发

   wsl -e <DistroName>

不过，这样会使的该分发的默认用户变为 root，对此，可使用 wslconf 该配置默认用户。

在 WSL文档 中，给出了“更改分发默认用户”的方法：

<DistributionName> config --default-user <Username>

但这仅适用于从 Store 获取到的分发，对于自行导入的分发无效。

启动配置

通过 wslconf 配置每个发行版

每个发行版在启动时会检测 /etc/wsl.conf 是否存在，如果存在且格式正确，则读取其内容。

wsl.conf 遵守 .ini 约定（除了注释，使用#，而非;），支持的节（section）有：automount、network、interop、user。

一个例子：

[automount]
options = "metadata,umask=22,fmask=11"
[user]
default = "w" # Set default user

使用 wslconfig 进行全局配置

该配置文件位于用于根目录下，一般为C:\Users\<yourUserName>\.wslconfig。

这个配置文件主要是和 WSL 2 有关的，有效节为wsl2。