ReactOS अब BTRFS विभाजन के साथ शुरू होता है

नमस्कार, हेब्र! इस श्रृंखला में, हम WinBtrfs ड्राइवर और ReactOS के साथ तीव्रता से दोस्ती करना जारी रखते हैं।


क्या यह आपका विंडोज है?

चलिए शुरू करते हैं। पिछली पोस्ट के बाद, फ्रीलोडर बूटलोडर के लिए एक मिनी-चालक को लागू किया गया था, जो केवल-पढ़ने के लिए मोड में BTRFS अनुभाग से फ़ाइलों को पढ़ने की अनुमति देता है। पहली समस्या ने मुझे यहाँ प्रतीक्षित किया - BTRFS एक केस-संवेदी फाइल सिस्टम है। यहां, इनोड संरचना की खोज करने के लिए (इस संरचना में फ़ाइल के बारे में बुनियादी जानकारी है), फ़ाइल नाम का हैश निर्देशिका में उपयोग किया जाता है, यह आपको निर्देशिका में निहित सभी फ़ाइलों को बाहर निकाले बिना रास्तों पर चलने की अनुमति देता है।

हालाँकि, विंडोज की दुनिया में, फ़ाइल नाम रजिस्टर के रूप में इस तरह की बात किसी के लिए बहुत कम चिंता का विषय है, इसलिए ओएस लोड करने के लिए आवश्यक ड्राइवरों के लिए मार्ग रजिस्ट्री में बिल्कुल किसी भी रजिस्टर में लिखा जा सकता है।

फिलहाल, यह समस्या अच्छी पुरानी बैसाखियों द्वारा हल की गई है - जब आप किसी फ़ाइल की खोज करने का अनुरोध करते हैं, तो सिस्टम 32 द्वारा System32 और System32 को बदल दिया जाता है, ड्राइवर फ़ोल्डर के साथ। अब तक, मैं सोच रहा था कि कोई इसे सक्षम रूप से कैसे कर सकता है। सबसे अधिक संभावना है कि मैं हर बार एक निर्देशिका में फ़ाइलों की एक पूरी सूची अपलोड करूंगा और एक केस-असंवेदनशील खोज करूंगा - स्पीड लोडर विशेष रूप से बूटलोडर पर दिखाई नहीं देगा।



लोडर फाइलों को पढ़ता है, बैसाखी को कठोर किया जाता है - हम आगे बढ़ते हैं।

मैंने बूच वर्चुअल मशीन में बूटलोडर कोड विकसित किया है, क्योंकि यह इसमें करने के लिए सबसे सुविधाजनक चीज है। लेकिन वह (जैसा कि यह निकला) रिएक्टोस को लॉन्च करने में समस्याएं हैं, इसलिए मुझे सामान्य वर्चुअलबॉक्स में स्थानांतरित करना पड़ा।

और फिर एक और घात मेरी प्रतीक्षा कर रहा था - किसी कारण से, बूट सेक्टर ने काम नहीं किया। जैसा कि यह निकला, INT 13h AH = 42h इंटरप्ट (डिस्क से विस्तारित रीड) के कार्यान्वयन में कुछ समस्याएं हैं, जिसके कारण यह फ़ंक्शन एक समय में 8 से अधिक सेक्टर नहीं पढ़ सकता है।

और अंत में, पहला त्रुटि संदेश (यह बीएसओडी भी नहीं है!)



STATUS_ACCESS_VIOLATION का अपवाद WinSxS सबसिस्टम से आया है, जो मुख्य रूप से शराब से लिया गया है। कुछ दिनों की घटना के कारण पर खर्च किया जाना था, क्योंकि सभी लाइब्रेरी WinSxS के माध्यम से भरी हुई हैं, और स्टार्टअप पर उनमें से बहुत सारे हैं। अंत में, यह पता चला कि समस्या WinSxS (fuch) में नहीं थी, लेकिन NtQueryDirectoryFile सिस्टम कॉल में थी।

WinSxS अक्सर इस फ़ंक्शन का उपयोग मास्क के द्वारा प्रकट होने के लिए खोज करने के लिए करता है (जैसे प्रश्न बनाकर: "* _Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0।।। *। _ _ * * *। Manifest"), और WinBtrfs ड्राइवर में प्रसंस्करण क्रेप से संबंधित बग। तारांकन से शुरू होने वाले मुखौटे। आप यहाँ एक बहुत ही सरल पुल अनुरोध देख सकते हैं।

आश्चर्यजनक रूप से, यह डेस्कटॉप पर इंस्टॉलेशन और बूट को पूरा करने के लिए पर्याप्त था


शायद WinBtrfs ड्राइवर से दुनिया का पहला बूट। मेरे फिक्स के पहले कार्यान्वयन में भी त्रुटियां थीं, जिसके कारण ग्राफिक्स को कहीं जाना पड़ा और चित्रों को लोड नहीं करना पड़ा।

असल में, सिस्टम बूट होता है और यहां तक ​​कि काम भी करता है (हालांकि स्थिरता 0.4.9 रिलीज के समान नहीं है)।

लेकिन समस्याएं अभी भी भरी हैं:

• कोई स्वैप फ़ाइल समर्थन नहीं। आमतौर पर, btrfs डिस्क पर linux स्वैप फ़ाइलों पर भी समर्थन नहीं किया जाता है, और पैच कई वर्षों से लटका हुआ है। लेकिन WinBtrfs उनका समर्थन करता है। हमारे पास विंडोज की तुलना में मेमोरी मैनेजर का थोड़ा अलग कार्यान्वयन है, जिसके लिए एक और सिस्टम कॉल की आवश्यकता होती है जो अभी तक WinBtrfs में उपलब्ध नहीं है।
• त्रुटियों और स्मृति अतिप्रवाह लिखें। मैं उदाहरण के लिए, Git क्लाइंट को स्थापित करते समय ऐसे कुछ को ठीक करने में कामयाब रहा। हम यह पता लगाएंगे कि मेमोरी कहां बहती है।
• शटडाउन और रिबूट पर बीएसओडी। पैच पहले से ही मंजूरी का इंतजार कर रहा है

अंत तक, जीएसओसी को बस थोड़ा सा छोड़ दिया गया था, बग को और ठीक करने की योजना बनाई गई, और स्वैप फ़ाइल के साथ समस्या को हल किया (लेकिन यह कार्यक्रम के अंत के बाद है)।

खैर, जो लोग इस सुविधा के विकास का समर्थन करना चाहते हैं, वे WinBtrfs ड्राइवर के परीक्षण और विकास में शामिल हो सकते हैं।