WSL 2 को Windows फ़ाइल सिस्टम एक्सेस में तेज़ी मिल रही है

मूल लेख ↗ Hacker News चर्चा ↗

बेंचमार्क और तकनीकी नोट्स

  • एक उपयोगकर्ता ने Ryzen 7 + SSD पर Hugo build साझा किया: WSL के आंतरिक ext4 VHD पर ~50s, जबकि virtiofs के जरिए Windows फ़ाइलों पर ~75s; Defender से ~10s अतिरिक्त लगे। फिर भी उन्होंने इसे पुराने 9P-आधारित DrvFs की तुलना में एक बड़ा सुधार और क्रॉस-OS एक्सेस के लिए “अच्छा” परिणाम माना।
  • स्पष्टता: “drvfs” माउंट टाइप है; यह 9P (पुराना, धीमा) या virtiofs (नया) इस्तेमाल कर सकता है। बेंचमार्क में WSL के आंतरिक फ़ाइल सिस्टम की तुलना Windows फ़ाइलों तक virtiofs एक्सेस से की गई थी, 9P से नहीं।
  • कुछ लोगों ने अपग्रेड के बाद WSL startup काफ़ी तेज़ होने की रिपोर्ट की।

फ़ाइल सिस्टम प्रदर्शन क्यों महत्वपूर्ण है

  • व्यापक सहमति है कि WSL2 से /mnt/c (Windows drives) तक एक्सेस बहुत धीमा होता था/है, खासकर बहुत सारी छोटी फ़ाइलों के लिए (जैसे node_modules, Ruby requires, Next.js dev server, git operations)।
  • कई लोग बताते हैं कि Windows पर WSL से बड़े node_modules trees हटाने में मिनटों लग सकते हैं, जबकि native Windows में यह सेकंडों में हो जाता है।
  • कारणों पर मतभेद हैं: कुछ NTFS को दोष देते हैं; दूसरे कहते हैं कि NTFS ठीक है और असली लागत Windows filesystem filter drivers (Defender, AV, backup, cloud sync) की है।

Virtiofs बनाम 9P और सीमाएँ

  • 9P-over-virtio का उपयोग इसलिए किया गया क्योंकि यह Linux virtualization में पहले से मौजूद था और सरल था, लेकिन यह “NFS-like” धीमा है।
  • virtiofs से gap का कुछ हिस्सा कम होने की उम्मीद है, लेकिन यह केवल WSL से Windows फ़ाइलों तक एक्सेस को प्रभावित करता है। WSL के अपने ext4 VHD के अंदर किया गया काम सबसे तेज़ रहता है।
  • कुछ लोग ज़ोर देते हैं कि virtiofs के बावजूद Windows-side overhead (filters, Defender) बना रहता है।

Developer Workflows और Workarounds

  • आम सलाह: dev projects को WSL के ext4 filesystem में रखें; ज़रूरत होने पर /mnt/c में/से copy करें।
  • कुछ लोग WSL में अलग ext4 volumes mount करते हैं और Windows से उन्हें access करते हैं, जो उल्टा करने की तुलना में तेज़ हो सकता है।
  • कुछ हल्के कामों (जैसे SSH) के लिए WSL1 का उपयोग करते हैं क्योंकि इसमें VM overhead नहीं होता, लेकिन Docker/containers के लिए WSL2 चाहिए।

OS Choice, Gaming, और LLMs

  • कई लोग Windows छोड़कर macOS या Linux पर चले गए, मुख्यतः WSL/Windows filesystem की धीमी गति के कारण, और Microsoft की cloud/ads integration से भी चिढ़ के कारण।
  • विरोधी तर्क: दूसरे लोगों के लिए Windows + WSL एक बहुत अच्छा dev environment है, खासकर gaming की ज़रूरतों और Adobe, Office/VBA, VPNs, FPGA और game dev tooling जैसे Windows-only tools की व्यापकता के साथ।
  • gaming पर बहस: कुछ कहते हैं Windows स्पष्ट रूप से आगे है (drivers, anti-cheat), जबकि दूसरे दावा करते हैं कि modern Linux + Proton अक्सर Windows perf के बराबर या बेहतर होता है, और anti-cheat मुख्य रुकावट है।
  • कई टिप्पणियाँ कहती हैं कि LLMs (Claude, ChatGPT) ने Linux पर जाने की friction को बहुत कम कर दिया है, distro choice, configuration, और scripting में मदद करके।

Enterprise और Strategic Context

  • बहुत से लोग WSL का उपयोग करते हैं क्योंकि corporate policy bare-metal Linux को मना करती है लेकिन Windows की अनुमति देती है।
  • कुछ इसे ऐसे environments में “near-Linux” पाने का “only sane way” मानते हैं।
  • कुछ का तर्क है कि Microsoft को Windows filesystem performance और NT side को ठीक करना चाहिए था, बजाय WSL1 की syscall translation से WSL2 के VM approach पर pivot करने के; जबकि कुछ अन्य मानते हैं कि Docker और full Linux semantics के लिए VM approach ज़रूरी था।