- Windows NT की सबसिस्टम संरचना अन्य ऑपरेटिंग सिस्टम के लिए प्रोग्राम चलाने हेतु एक API कॉल रूपांतरण लेयर पर आधारित रही है
- WSL1 ने इसी परंपरा को आगे बढ़ाते हुए Linux कॉल को Windows kernel कॉल में बदलने वाला हल्का अनुवाद लेयर का काम किया
- WSL2 में प्रदर्शन से जुड़ी समस्याएँ हल करने के लिए Hyper-V आधारित पूर्ण Linux VM में रूपांतरण हुआ और वास्तविक Linux kernel चलाया जाने लगा
- WSL2 में डायनामिक मेमोरी मैनेजमेंट, Windows ड्राइव माउंट, WSLg द्वारा GUI इंटीग्रेशन जैसी सुविधाओं की वजह से सामान्य VM की तुलना में अधिक एकीकरण मिलता है
- फ़ाइल प्रबंधन की असुविधा और डिस्क इमेज निर्भरता जैसी सीमाएँ होने के बावजूद, WSL1 और WSL2 के फायदे-नुकसान को चुनिंदा तौर पर मिलाकर इस्तेमाल करने की flexibility ही सबसे महत्वपूर्ण है
Windows NT में सबसिस्टम की अवधारणा
- Windows NT का सबसिस्टम(subsystem) अन्य ऑपरेटिंग सिस्टम के प्रोग्राम चलाने के लिए एक API सेट और कॉल रूपांतरण लेयर को दर्शाता है
- पुराने समय में NT में OS/2 सबसिस्टम(OS2SS.EXE) और POSIX सबसिस्टम(PSXSS.EXE) मौजूद थे
- CSRSS.EXE Win32 API अनुवाद लेयर के रूप में काम करता है, और कुछ क्षमताएँ kernel mode (
WIN32K.SYS) में चली गईं
- POSIX सबसिस्टम सरकार-मान्यता के लिए न्यूनतम इम्प्लीमेंटेशन था, जिसे बाद में Interix आधारित Windows Services for Unix से बदल दिया गया
WSL1: अनुवाद आधारित Linux लेयर
- WSL1(Windows Subsystem for Linux) Linux सिस्टम कॉल को Windows कॉल में बदलने वाला पतला अनुवाद लेयर है
- रन करते समय
bash प्रोसेस केवल कुछ MB मेमोरी लेता है और Task Manager में सामान्य प्रक्रिया के रूप में दिखता है
- root फाइलसिस्टम NTFS पर अलग-अलग फाइल स्ट्रक्चर के रूप में मौजूद रहता है, इसलिए स्टोरेज ओवरहेड लगभग नहीं होता
- सीमाएँ
- I/O प्रदर्शन में गिरावट: Linux और Win32 फाइलसिस्टम API के अंतर से होने वाली ट्रांसलेशन लागत
- GUI चलाने के लिए बाहरी X server की जरूरत (जैसे: X410)
- Raw socket उपलब्ध नहीं होने से
traceroute, nmap, tcpdump जैसे कमांड नहीं चल पाते
WSL2: Hyper-V आधारित Linux VM
- यूजर्स की जरूरत के अनुसार Microsoft ने Hyper-V पर चलने वाला पूर्ण Linux VM जोड़ा
- root फाइलसिस्टम एक single VHDX file में मैनेज होता है
- कमांड
wsl --set-version "Ubuntu" 2 से WSL1 और WSL2 के बीच परिवर्तन संभव है
- प्रदर्शन विशेषताएँ
- cold boot थोड़ा धीमा होता है, लेकिन वास्तविक native Linux kernel चलता है
- मेमोरी उपयोग डायनमिक होता है और अधिकतम फिजिकल मेमोरी का आधा तक बढ़ सकता है
stress टेस्ट में मेमोरी लोड के साथ बढ़ने के बाद अपने आप घटती दिखती है- जरूरत पड़ने पर
wsl --shutdown से VM बंद की जा सकती है
WSL2 की इंटीग्रेशन फीचर्स और सीमाएँ
- WSL2 पारंपरिक VM से अलग Windows इंटीग्रेशन को और मजबूत करता है
- Windows ड्राइव ऑटो-माउंट,
\\wsl$\ पथ से Linux ड्राइव एक्सेस, और WSLg से GUI ऐप रन
- GUI ऐप्स Remote Desktop Protocol के जरिए stream होते हैं, DPI और टेक्स्ट स्केलिंग के लिए अलग सेटिंग की जरूरत पड़ती है
- फाइल प्रबंधन की चुनौतियाँ
- Linux वर्क डेटा
ext4.vhdx इमेज के अंदर रहता है, जिससे portability और recovery risk मौजूद रहती है
wsl --unregister Distro चलाने पर सभी डेटा तुरंत हट जाते हैं- Windows ड्राइव (
/mnt/c) का उपयोग करने पर NTFS + VM ओवरहेड के कारण प्रदर्शन घटता है
- फाइलसिस्टम प्रोटोकॉल
- WSL1 में
drvfs, जबकि WSL2 में Plan9 का 9p protocol प्रयोग होता है
- रूपांतरण प्रक्रिया में
drvfs से जुड़ी बग की रिपोर्ट किए जाने के उदाहरण सामने आए हैं
- वैकल्पिक तरीका
- अलग VHDX image बना कर
wsl --mount --vhd से mount करने पर वर्क डेटा अलग रखने की सलाह दी जाती है
.wslconfig में यह behavior auto सेट नहीं किया जा सकता, इसलिए स्क्रिप्ट के ज़रिये सेटअप करना पड़ता है
निष्कर्ष
- Windows NT की मॉड्यूलर डिज़ाइन और स्थिर kernel ABI पुराने ड्राइवरों की compatibility को बनाए रखती है
- WSL1 की ताकत इसका हल्का मेमोरी उपयोग है, जबकि WSL2 वास्तविक Linux kernel के कारण बेहतर compatibility और performance देता है
- WSL2 पारंपरिक VM के नुकसान को कम करके host OS के साथ इंटीग्रेशन को मजबूत करने वाला architecture देता है
- पारंपरिक परिभाषा में यह VM के करीब है, पर इसे “सबसिस्टम” कहने लायक एक हल्के एकीकृत वातावरण के रूप में भी देखा जा सकता है
अभी कोई टिप्पणी नहीं है.