SDCardFS में गहन अन्वेषण, FUSE के लिए Google का प्रतिस्थापन, और इसके कार्यान्वयन से I/O ओवरहेड कैसे कम होगा।
कई महीने पहले, Google ने "" नामक कुछ जोड़ा थाएसडीकार्डएफएसलिनक्स कर्नेल के लिए आधिकारिक AOSP शाखाओं के लिए। उस समय, इस कदम पर केवल ध्यान दिया गया था कुछ कर्नेल डेवलपर, लेकिन अन्यथा अधिकांश उपयोगकर्ताओं के रडार के नीचे उड़ गया। इस तथ्य पर विचार करने में कोई आश्चर्य की बात नहीं है कि अधिकांश उपयोगकर्ता, जिनमें मैं भी शामिल हूं, वास्तव में नहीं जानते कि एंड्रॉइड ओएस और उसके कर्नेल के हुड के नीचे क्या चल रहा है।
हालाँकि, इसका सबसे ताज़ा एपिसोड एंड्रॉइड डेवलपर्स मंच के पीछे पॉडकास्ट ने इस विषय में रुचि नवीनीकृत की। चेत हासे (Google के एक वरिष्ठ सॉफ्टवेयर इंजीनियर) द्वारा होस्ट किए गए पॉडकास्ट ने कर्नेल में किए गए हालिया और आगामी परिवर्तनों का पता लगाया। शो में एंड्रॉइड टीम पर काम करने वाला एक लिनक्स कर्नेल डेवलपर था - रोम लेमरचंद। दोनों ने मुख्य रूप से इस बात पर चर्चा की कि ए/बी अपडेट को समायोजित करने के लिए क्या बदलाव किए गए हैं, लेकिन एपिसोड के आखिरी 5 मिनट में श्री लेमरचंद ने "अगली बड़ी चीज़" के बारे में बात की जिस पर उनकी टीम काम कर रही थी - एसडीकार्डएफएस.
मुझे यह स्वीकार करना होगा कि इस पॉडकास्ट को सुनने के बाद मुझे SDCardFS के अस्तित्व के बारे में पता चला। निस्संदेह, इस विषय में रुचि लेने वाला मैं अकेला नहीं था हालिया रेडिट थ्रेड दिखाया है। हालाँकि, मैं पॉडकास्ट में पेश की गई बुनियादी व्याख्या से संतुष्ट नहीं था, और कुछ को दूर करने के प्रयास में चारों ओर गलत सूचना फैलाई जा रही है, मैंने स्वयं कुछ शोध किया और प्रासंगिक ज्ञान रखने वाले कुछ विशेषज्ञों से बात की मामला।
इस लेख में अपने ज्ञान का योगदान देने और मेरे प्रश्नों का उत्तर देने के लिए समय निकालने के लिए सॉफ्टवेयर डेवलपर मिशाल कोवाल्स्की को बहुत-बहुत धन्यवाद।
"बाहरी" वास्तव में आंतरिक है
शुरुआत से ही, कुछ गलतफहमियाँ अवश्य हैं जिन्हें हमें दूर करना होगा - अन्यथा लेख का बाकी हिस्सा बहुत भ्रमित करने वाला होगा। एसडी कार्ड और एंड्रॉइड फोन के इतिहास पर चर्चा करना उपयोगी है।
एंड्रॉइड फोन के शुरुआती दिनों में, लगभग हर डिवाइस स्टोरेज के लिए अपने माइक्रोएसडी कार्ड का उपयोग करने पर निर्भर था। यह इस तथ्य के कारण था कि उस समय फोन बहुत कम आंतरिक भंडारण क्षमता के साथ भेजे जाते थे। हालाँकि, अनुप्रयोगों को संग्रहीत करने के लिए उपयोग किए जाने वाले एसडी कार्ड अक्सर एक शानदार उपयोगकर्ता अनुभव प्रदान नहीं करते हैं, कम से कम उस गति की तुलना में जिसके साथ आंतरिक फ्लैश मेमोरी डेटा पढ़/लिख सकती है। इसलिए, बाहरी डेटा भंडारण के लिए एसडी कार्ड का बढ़ता उपयोग Google के लिए उपयोगकर्ता अनुभव चिंता का विषय बन रहा था।
बाहरी स्टोरेज डिवाइस के रूप में एसडी कार्ड के शुरुआती प्रसार के कारण, एंड्रॉइड की स्टोरेज नामकरण परंपराएं इस तथ्य पर आधारित थीं कि प्रत्येक डिवाइस में एक वास्तविक, भौतिक माइक्रोएसडी कार्ड स्लॉट होता था। लेकिन जिन डिवाइसों में एसडी कार्ड स्लॉट नहीं था, वहां भी वास्तविक आंतरिक स्टोरेज चिप को इंगित करने के लिए /sdcard लेबल का उपयोग किया जाता था। अधिक भ्रमित करने वाला तथ्य यह है कि जो डिवाइस भंडारण के लिए भौतिक एसडी कार्ड के साथ-साथ उच्च क्षमता वाले स्टोरेज चिप दोनों का उपयोग करते हैं, वे अक्सर एसडी कार्ड के आधार पर अपने विभाजन का नाम देते हैं। उदाहरण के लिए, इन उपकरणों में /sdcard माउंट पॉइंट वास्तविक आंतरिक स्टोरेज चिप को संदर्भित करेगा, जबकि /storage/sdcard1 जैसा कुछ भौतिक बाहरी कार्ड को संदर्भित करेगा।
इस प्रकार, भले ही माइक्रोएसडी कार्ड को व्यावहारिक रूप से बाहरी भंडारण माना जाता है, नामकरण परंपरा के परिणामस्वरूप "एसडीकार्ड" भौतिक कार्ड के किसी भी वास्तविक उपयोग से बहुत पहले चिपक जाता है। भंडारण के साथ इस भ्रम ने एप्लिकेशन डेवलपर्स को इस तथ्य के कारण कुछ सिरदर्द भी प्रदान किया कि एप्लिकेशन डेटा और उसके मीडिया को दो विभाजनों के बीच अलग किया गया था।
आरंभिक आंतरिक भंडारण चिप्स के कम भंडारण स्थान के कारण उपयोगकर्ताओं को निराशा हुई कि वे अब एप्लिकेशन इंस्टॉल नहीं कर सकते (/डेटा विभाजन पूर्ण होने के कारण)। इस बीच, उनके बड़ी क्षमता वाले माइक्रोएसडी कार्ड केवल मीडिया (जैसे फोटो, संगीत और फिल्में) रखने के लिए सीमित कर दिए गए। जो उपयोगकर्ता पुराने समय में हमारे मंचों को ब्राउज़ करते थे, उन्हें ये नाम याद होंगे: Link2SD और Apps2SD। ये (रूट) समाधान थे जो उपयोगकर्ताओं को अपने एप्लिकेशन और उसके डेटा को भौतिक एसडी कार्ड पर इंस्टॉल करने में सक्षम बनाते थे। लेकिन ये सही समाधान से बहुत दूर थे, इसलिए Google को इसमें कदम उठाना पड़ा।
प्रसिद्ध रूप से, Google ने बहुत पहले ही SD कार्ड पर प्लग हटा दिया था। नेक्सस वन माइक्रोएसडी कार्ड स्लॉट वाला एकमात्र नेक्सस डिवाइस है (और यह हमेशा के लिए रहेगा क्योंकि नेक्सस ब्रांड प्रभावी रूप से समाप्त हो चुका है)। नेक्सस एस के साथ, अब सभी एप्लिकेशन डेटा और मीडिया को संग्रहीत करने के लिए केवल एक, एकीकृत विभाजन था - /डेटा विभाजन। जिसे कभी /sdcard माउंट पॉइंट के नाम से जाना जाता था, वह अब केवल एक वर्चुअल फ़ाइल सिस्टम (के तहत कार्यान्वित) का संदर्भ दे रहा था फ्यूज प्रोटोकॉल जैसा कि नीचे चर्चा की गई है) डेटा विभाजन में स्थित है - /डेटा/मीडिया/0।
अनुकूलता बनाए रखने और भ्रम को कम करने के लिए, Google ने अभी भी मीडिया को होल्ड करने के लिए इस वर्चुअल "एसडीकार्ड" विभाजन का उपयोग किया है। लेकिन अब यह "एसडीकार्ड" वर्चुअल विभाजन वास्तव में /डेटा के भीतर स्थित था, इसके भीतर संग्रहीत कुछ भी आंतरिक भंडारण चिप के भंडारण स्थान के विरुद्ध गिना जाएगा। इस प्रकार, यह ओईएम पर निर्भर था कि वह अनुप्रयोगों (/डेटा) बनाम मीडिया (/डेटा/मीडिया) को कितना स्थान आवंटित करे।
Google उम्मीद कर रहा था कि निर्माता उनके उदाहरण का अनुसरण करें और एसडी कार्ड से छुटकारा पाएं। शुक्र है, समय के साथ फोन निर्माता लागत प्रभावी रहते हुए इन घटकों को उच्च क्षमता पर प्राप्त करने में सक्षम हो गए, इसलिए एसडी कार्ड की आवश्यकता कम होने लगी थी। लेकिन नामकरण परंपराएं डेवलपर्स और ओईएम को समायोजित करने के लिए किए जाने वाले प्रयास की मात्रा को कम करने के लिए बनी हुई हैं। वर्तमान में, जब हम "बाह्य भंडारण" का उल्लेख करते हैं तो हम इसका उल्लेख कर रहे होते हैं दो चीजों में से कोई एक: वास्तविक हटाने योग्य माइक्रोएसडी कार्ड या /डेटा/मीडिया में स्थित वर्चुअल "एसडीकार्ड" विभाजन। इनमें से उत्तरार्द्ध, व्यावहारिक रूप से बोलते हुए, वास्तव में आंतरिक भंडारण है, लेकिन Google की नामकरण परंपरा इसे इस तथ्य के कारण अलग करती है कि यह डेटा उपयोगकर्ता के लिए पहुंच योग्य है (जैसे कि जब कंप्यूटर में प्लग किया जाता है)।
वर्तमान में, जब हम "बाह्य भंडारण" का उल्लेख करते हैं तो हम इसका उल्लेख कर रहे होते हैं दो चीजों में से कोई एक: वास्तविक हटाने योग्य माइक्रोएसडी कार्ड या /डेटा/मीडिया में स्थित वर्चुअल "एसडीकार्ड" विभाजन।
एंड्रॉइड के वर्चुअल फाइल सिस्टम का इतिहास
अब जब "एसडीकार्ड" को एक वर्चुअल फाइल सिस्टम के रूप में माना जाता है, तो इसका मतलब है कि इसे Google द्वारा वांछित किसी भी फाइल सिस्टम के रूप में स्वरूपित किया जा सकता है। नेक्सस एस और एंड्रॉइड 2.3 से शुरुआत करते हुए, Google ने "एसडीकार्ड" को वीएफएटी (वर्चुअल एफएटी) के रूप में प्रारूपित करना चुना। यह कदम उस समय समझ में आया, क्योंकि VFAT को माउंट करने से लगभग कोई भी कंप्यूटर आपके फोन पर संग्रहीत डेटा तक पहुंच प्राप्त कर सकेगा। हालाँकि, इस प्रारंभिक कार्यान्वयन में दो प्रमुख मुद्दे थे।
पहला मुख्य रूप से अंतिम उपयोगकर्ता (आप) से संबंधित है। अपने डिवाइस को अपने कंप्यूटर से कनेक्ट करने के लिए, आप डेटा ट्रांसफर करने के लिए यूएसबी मास स्टोरेज मोड का उपयोग करेंगे। हालाँकि, कंप्यूटर के डेटा तक पहुँचने से पहले एंड्रॉइड डिवाइस को वर्चुअल पार्टीशन को अनमाउंट करना आवश्यक था। यदि कोई उपयोगकर्ता प्लग इन रहते हुए अपने डिवाइस का उपयोग करना चाहता है, तो कई चीज़ें अनुपलब्ध दिखाई देंगी।
मीडिया ट्रांसफर प्रोटोकॉल का परिचय (एमटीपी) ने यह पहला मुद्दा हल कर दिया। प्लग इन करने पर, आपका कंप्यूटर आपके डिवाइस को "मीडिया स्टोरेज" डिवाइस के रूप में देखता है। यह आपके फ़ोन से फ़ाइलों की एक सूची का अनुरोध करता है, और एमटीपी उन फ़ाइलों की एक सूची लौटाता है जिन्हें कंप्यूटर डिवाइस से डाउनलोड कर सकता है। जब किसी फ़ाइल को हटाने का अनुरोध किया जाता है, तो एमटीपी अनुरोधित फ़ाइल को स्टोरेज से हटाने के लिए एक कमांड भेजता है। यूएसबी मास स्टोरेज मोड के विपरीत, जो वास्तव में "एसडीकार्ड" को माउंट करता है, एमटीपी उपयोगकर्ता को प्लग इन रहते हुए अपने डिवाइस का उपयोग जारी रखने की अनुमति देता है। इसके अलावा, एंड्रॉइड फोन पर मौजूद फाइल सिस्टम अब कंप्यूटर के लिए डिवाइस पर फाइलों को पहचानने के लिए मायने नहीं रखता है।
दूसरे, तथ्य यह था कि VFAT ने उस प्रकार का मजबूत अनुमति प्रबंधन प्रदान नहीं किया जिसकी Google को आवश्यकता थी। प्रारंभ में, कई एप्लिकेशन डेवलपर "एसडीकार्ड" को अपने एप्लिकेशन के डेटा के लिए डंपिंग ग्राउंड के रूप में मानते थे, जिसमें उनकी फ़ाइलों को कहां संग्रहीत करना है, इसकी कोई एकीकृत समझ नहीं होती थी। कई एप्लिकेशन बस अपने ऐप नाम के साथ एक फ़ोल्डर बनाते हैं और अपनी फ़ाइलों को वहां संग्रहीत करते हैं।
उस समय लगभग हर एप्लिकेशन को इसकी आवश्यकता होती थी WRITE_EXTERNAL_STORAGE उनकी एप्लिकेशन फ़ाइलों को बाह्य संग्रहण में लिखने की अनुमति। हालाँकि, अधिक परेशान करने वाली बात यह थी कि लगभग हर एप्लिकेशन को इसकी आवश्यकता भी होती थी पढ़ें_बाहरी_स्टोरेज अनुमति - केवल अपनी स्वयं की डेटा फ़ाइलों को पढ़ने के लिए! इसका मतलब यह था कि एप्लिकेशन बाहरी स्टोरेज पर कहीं भी संग्रहीत डेटा तक आसानी से पहुंच सकते थे, और ऐसी अनुमति अक्सर उपयोगकर्ता द्वारा दी जाती थी क्योंकि कई ऐप्स के लिए भी इसकी आवश्यकता होती थी समारोह।
Google ने इसे स्पष्ट रूप से समस्याग्रस्त के रूप में देखा। अनुमति प्रबंधन के पीछे का पूरा विचार यह अलग करना है कि ऐप्स किस तक पहुंच सकते हैं और क्या नहीं। यदि लगभग हर ऐप को संभावित संवेदनशील उपयोगकर्ता डेटा तक पढ़ने की पहुंच दी जा रही है, तो अनुमति अर्थहीन है। इस प्रकार, Google ने निर्णय लिया कि उन्हें एक नए दृष्टिकोण की आवश्यकता है। यहीं पर FUSE आता है।
यूजरस्पेस में फ़ाइल सिस्टम (FUSE)
एंड्रॉइड 4.4 से शुरुआत करते हुए, Google ने वर्चुअल "sdcard" विभाजन को VFAT के रूप में माउंट नहीं करने का निर्णय लिया। इसके बजाय, Google ने "sdcard" वर्चुअल विभाजन पर FAT32 का अनुकरण करने के लिए FUSE का उपयोग करना शुरू किया। एसडीकार्ड प्रोग्राम कॉलिंग के साथ FAT-on-sdcard शैली निर्देशिका अनुमतियों का अनुकरण करने के लिए FUSE, एप्लिकेशन बाहरी संग्रहण पर संग्रहीत इसके डेटा तक पहुंच शुरू कर सकते हैं बिना किसी अनुमति की आवश्यकता के. दरअसल, एपीआई लेवल 19 से शुरू होकर, READ_EXTERNAL_STORAGE को अब स्थित फ़ाइलों तक पहुंचने की आवश्यकता नहीं थी बाह्य भंडारण पर - बशर्ते FUSE डेमॉन द्वारा बनाया गया डेटा फ़ोल्डर ऐप के पैकेज नाम से मेल खाता हो। FUSE संभाल लेगा बाहरी भंडारण पर फ़ाइलों के स्वामी, समूह और मोड को संश्लेषित करना जब कोई एप्लिकेशन इंस्टॉल किया जाता है.
FUSE इन-कर्नेल मॉड्यूल से भिन्न है क्योंकि यह गैर-विशेषाधिकार प्राप्त उपयोगकर्ताओं को वर्चुअल फ़ाइल सिस्टम लिखने की अनुमति देता है। Google द्वारा FUSE को लागू करने का कारण काफी सरल है - इसने वही किया जो वे चाहते थे और पहले से ही था अच्छी तरह से समझा और प्रलेखित किया गया लिनक्स की दुनिया में. एक उद्धरण के लिए इस मामले पर Google डेवलपर:
"क्योंकि FUSE एक अच्छा स्थिर एपीआई है, कर्नेल संस्करणों के बीच चलते समय अनिवार्य रूप से शून्य रखरखाव कार्य की आवश्यकता होती है। यदि हम इन-कर्नेल समाधान में स्थानांतरित हो जाते हैं, तो हम प्रत्येक स्थिर कर्नेल संस्करण के लिए पैच का एक सेट बनाए रखने के लिए साइन अप करेंगे।" - जेफ शार्की, Google में सॉफ्टवेयर इंजीनियर
हालाँकि, यह बिल्कुल स्पष्ट हो रहा था कि FUSE का ओवरहेड अन्य मुद्दों के बीच प्रदर्शन में गिरावट ला रहा था। इस मामले के संबंध में मैंने जिस डेवलपर से बात की, मिशाल कोवाल्ज़िक, एक उत्कृष्ट ब्लॉग पोस्ट लिखा एक वर्ष से अधिक पहले FUSE के साथ वर्तमान मुद्दों का विवरण दिया गया था। अधिक तकनीकी विवरण उनके ब्लॉग पर पढ़ा जा सकता है, लेकिन मैं उनके निष्कर्षों का (उनकी अनुमति से) अधिक सामान्य शब्दों में वर्णन करूंगा।
FUSE के साथ समस्या
एंड्रॉइड में, "एसडीकार्ड" यूजरस्पेस डेमॉन बूट पर अनुकरणीय बाहरी स्टोरेज निर्देशिका में /dev/fuse को माउंट करने के लिए FUSE का उपयोग करता है। उसके बाद, एसडीकार्ड डेमॉन कर्नेल से किसी भी लंबित संदेश के लिए FUSE डिवाइस को पोल करता है। यदि आपने पॉडकास्ट सुना है, तो आपने श्री लेमरचंद को I/O संचालन के दौरान ओवरहेड शुरू करने के लिए FUSE का उल्लेख करते हुए सुना होगा - यहां मूलतः यही होता है।
वास्तविक दुनिया में, यह प्रदर्शन प्रभावित करता है कोई फ़ाइल बाहरी संग्रहण पर संग्रहीत है.
समस्या #1 - I/O ओवरहेड
मान लें कि हम एक साधारण टेक्स्ट फ़ाइल बनाते हैं, जिसे "test.txt" कहा जाता है, और इसे /sdcard/test.txt में संग्रहीत करते हैं (जो, चलो मैं आपको याद दिला दूं, वास्तव में /data/media/0/test.txt यह मान रहा है कि वर्तमान उपयोगकर्ता प्राथमिक उपयोगकर्ता है उपकरण)। यदि हम इस फ़ाइल को (कमांड कैट) पढ़ना चाहते हैं, तो हम उम्मीद करेंगे कि सिस्टम 3 कमांड जारी करेगा: खोलें, पढ़ें, फिर बंद करें। वास्तव में, जैसा कि श्री कोवाल्ज़िक प्रयोग करके प्रदर्शित करते हैं स्ट्रेस, यही होता है:
लेकिन चूँकि फ़ाइल बाहरी संग्रहण पर स्थित है जिसे एसडीकार्ड डेमॉन द्वारा प्रबंधित किया जाता है, इसलिए कई अतिरिक्त ऑपरेशन करने की आवश्यकता होती है। श्री कोवाल्ज़िक के अनुसार, अनिवार्य रूप से 8 अतिरिक्त कदमों की आवश्यकता है इन 3 व्यक्तिगत आदेशों में से प्रत्येक:
- यूजरस्पेस एप्लिकेशन सिस्टम कॉल जारी करता है जिसे कर्नेल में FUSE ड्राइवर द्वारा नियंत्रित किया जाएगा (हम इसे पहले स्ट्रेस आउटपुट में देखते हैं)
- कर्नेल में FUSE ड्राइवर नए अनुरोध के बारे में यूजरस्पेस डेमॉन (एसडीकार्ड) को सूचित करता है
- यूजरस्पेस डेमॉन /dev/fuse पढ़ता है
- यूजरस्पेस डेमॉन कमांड को पार्स करता है और फ़ाइल ऑपरेशन को पहचानता है (उदा. खुला)
- यूजरस्पेस डेमॉन वास्तविक फ़ाइल सिस्टम पर सिस्टम कॉल जारी करता है (EXT4)
- कर्नेल भौतिक डेटा एक्सेस को संभालता है और डेटा को उपयोगकर्ता स्थान पर वापस भेजता है
- यूजरस्पेस डेटा को संशोधित करता है (या नहीं) करता है और इसे /dev/fuse के माध्यम से फिर से कर्नेल में भेजता है
- कर्नेल मूल सिस्टम कॉल को पूरा करता है और डेटा को वास्तविक यूजरस्पेस एप्लिकेशन में ले जाता है (हमारे उदाहरण बिल्ली में)
ऐसा लगता है बहुत केवल एक I/O कमांड चलाने के लिए ओवरहेड का। और आप सही होंगे। इसे प्रदर्शित करने के लिए, श्री कोवाल्स्की ने दो अलग-अलग I/O परीक्षणों का प्रयास किया: एक में एक बड़ी फ़ाइल की प्रतिलिपि बनाना और दूसरे में बहुत सारी छोटी फ़ाइलों की प्रतिलिपि बनाना शामिल था। उन्होंने इन परिचालनों को संभालने वाले FUSE (FAT32 के रूप में स्थापित आभासी विभाजन पर) की गति की तुलना की कर्नेल (EXT4 के रूप में स्वरूपित डेटा विभाजन पर), और उन्होंने पाया कि FUSE वास्तव में महत्वपूर्ण योगदान दे रहा था उपरि.
पहले परीक्षण में, उन्होंने दोनों परीक्षण स्थितियों के तहत 725MB फ़ाइल की प्रतिलिपि बनाई। उन्होंने पाया कि FUSE कार्यान्वयन ने बड़ी फ़ाइलों को स्थानांतरित कर दिया 17% अधिक धीरे-धीरे.
दूसरे परीक्षण में, उन्होंने 10,000 फ़ाइलें कॉपी कीं - उनमें से प्रत्येक का आकार 5KB था। इस परिदृश्य में, FUSE कार्यान्वयन समाप्त हो गया था 40 सेकंड धीमी मूल रूप से 50एमबी मूल्य का डेटा कॉपी करने के लिए।
वास्तविक दुनिया में, यह प्रदर्शन प्रभावित करता है कोई फ़ाइल बाहरी संग्रहण पर संग्रहीत है. इसका मतलब है कि मैप्स जैसे ऐप्स बड़ी फ़ाइलों को /sdcard पर संग्रहीत करते हैं, संगीत ऐप्स ढेर सारी संगीत फ़ाइलों को संग्रहीत करते हैं, कैमरा ऐप्स और फ़ोटो इत्यादि। कोई भी I/O ऑपरेशन जिसमें बाह्य भंडारण शामिल है, FUSE के ओवरहेड से प्रभावित होता है। लेकिन I/O ओवरहेड FUSE के साथ एकमात्र समस्या नहीं है।
समस्या #2 - डबल कैशिंग
डेटा एक्सेस प्रदर्शन को बेहतर बनाने के लिए डेटा की कैशिंग महत्वपूर्ण है। डेटा के आवश्यक टुकड़ों को मेमोरी में संग्रहीत करके, लिनक्स कर्नेल जरूरत पड़ने पर उस डेटा को तुरंत याद करने में सक्षम है। लेकिन जिस तरह से FUSE को लागू किया गया है, उसके कारण एंड्रॉइड स्टोर में आवश्यक कैश की मात्रा दोगुनी हो जाती है।
जैसा कि श्री कोवाल्ज़िक प्रदर्शित करते हैं, 10 एमबी फ़ाइल को कैश में ठीक 10 एमबी के रूप में सहेजे जाने की उम्मीद है, लेकिन इसके बजाय कैश आकार तक। लगभग 20एमबी द्वारा। यह कम रैम वाले उपकरणों पर समस्याग्रस्त है, क्योंकि लिनक्स कर्नेल स्टोर डेटा को स्टोर करने के लिए पेज कैश का उपयोग करता है याद। श्री कोवाल्स्की ने इस दृष्टिकोण का उपयोग करके इस डबल कैशिंग समस्या का परीक्षण किया:
- ज्ञात आकार वाली एक फ़ाइल बनाएं (परीक्षण के लिए, 10 एमबी)
- इसे /sdcard पर कॉपी करें
- पेज कैश ड्रॉप करें
- पेज कैश उपयोग का एक स्नैपशॉट लें
- परीक्षण फ़ाइल पढ़ें
- पेज कैश उपयोग का एक और स्नैपशॉट लें
उन्होंने पाया कि उनके परीक्षण से पहले, पेज कैश के लिए कर्नेल द्वारा 241MB का उपयोग किया जा रहा था। एक बार जब उन्होंने अपनी परीक्षण फ़ाइल पढ़ी, तो उन्हें पेज कैश के लिए 251एमबी का उपयोग देखने की उम्मीद थी। इसके बजाय, उसने पाया कि वह कर्नेल उपयोग कर रहा था 263एमबी पेज कैश के लिए - के बारे में अपेक्षा से दोगुना. ऐसा होने का कारण यह है कि डेटा को पहले उपयोगकर्ता एप्लिकेशन द्वारा कैश किया जाता है जिसने मूल रूप से I/O कॉल (FUSE) जारी किया था, और दूसरा sdcard डेमॉन (EXT4 FS) द्वारा।
समस्या #3 - FAT32 का अधूरा कार्यान्वयन
FUSE अनुकरण FAT32 के उपयोग से उत्पन्न होने वाली दो और समस्याएं हैं जो एंड्रॉइड समुदाय में कम व्यापक रूप से ज्ञात हैं।
पहले में शामिल है ग़लत टाइमस्टैम्प. यदि आपने कभी कोई फ़ाइल स्थानांतरित की है (जैसे कि कोई फोटो) और देखा कि टाइमस्टैम्प गलत है, तो यह एंड्रॉइड के FUSE के कार्यान्वयन के कारण है। यह मुद्दा है के लिए अस्तित्व में था साल. अधिक विशिष्ट होने के लिए, इस मुद्दे में शामिल है यूटाइम() सिस्टम कॉल जो आपको फ़ाइल की पहुंच और संशोधन समय को बदलने की अनुमति देता है। दुर्भाग्य से, एक मानक उपयोगकर्ता के रूप में एसडीकार्ड डेमॉन पर की गई कॉल के पास इस सिस्टम कॉल को निष्पादित करने की उचित अनुमति नहीं है। इसके लिए उपाय मौजूद हैं, लेकिन उनके लिए आपको इसकी आवश्यकता होती है रूट पहुंच है.
यदि आपने कभी कोई फ़ाइल स्थानांतरित की है (जैसे कि कोई फोटो) और देखा कि टाइमस्टैम्प गलत है, तो यह एंड्रॉइड के FUSE के कार्यान्वयन के कारण है।
अगली समस्या कुछ इस तरह का उपयोग करने वाले व्यवसायों के लिए अधिक चिंताजनक है स्मार्टएसडी कार्ड. FUSE से पहले, ऐप निर्माता इसकी निगरानी कर सकते थे O_DIRECT झंडा कार्ड में एम्बेडेड माइक्रोकंट्रोलर के साथ संचार करने के लिए। FUSE के साथ, डेवलपर्स केवल फ़ाइल के कैश्ड संस्करण तक पहुंच सकते हैं, और माइक्रोकंट्रोलर द्वारा भेजे गए किसी भी कमांड को देखने में असमर्थ हैं। यह कुछ उद्यम/सरकारी/बैंकिंग ऐप्स के लिए समस्याग्रस्त है जो मूल्य वर्धित माइक्रोएसडी कार्ड के साथ संचार करते हैं।
SDCardFS के लिए डंपिंग FUSE
कुछ ओईएमएस ने इन समस्याओं को पहले ही पहचान लिया और FUSE को बदलने के लिए इन-कर्नेल समाधान की तलाश शुरू कर दी। उदाहरण के लिए, सैमसंग विकसित हुआ एसडीकार्डएफएस जो WrapFS पर आधारित है। यह इन-कर्नेल समाधान FUSE की तरह ही FAT32 का अनुकरण करता है, लेकिन I/O ओवरहेड, डबल कैशिंग और अन्य मुद्दों को छोड़ देता है जिनका मैंने ऊपर उल्लेख किया है। (हां, मैं उस बात को दोहरा दूं, यह समाधान जिसे Google अब लागू कर रहा है वह सैमसंग के काम पर आधारित है).
Google ने अंततः FUSE से जुड़ी कमियों को स्वीकार कर लिया है, यही कारण है कि उन्होंने सैमसंग द्वारा विकसित इन-कर्नेल FAT32 इम्यूलेशन परत की ओर बढ़ना शुरू कर दिया है। कंपनी, जैसा कि उल्लेख किया गया है एंड्रॉइड डेवलपर्स मंच के पीछे पॉडकास्ट, कर्नेल के आगामी संस्करण में सभी उपकरणों के लिए SDCardFS उपलब्ध कराने पर काम कर रहा है। आप वर्तमान में उनकी प्रगति देख सकते हैं AOSP में काम करें.
के तौर पर Google डेवलपर ने पहले समझायाइन-कर्नेल समाधान को लागू करने में सबसे बड़ी चुनौती यह है कि पैकेज नाम को कैसे मैप किया जाए किसी पैकेज के लिए बिना किसी आवश्यकता के बाह्य भंडारण में अपने स्वयं के डेटा तक पहुंचने के लिए एप्लिकेशन आईडी आवश्यक है अनुमतियाँ. लेकिन वह बयान एक साल पहले दिया गया था, और हम उस बिंदु पर पहुंच गए हैं जहां टीम SDCardFS को अपनी "अगली बड़ी चीज़" कह रही है। उन्होंने पहले ही पुष्टि कर दी है कि भयानक टाइमस्टैम्प त्रुटि इसे ठीक कर दिया गया है, FUSE से दूर जाने के लिए धन्यवाद, ताकि हम FUSE के परित्याग के साथ आने वाले सभी परिवर्तनों को देखने के लिए उत्सुक हो सकें।
तथ्य-जाँच संबंधी भ्रांतियाँ
यदि आप लेख में इतनी दूर तक पहुँच गए हैं, तो अब तक सब कुछ बनाए रखने के लिए बधाई! मैं इस लेख को लिखते समय अपने कुछ प्रश्नों को स्पष्ट करना चाहता था:
- SDCardFS के पास है वास्तविक एसडी कार्ड से कोई लेना-देना नहीं. इसका नाम सिर्फ इसलिए रखा गया है क्योंकि यह /sdcard के लिए I/O एक्सेस को संभालता है। और जैसा कि आपको याद होगा, /sdcard एक पुराना लेबल है जो आपके डिवाइस के "बाहरी" स्टोरेज (जहां ऐप्स अपने मीडिया को स्टोर करते हैं) का जिक्र करता है।
- SDCardFS है पारंपरिक फ़ाइल सिस्टम नहीं जैसे FAT32, EXT4, या F2FS. यह एक स्टैकेबल रैपर फ़ाइल सिस्टम है जो निचले, अनुकरणीय फ़ाइल सिस्टम को कमांड भेजता है (इस मामले में, यह /sdcard पर FAT32 होगा)।
- एमटीपी के संबंध में कुछ भी नहीं बदलेगा. आप अपने कंप्यूटर से फ़ाइलें स्थानांतरित करने के लिए एमटीपी का उपयोग करना जारी रखेंगे (जब तक कि Google एक बेहतर प्रोटोकॉल पर समझौता नहीं कर लेता)। लेकिन कम से कम टाइमस्टैम्प त्रुटि ठीक हो जाएगी!
- जैसा कि पहले उल्लेख किया गया है, जब Google "बाहरी संग्रहण" को संदर्भित करता है तो वे या तो (सभी उद्देश्यों के लिए) के बारे में बात कर रहे होते हैं उद्देश्य) आंतरिक /एसडीकार्ड वर्चुअल FAT32 विभाजन या वे वास्तविक, भौतिक, हटाने योग्य माइक्रोएसडी के बारे में बात कर रहे हैं कार्ड. शब्दावली भ्रमित करने वाली है, लेकिन हम इसी से प्रभावित हैं।
निष्कर्ष
FUSE से दूर जाकर और इन-कर्नेल FAT32 इम्यूलेशन लेयर (SDCardFS) को लागू करके, Google कम कर देगा महत्वपूर्ण I/O ओवरहेड, डबल कैशिंग को समाप्त करना, और इसके FUSE के अनुकरण से संबंधित कुछ अस्पष्ट मुद्दों को हल करना FAT32.
चूंकि ये बदलाव कर्नेल में किए जाएंगे, इसलिए इन्हें एंड्रॉइड के किसी बड़े नए संस्करण के बिना भी रोल आउट किया जा सकता है। कुछ उपयोगकर्ता इन परिवर्तनों को आधिकारिक तौर पर एंड्रॉइड 8 में लागू होते देखने की उम्मीद कर रहे हैं, लेकिन यह संभव है किसी भी भविष्य के OTA के लिए पिक्सेल डिवाइस पर लिनक्स कर्नेल संस्करण 4.1 लाने के लिए जिस पर Google काम कर रहा है पर।
आप में से कुछ लोगों के लिए, SDCardFS कोई नई अवधारणा नहीं है। वास्तव में, सैमसंग डिवाइस वर्षों से इसका उपयोग कर रहे हैं (आखिरकार उन्होंने ही इसे विकसित किया था)। जब से SDCardFS को पिछले साल AOSP में पेश किया गया था, कुछ कस्टम ROM और कर्नेल डेवलपर्स ने इसे अपने काम में लागू करना चुना है। CyanogenMOD ने एक समय इसे लागू करने पर विचार किया था, लेकिन जब उपयोगकर्ताओं को अपनी तस्वीरों के साथ समस्याओं का सामना करना पड़ा तो इसे वापस ले लिया। लेकिन उम्मीद है कि Google द्वारा इस परियोजना पर नियंत्रण लेने के साथ, भविष्य के सभी उपकरणों पर Android उपयोगकर्ता FUSE को छोड़ने के साथ शुरू किए गए सुधारों का लाभ उठा सकते हैं।