Everything about WSL 1 you want to know
阿新 • • 發佈:2021-03-15
> **關於 WSL 1 入門,你應該知道這些**
> 如有錯誤,歡迎指出
---
> 參考:
>
> * [WSL 文件](https://docs.microsoft.com/zh-cn/windows/wsl/)
> * [VMware Workstation Pro 文件](https://docs.vmware.com/cn/VMware-Workstation-Pro/index.html)
# 概述
> 通過 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](https://docs.microsoft.com/zh-cn/windows/wsl/tutorials/wsl-containers)** 等。
- 對 Linux 核心的任何更新都立即可供使用。 (無需等待 WSL 團隊實現更新並新增更改)。
#### 在啟動時使用的記憶體量更少
WSL 2 在實際 Linux 核心上使用輕量級實用工具 VM,記憶體佔用量很小。 該實用工具將在啟動時分配虛擬地址支援的記憶體。 它已經過配置,在啟動時使用的記憶體佔比小於 WSL 1 所需的記憶體佔比。
### [WSL 1 會被棄用嗎?](https://docs.microsoft.com/zh-cn/windows/wsl/wsl2-faq#what-will-happen-to-wsl-1-will-it-be-abandoned)
> 我們目前沒有計劃棄用 WSL 1。 你可以並行執行 WSL 1 和 WSL 2 發行版,還可以隨時升級和降級任何發行版。
## WSL 2 與 VMware
> WSL 2 使用 Hyper-V 體系結構來實現其虛擬化。
### 衝突與相容
#### ref1
[VMware Workstation 15.5.5 Pro 發行說明](https://docs.vmware.com/cn/VMware-Workstation-Pro/15.5/rn/VMware-Workstation-1555-Pro-Release-Notes.html) 在“新增功能”中指出:
> **支援 Windows 10 主機 VBS:** 現在,VMware Workstation 15.5.5 可在啟用了 Hyper-V 功能(例如:基於虛擬化的安全性)的 Windows 主機上執行。
#### ref2
[VMware Workstation Pro 產品文件](https://docs.vmware.com/cn/VMware-Workstation-Pro/15.0/com.vmware.ws.using.doc/GUID-0EE752F8-C159-487A-9159-FE1F646EE4CA.html) 在“在啟用了 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](https://blogs.vmware.com/workstation/2020/05/vmware-workstation-now-supports-hyper-v-mode.html)中,有關於 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](https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-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](https://docs.microsoft.com/en-us/virtualization/api/) (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 和其他第三方虛擬化工具](https://docs.microsoft.com/zh-cn/windows/wsl/wsl2-faq#will-i-be-able-to-run-wsl-2-and-other-3rd-party-virtualization-tools-such-as-vmware-or-virtualbox) 的回答,也提到了關於這一相容問題的解決:
> 我們一直在開發解決方案以支援 Hyper-V 的第三方整合。 例如,我們向第三方虛擬化提供商公開了一組稱為[虛擬機器監控程式平臺](https://docs.microsoft.com/zh-cn/virtualization/api/)的 API,可以用來使其軟體與 Hyper-V 相容。 這使得應用程式可以將 Hyper-V 體系結構用於其模擬。
### 小結
總而言之,15.5.5 之後,在使用了 WSL 2、Docker for Windows 的同時,仍可以使用 Workstation。但在虛擬機器效能上,會有些損耗;另外,也無法再使用巢狀的虛擬化([已知問題](https://docs.vmware.com/cn/VMware-Workstation-Pro/15.5/rn/VMware-Workstation-1555-Pro-Release-Notes.html#knownissues))。
所以我選擇使用:
**WSL 1 + Workstation 15.5.2**
VMware 官方只提供每個主版本的最新版本的下載,所以要想下載 15.5.2,只能[另尋門路](https://leeyr.com/16.html)了。
# WSL 1 的使用
## 開啟功能支援
1. 開啟“控制面板”
2. 開啟“程式和功能”
3. 在視窗左側,開啟“啟用或關閉 Windows 功能”
4. 選中“適用於 Linux 的 Windows 子系統”
5. 點選“確認”
## 檔案系統
### 概述
> 參見 [File systems in WSL](https://docs.microsoft.com/zh-cn/archive/blogs/wsl/wsl-file-system-support#file-systems-in-wsl)
WSL 必須將各種 Linux 檔案系統操作翻譯成 NT 核心操作,為此,WSL 仿照 Linux 下的 VFS,設計了一個 VFS 元件。下圖展示了它的架構:
![file-system-graphic](https://msdnshared.blob.core.windows.net/media/2016/06/file-system-graphic.png)
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?](https://devblogs.microsoft.com/commandline/whats-new-for-wsl-in-windows-10-version-1903/#comment-2438)
> * [GitHub/wslfs](https://github.com/daniellmorris/wslfs)
> * [What does /upgrade do? · Issue #280 · MicrosoftDocs/WSL](https://link.zhihu.com/?target=https%3A//github.com/MicrosoftDocs/WSL/issues/280%23issuecomment-468425983)
### 檔案許可權
> 參見
>
> * [Chmod/Chown WSL Improvements](https://devblogs.microsoft.com/commandline/chmod-chown-wsl-improvements/)
> * [WSL 的檔案許可權](https://docs.microsoft.com/zh-cn/windows/wsl/file-permissions)
Linux 檔案的許可權資訊作為額外的元資料,在預設的掛載中是不被支援的。這也就意味著,如 Chmod/Chown 這樣的命令實際上不會起到任何作用。對於沒有元資料的檔案,WSL 根據 Windows 下檔案的“屬性-安全”資訊來推測該檔案在 WSL 中的許可權。
為此,WSL 團隊針對 DrvFs 引入了掛載選項 `metadata`,以對檔案和目錄提供 Linux 元資料支援。這將在 Windows NT 檔案上新增擴充套件屬性,並對其進行解釋,以提供 Linux 檔案系統許可權。
啟用了元資料後,新建立的檔案將帶有預設的元資料,並且同一檔案在 Windows 和 Linux 下的許可權也將不再保持同步,但注意,同一檔案在 WSL 下的訪問許可權不能多於其在 Windows 下具有的訪問許可權。
另外,可以通過掛載選項來設定初始許可權,這些選項有:
* 指定檔案的使用者 ID 的 `uid`
* 指定檔案的組 ID 的 `gid`
* 用於設定許可權掩碼的:
* 應用於所有檔案的 `umask`
* 只應用於目錄的 `dmask`
* 只應用於檔案的 `fmask`
例項如:
```shell
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](https://docs.microsoft.com/zh-cn/archive/blogs/wsl/file-system-improvements-to-the-windows-subsystem-for-linux)
WSL 只會在啟動時自動掛載固定的 NTFS 驅動器;同時,也允許使用者手動掛載系統中存在的任意驅動器。
這意味著,對於可在 Windows 中訪問到的任何儲存,包括 removable USB sticks or CDs, and any network location等,都同樣可在 WSL 訪問到。
以掛載可移動驅動器 `D:` 為例,執行如下命令以掛載:
```shell
sudo mkdir /mnt/d
sudo mount -t drvfs D: /mnt/d
```
執行如下命令解除安裝:
```shell
sudo umount /mnt/d
```
不過要注意的是,對於 FAT 格式的可移動介質,DrvFs 表現為不支援硬連結和符號連結,同時對大小寫不敏感。
## 高階操作
### 命令列參考
#### 執行 Linux 命令
* 不帶引數
啟動預設發行版,使用預設的 shell
* `--distribut