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

。