> **關於 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 元件。下圖展示了它的架構：  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