استكشاف متعمق لـ SDCardFS، بديل Google لـ FUSE، وكيف سيؤدي تنفيذه إلى تقليل حمل الإدخال/الإخراج.
منذ عدة أشهر، أضافت جوجل شيئًا يسمى "SDCardFS" إلى فروع AOSP الرسمية لنواة Linux. في ذلك الوقت، لم يلاحظ هذه الخطوة إلا من قبل بعض مطوري النواة، ولكن خلاف ذلك طار تحت رادار معظم المستخدمين. ليس من المستغرب أن نأخذ في الاعتبار حقيقة أن معظم المستخدمين، بما فيهم أنا، لا يعرفون حقًا ما يحدث تحت غطاء نظام التشغيل Android ونواةه.
ومع ذلك، فإن الحلقة الأخيرة من مطورو أندرويد وراء الكواليس بودكاست جدد الاهتمام بهذا الموضوع. استكشف البودكاست، الذي استضافه شيت هاس (أحد كبار مهندسي البرمجيات في Google)، التغييرات الأخيرة والقادمة التي تم إجراؤها على النواة. كان في العرض مطور Linux kernel يعمل ضمن فريق Android - Rom Lemarchand. ناقش الثنائي في المقام الأول التغييرات التي تم إجراؤها لاستيعاب تحديثات A/B، ولكن في الدقائق الخمس الأخيرة من الحلقة تحدث السيد ليمارشاند عن "الشيء الكبير التالي" الذي كان فريقه يعمل عليه - SDCardFS.
يجب أن أعترف أنني علمت بوجود SDCardFS بعد الاستماع إلى هذا البودكاست. وبطبيعة الحال، لم أكن الوحيد الذي اهتم بهذا الموضوع، ك
شكرًا جزيلاً لمطور البرامج ميشال كووالتشيك لمساهمته بمعرفته في هذه المقالة ولأخذ الوقت الكافي للإجابة على أسئلتي.
"الخارجي" هو داخلي حقًا
في البداية، لا بد أن تكون هناك بعض المفاهيم الخاطئة التي يتعين علينا توضيحها - وإلا فإن بقية المقالة ستكون مربكة للغاية. من المفيد مناقشة تاريخ بطاقات SD وهواتف Android.
في الأيام الأولى لهواتف Android، اعتمدت كل الأجهزة تقريبًا على استخدام بطاقات microSD الخاصة بها للتخزين. كان هذا بسبب حقيقة أن الهواتف في ذلك الوقت كانت مزودة بسعات تخزين داخلية ضئيلة. ومع ذلك، فإن بطاقات SD المستخدمة لتخزين التطبيقات غالبًا لا توفر تجربة مستخدم ممتازة، على الأقل مقارنة بالسرعة التي يمكن بها لذاكرة الفلاش الداخلية قراءة/كتابة البيانات. ولذلك، أصبح الاستخدام المتزايد لبطاقات SD لتخزين البيانات الخارجية مصدر قلق لتجربة المستخدم بالنسبة لشركة Google.
نظرًا للانتشار المبكر لبطاقات SD كأجهزة تخزين خارجية، استندت اصطلاحات تسمية وحدات التخزين في Android إلى حقيقة أن كل جهاز يحتوي على فتحة بطاقة microSD فعلية. ولكن حتى على الأجهزة التي لا تحتوي على فتحة بطاقة SD، ظلت التسمية /sdcard مستخدمة للإشارة إلى شريحة التخزين الداخلية الفعلية. الأمر الأكثر إرباكًا هو حقيقة أن الأجهزة التي تستخدم بطاقة SD الفعلية بالإضافة إلى شريحة تخزين عالية السعة للتخزين غالبًا ما تقوم بتسمية أقسامها بناءً على بطاقة SD. على سبيل المثال، في هذه الأجهزة، تشير نقطة التثبيت /sdcard إلى شريحة التخزين الداخلية الفعلية، في حين تشير نقطة مثل /storage/sdcard1 إلى البطاقة الخارجية الفعلية.
وبالتالي، على الرغم من أن بطاقة microSD تعتبر عمليًا بمثابة وحدة تخزين خارجية، إلا أن اصطلاح التسمية أدى إلى بقاء "SDCard" لفترة طويلة بعد أي استخدام فعلي للبطاقة الفعلية. أدى هذا الخلط مع التخزين أيضًا إلى حدوث بعض الصداع لمطوري التطبيقات نظرًا لحقيقة أن بيانات التطبيق ووسائطه تم فصلها بين القسمين.
أدت مساحة التخزين المنخفضة لشرائح التخزين الداخلية المبكرة إلى اكتشاف المستخدمين بشكل محبط أنهم لم يعد بإمكانهم تثبيت التطبيقات (نظرًا لامتلاء قسم / البيانات). وفي الوقت نفسه، تم نقل بطاقات microSD ذات السعة الأكبر الخاصة بهم إلى الاحتفاظ بالوسائط فقط (مثل الصور والموسيقى والأفلام). قد يتذكر المستخدمون الذين تصفحوا منتدياتنا في الماضي هذه الأسماء: Link2SD وApps2SD. كانت هذه الحلول (الجذرية) مكنت المستخدمين من تثبيت تطبيقاتهم وبياناتها كلها على بطاقة SD الفعلية. لكن هذه الحلول لم تكن مثالية، لذا كان على جوجل أن تتدخل.
من المعروف أن Google قامت بسحب المكونات من بطاقات SD في وقت مبكر جدًا. يظل جهاز Nexus One هو جهاز Nexus الوحيد المزود بفتحة بطاقة microSD (وسيظل كذلك إلى الأبد نظرًا لأن علامة Nexus التجارية قد ماتت فعليًا). مع Nexus S، أصبح هناك الآن قسم واحد موحد لتخزين كافة بيانات ووسائط التطبيق - القسم / البيانات. ما كان يُعرف سابقًا باسم نقطة تحميل /sdcard الآن كان يشير ببساطة إلى نظام ملفات افتراضي (يتم تنفيذه ضمن فيوز البروتوكول كما هو موضح أدناه) الموجود في قسم البيانات - /data/media/0.
من أجل الحفاظ على التوافق وتقليل الارتباك، لا تزال Google تستخدم قسم "sdcard" الظاهري الآن للاحتفاظ بالوسائط. ولكن الآن بعد أن أصبح هذا القسم الافتراضي "sdcard" موجودًا بالفعل داخل /data، فإن أي شيء يتم تخزينه داخله سيتم احتسابه مقابل مساحة التخزين لشريحة التخزين الداخلية. وبالتالي، كان الأمر متروكًا لمصنعي المعدات الأصلية للنظر في مقدار المساحة المخصصة للتطبيقات (/ البيانات) مقابل الوسائط (/ البيانات/ الوسائط).
وكانت جوجل تأمل أن تحذو الشركات المصنعة حذوها وتتخلص من بطاقات SD. لحسن الحظ، مع مرور الوقت، تمكنت الشركات المصنعة للهواتف من توفير هذه المكونات بسعات أعلى مع الحفاظ على فعالية التكلفة، لذلك بدأت الحاجة إلى بطاقات SD في الانخفاض. لكن اصطلاحات التسمية استمرت لتقليل مقدار الجهد الذي يتعين على المطورين ومصنعي المعدات الأصلية بذله للتكيف. حاليًا، عندما نشير إلى "التخزين الخارجي" فإننا نشير إليه إما أحد الأمرين: بطاقة microSD الفعلية القابلة للإزالة أو قسم "SDCard" الافتراضي الموجود في /data/media. والأخيرة من الناحية العملية، هو في الواقع وحدة تخزين داخلية، ولكن اصطلاح التسمية الخاص بـ Google يميزها نظرًا لحقيقة أن هذه البيانات يمكن للمستخدم الوصول إليها (على سبيل المثال عند توصيلها بالكمبيوتر).
حاليًا، عندما نشير إلى "التخزين الخارجي" فإننا نشير إليه إما أحد الأمرين: بطاقة microSD الفعلية القابلة للإزالة أو قسم "SDCard" الافتراضي الموجود في /data/media.
تاريخ أنظمة الملفات الافتراضية لنظام Android
الآن بعد أن تم التعامل مع "sdcard" كنظام ملفات افتراضي، فهذا يعني أنه يمكن تنسيقه كأي نظام ملفات تريده Google. بدءًا من Nexus S وAndroid 2.3، اختارت Google تنسيق "sdcard" كـ VFAT (FAT افتراضي). كانت هذه الخطوة منطقية في ذلك الوقت، نظرًا لأن تركيب VFAT سيسمح لأي كمبيوتر تقريبًا بالوصول إلى البيانات المخزنة على هاتفك. ومع ذلك، كانت هناك مشكلتان رئيسيتان في هذا التنفيذ الأولي.
الأول يتعلق في المقام الأول بالمستخدم النهائي (أنت). لتوصيل جهازك بالكمبيوتر، ستستخدم وضع تخزين USB كبير السعة لنقل البيانات. ومع ذلك، يتطلب هذا من جهاز Android إلغاء تثبيت القسم الظاهري قبل أن يتمكن الكمبيوتر من الوصول إلى البيانات. إذا أراد المستخدم استخدام جهازه أثناء توصيله بالكهرباء، فستظهر العديد من الأشياء على أنها غير متاحة.
ال مقدمة لبروتوكول نقل الوسائط (MTP) حل هذه المشكلة الأولى. عند توصيله، يرى جهاز الكمبيوتر الخاص بك جهازك كجهاز "تخزين الوسائط". فهو يطلب قائمة بالملفات من هاتفك، ويقوم MTP بإرجاع قائمة بالملفات التي يمكن للكمبيوتر تنزيلها من الجهاز. عندما يُطلب حذف ملف، يرسل MTP أمرًا لإزالة الملف المطلوب من التخزين. على عكس وضع تخزين USB كبير السعة الذي يقوم بالفعل بتثبيت "sdcard"، يسمح MTP للمستخدم بمواصلة استخدام أجهزته أثناء توصيله. علاوة على ذلك، لم يعد نظام الملفات الموجود على هاتف Android مهمًا بالنسبة للكمبيوتر للتعرف على الملفات الموجودة على الجهاز.
ثانيًا، كانت هناك حقيقة أن VFAT لم يوفر نوع إدارة الأذونات القوية التي احتاجتها Google. في وقت مبكر، كان العديد من مطوري التطبيقات يعاملون "بطاقة sdcard" باعتبارها مكانًا مليئًا ببيانات تطبيقاتهم، مع عدم وجود إحساس موحد بمكان تخزين ملفاتهم. تقوم العديد من التطبيقات ببساطة بإنشاء مجلد باسم التطبيق الخاص به وتخزين ملفاته هناك.
يتطلب كل تطبيق تقريبًا في ذلك الوقت WRITE_EXTERNAL_STORAGE إذن لكتابة ملفات التطبيق الخاصة بهم إلى وحدة التخزين الخارجية. ومع ذلك، ما كان أكثر إثارة للقلق هو حقيقة أن كل تطبيق تقريبًا يتطلب أيضًا READ_EXTERNAL_STORAGE إذن - فقط لقراءة ملفات البيانات الخاصة بهم! وهذا يعني أنه يمكن للتطبيقات الوصول بسهولة إلى البيانات المخزنة في أي مكان على وحدة التخزين الخارجية، وغالبًا ما يمنح المستخدم هذا الإذن لأنه كان مطلوبًا للعديد من التطبيقات وظيفة.
من الواضح أن جوجل رأت أن هذا يمثل مشكلة. الفكرة الكاملة وراء إدارة الأذونات هي فصل ما يمكن للتطبيقات الوصول إليه وما لا يمكنها الوصول إليه. إذا تم منح كل تطبيق تقريبًا حق الوصول للقراءة إلى بيانات المستخدم التي يحتمل أن تكون حساسة، فإن الإذن لا معنى له. وهكذا، قررت جوجل أنها بحاجة إلى نهج جديد. هذا هو المكان الذي يأتي فيه FUSE.
نظام الملفات في مساحة المستخدم (FUSE)
بدءًا من Android 4.4، قررت Google عدم تحميل قسم "sdcard" الافتراضي باعتباره VFAT. وبدلاً من ذلك، بدأت Google في استخدام FUSE لمحاكاة FAT32 على القسم الظاهري "sdcard". مع استدعاء برنامج sdcard FUSE لمحاكاة أذونات دليل نمط FAT-on-sdcardيمكن أن تبدأ التطبيقات في الوصول إلى بياناتها المخزنة على وحدة تخزين خارجية دون الحاجة إلى أي أذونات. في الواقع، بدءًا من مستوى API 19، لم يعد READ_EXTERNAL_STORAGE مطلوبًا للوصول إلى الملفات الموجودة على وحدة تخزين خارجية - بشرط أن يتطابق مجلد البيانات الذي أنشأه برنامج FUSE مع اسم حزمة التطبيق. سوف يتعامل FUSE تجميع المالك والمجموعة وأوضاع الملفات الموجودة على وحدة التخزين الخارجية عند تثبيت التطبيق.
يختلف FUSE عن الوحدات الموجودة في kernel لأنه يسمح للمستخدمين غير المميزين بكتابة أنظمة ملفات افتراضية. السبب وراء قيام Google بتنفيذ FUSE بسيط إلى حد ما - فقد فعلت ما أرادته وقد فعلت ذلك بالفعل مفهومة جيدا وموثقة في عالم لينكس. على حد تعبير أ مطور جوجل في هذا الشأن:
"نظرًا لأن FUSE عبارة عن واجهة برمجة تطبيقات مستقرة ولطيفة، فلا توجد أي أعمال صيانة مطلوبة عند التنقل بين إصدارات kernel. إذا انتقلنا إلى حل داخل النواة، فسنقوم بالاشتراك في الحفاظ على مجموعة من التصحيحات لكل إصدار مستقر من إصدارات النواة." - جيف شاركي، مهندس برمجيات في Google
ومع ذلك، أصبح من الواضح تمامًا أن النفقات العامة لـ FUSE حققت نجاحًا كبيرًا في الأداء من بين مشكلات أخرى. المطور الذي تحدثت معه بخصوص هذا الأمر، ميشال كووالتشيك، صاغ وظيفة بلوق ممتازة منذ أكثر من عام يعرض تفاصيل المشكلات الحالية المتعلقة بـ FUSE. يمكن قراءة المزيد من التفاصيل التقنية على مدونته، ولكنني سأصف النتائج التي توصل إليها (بإذن منه) بعبارات عامة أكثر.
المشكلة مع فيوز
في Android، يستخدم البرنامج الخفي لمساحة المستخدم "sdcard" FUSE لتركيب /dev/fuse على دليل التخزين الخارجي الذي تمت محاكاته عند التمهيد. بعد ذلك، يقوم البرنامج الخفي sdcard باستقصاء جهاز FUSE عن أي رسائل معلقة من النواة. إذا استمعت إلى البودكاست، فربما سمعت السيد ليمارشاند يشير إلى تقديم FUSE للحمل أثناء عمليات الإدخال/الإخراج - وهذا ما يحدث بشكل أساسي.
في العالم الحقيقي، يؤثر هذا الأداء أي الملف المخزن على وحدة التخزين الخارجية.
المشكلة رقم 1 - حمل الإدخال/الإخراج
لنفترض أننا أنشأنا ملفًا نصيًا بسيطًا، يسمى "test.txt"، وقمنا بتخزينه في /sdcard/test.txt (والذي، دعونا أذكرك، هو في الواقع /data/media/0/test.txt بافتراض أن المستخدم الحالي هو المستخدم الأساسي في جهاز). إذا أردنا قراءة (command cat) هذا الملف، فإننا نتوقع أن يصدر النظام 3 أوامر: فتح، قراءة، ثم إغلاق. في الواقع، كما يوضح السيد كووالتشيك باستخدام Strace، وهذا ما يحدث:
ولكن نظرًا لوجود الملف على وحدة التخزين الخارجية التي تتم إدارتها بواسطة البرنامج الخفي sdcard، فهناك العديد من العمليات الإضافية التي يلزم تنفيذها. وفقًا للسيد كووالتشيك، هناك 8 خطوات إضافية مطلوبة بشكل أساسي كل من هذه الأوامر الفردية الثلاثة:
- يُصدر تطبيق Userspace استدعاء النظام الذي سيتم التعامل معه بواسطة برنامج تشغيل FUSE في kernel (نراه في أول إخراج للخطة)
- يقوم برنامج تشغيل FUSE في kernel بإعلام البرنامج الخفي لمساحة المستخدم (sdcard) بالطلب الجديد
- يقرأ البرنامج الخفي لمساحة المستخدم /dev/fuse
- يقوم برنامج Userspace daemon بتوزيع الأمر والتعرف على عملية الملف (على سبيل المثال. يفتح)
- يُصدر برنامج Userspace daemon استدعاء النظام لنظام الملفات الفعلي (EXT4)
- يتعامل Kernel مع الوصول الفعلي إلى البيانات ويرسل البيانات مرة أخرى إلى مساحة المستخدم
- يقوم Userspace بتعديل (أو لا) البيانات وتمريرها عبر /dev/fuse إلى kernel مرة أخرى
- يكمل Kernel استدعاء النظام الأصلي وينقل البيانات إلى تطبيق مساحة المستخدم الفعلي (في مثالنا cat)
يبدو هذا كثيراً من الحمل فقط إلى أمر الإدخال/الإخراج واحد ليتم تشغيله. وكنت على حق. لإثبات ذلك، حاول السيد كووالتشيك إجراء اختبارين مختلفين للإدخال/الإخراج: أحدهما يتضمن نسخ ملف كبير والآخر نسخ الكثير من الملفات الصغيرة. قام بمقارنة سرعة FUSE (على القسم الظاهري المثبت كـ FAT32) الذي يتعامل مع هذه العمليات مقابل kernel (في قسم البيانات بتنسيق EXT4)، ووجد أن FUSE كان بالفعل يساهم بشكل كبير تكاليف غير مباشرة.
في الاختبار الأول، قام بنسخ ملف بحجم 725 ميجابايت في ظل ظروف الاختبار. وجد أن تطبيق FUSE ينقل ملفات كبيرة 17% أبطأ.
وفي الاختبار الثاني، قام بنسخ 10000 ملف - حجم كل منها 5 كيلو بايت. في هذا السيناريو، انتهى تنفيذ FUSE 40 ثانية أبطأ لنسخ بيانات بقيمة 50 ميجابايت بشكل أساسي.
في العالم الحقيقي، يؤثر هذا الأداء أي الملف المخزن على وحدة التخزين الخارجية. وهذا يعني أن التطبيقات مثل الخرائط التي تقوم بتخزين ملفات كبيرة على /sdcard، وتطبيقات الموسيقى التي تخزن الكثير من ملفات الموسيقى، وتطبيقات الكاميرا والصور، وما إلى ذلك. تتأثر أي عملية إدخال/إخراج يتم تنفيذها والتي تتضمن وحدة تخزين خارجية بالحمل الزائد لـ FUSE. لكن حمل الإدخال/الإخراج ليس هو المشكلة الوحيدة في FUSE.
المشكلة رقم 2 - التخزين المؤقت المزدوج
يعد التخزين المؤقت للبيانات أمرًا مهمًا في تحسين أداء الوصول إلى البيانات. من خلال تخزين الأجزاء الأساسية من البيانات في الذاكرة، تكون نواة Linux قادرة على استدعاء تلك البيانات بسرعة عند الحاجة. ولكن نظرًا للطريقة التي يتم بها تنفيذ FUSE، يقوم Android بتخزين ضعف كمية ذاكرة التخزين المؤقت المطلوبة.
وكما يوضح السيد كووالتشيك، من المتوقع أن يتم حفظ ملف بحجم 10 ميجابايت في ذاكرة التخزين المؤقت بحجم 10 ميجابايت بالضبط، ولكن بدلاً من ذلك يزيد حجمه إلى حجم ذاكرة التخزين المؤقت بحوالي 20 ميجابايت. يعد هذا مشكلة على الأجهزة ذات ذاكرة الوصول العشوائي الأقل، حيث تستخدم مخازن Linux kernel ذاكرة التخزين المؤقت للصفحة لتخزين البيانات فيها ذاكرة. اختبر السيد كووالتشيك مشكلة التخزين المؤقت المزدوج باستخدام هذا الأسلوب:
- قم بإنشاء ملف بحجم معروف (للاختبار، 10 ميجابايت)
- انسخه إلى /sdcard
- قم بإسقاط ذاكرة التخزين المؤقت للصفحة
- خذ لقطة من استخدام ذاكرة التخزين المؤقت للصفحة
- قراءة ملف الاختبار
- التقط لقطة أخرى لاستخدام ذاكرة التخزين المؤقت للصفحة
ما وجده هو أنه قبل اختباره، كانت النواة تستخدم 241 ميجابايت للتخزين المؤقت للصفحة. بمجرد قراءة ملف الاختبار الخاص به، توقع أن يرى 251 ميجابايت مستخدمة في ذاكرة التخزين المؤقت للصفحة. وبدلاً من ذلك، وجد أن تلك النواة كانت تستخدم 263 ميجابايت لذاكرة التخزين المؤقت للصفحة - حول ضعف ما كان متوقعا. سبب حدوث ذلك هو أنه يتم تخزين البيانات مؤقتًا أولاً بواسطة تطبيق المستخدم الذي أصدر في الأصل استدعاء الإدخال / الإخراج (FUSE)، وثانيًا بواسطة البرنامج الخفي sdcard (EXT4 FS).
المشكلة رقم 3 - التنفيذ غير الكامل لـ FAT32
هناك مشكلتان أخريان ناشئتان عن استخدام FUSE الذي يحاكي FAT32 وهما أقل شهرة في مجتمع Android.
الأول ينطوي على الطوابع الزمنية غير صحيحة. إذا سبق لك أن قمت بنقل ملف (مثل صورة) ولاحظت أن الطابع الزمني غير صحيح، فذلك بسبب تطبيق Android لـ FUSE. هذه القضية لديها موجودة ل سنين. ولكي نكون أكثر تحديدا، فإن المسألة تنطوي على يوتايم () استدعاء النظام الذي يسمح لك بتغيير وقت الوصول وتعديل الملف. لسوء الحظ، المكالمات التي يتم إجراؤها إلى البرنامج الخفي sdcard كمستخدم قياسي لا تملك الإذن المناسب لتنفيذ استدعاء النظام هذا. هناك حلول لهذا، لكنها تتطلب منك ذلك لديك حق الوصول إلى الجذر.
إذا سبق لك أن قمت بنقل ملف (مثل صورة) ولاحظت أن الطابع الزمني غير صحيح، فذلك بسبب تطبيق Android لـ FUSE.
المشكلة التالية هي أكثر إثارة للقلق بالنسبة للشركات التي تستخدم شيئًا مثل بطاقة الذاكرة الذكية. قبل FUSE، كان بإمكان صانعي التطبيقات مراقبة علامة O_DIRECT من أجل التواصل مع وحدة التحكم الدقيقة المدمجة في البطاقة. باستخدام FUSE، يمكن للمطورين فقط الوصول إلى النسخة المخزنة مؤقتًا من الملف، ولا يمكنهم رؤية أي أوامر مرسلة بواسطة وحدة التحكم الدقيقة. يعد هذا مشكلة بالنسبة لبعض تطبيقات المؤسسات/الحكومة/الخدمات المصرفية التي تتواصل مع بطاقات microSD ذات القيمة المضافة.
تفريغ FUSE لـ SDCardFS
أدركت بعض شركات تصنيع المعدات الأصلية (OEMS) هذه المشكلات في وقت مبكر، وبدأت في البحث عن حل داخل النواة ليحل محل FUSE. سامسونج، على سبيل المثال، طورت SDCardFS والذي يعتمد على WrapFS. يحاكي هذا الحل الموجود داخل النواة FAT32 تمامًا كما يفعل FUSE، لكنه يتجاهل عبء الإدخال/الإخراج والتخزين المؤقت المزدوج والمشكلات الأخرى التي ذكرتها أعلاه. (نعم، اسمحوا لي أن أكرر هذه النقطة، يعتمد هذا الحل الذي تنفذه Google الآن على عمل Samsung).
لقد اعترفت Google نفسها أخيرًا بالعيوب المرتبطة بـ FUSE، ولهذا السبب بدأت في التحرك نحو طبقة محاكاة FAT32 داخل النواة والتي طورتها Samsung. الشركة كما هو مذكور في مطورو أندرويد وراء الكواليس podcast، تعمل على إتاحة SDCardFS لجميع الأجهزة في الإصدار القادم من kernel. يمكنك حاليًا رؤية التقدم الذي أحرزوه العمل في AOSP.
ك وأوضح مطور جوجل في وقت سابق، التحدي الأكبر في تنفيذ الحل داخل kernel هو كيفية تعيين اسم الحزمة إليه معرف التطبيق ضروري للحزمة للوصول إلى البيانات الخاصة بها في وحدة التخزين الخارجية دون الحاجة إلى أي منها الأذونات. ولكن تم الإدلاء بهذا البيان قبل عام، وقد وصلنا إلى النقطة التي أطلق فيها الفريق على SDCardFS اسم "الشيء الكبير التالي". لقد أكدوا بالفعل أن خطأ الطابع الزمني المخيف تم إصلاحه، وذلك بفضل الابتعاد عن FUSE، لذا يمكننا أن نتطلع إلى رؤية جميع التغييرات التي تم إجراؤها مع التخلي عن FUSE.
التحقق من صحة المفاهيم الخاطئة
إذا وصلت إلى هذا الحد من المقالة، فهنيئًا لك على مواكبة كل شيء حتى الآن! أردت أن أوضح بعض الأسئلة التي طرحتها بنفسي أثناء كتابة هذا المقال:
- يحتوي SDCardFS على لا علاقة لها ببطاقات SD الفعلية. تم تسميته على هذا النحو لأنه يتعامل مع الوصول إلى الإدخال / الإخراج لـ /sdcard. وكما تتذكر، فإن /sdcard هي تسمية قديمة تشير إلى وحدة التخزين "الخارجية" لجهازك (حيث تخزن التطبيقات الوسائط الخاصة بها).
- SDCardFS هو ليس نظام الملفات التقليدي مثل FAT32 أو EXT4 أو F2FS. إنه نظام ملفات مجمع قابل للتكديس يقوم بتمرير الأوامر إلى أنظمة الملفات الأدنى التي تمت محاكاتها (في هذه الحالة، سيكون FAT32 على /sdcard).
- لن يتغير شيء فيما يتعلق بالخطة المتوسطة الأجل. ستستمر في استخدام MTP لنقل الملفات من/إلى جهاز الكمبيوتر الخاص بك (حتى تستقر Google على بروتوكول أفضل). ولكن على الأقل سيتم إصلاح خطأ الطابع الزمني!
- كما ذكرنا من قبل، عندما تشير Google إلى "التخزين الخارجي" فإنهم إما يتحدثون عن (لكل المقاصد و الأغراض) قسم FAT32 الظاهري الداخلي /sdcard أو أنهم يتحدثون عن بطاقة microSD فعلية ومادية وقابلة للإزالة بطاقة. المصطلحات محيرة، لكن هذا ما أذهلنا.
خاتمة
من خلال الابتعاد عن FUSE وتنفيذ طبقة محاكاة FAT32 داخل النواة (SDCardFS)، ستعمل Google على تقليل حمل كبير للإدخال/الإخراج، والقضاء على التخزين المؤقت المزدوج، وحل بعض المشكلات الغامضة المتعلقة بمحاكاة FUSE الخاصة به FAT32.
وبما أن هذه التغييرات سيتم إجراؤها على النواة، فيمكن طرحها بدون إصدار رئيسي جديد من Android بجانبها. ويتوقع بعض المستخدمين رؤية هذه التغييرات مطبقة رسميًا في Android 8، ولكن هذا ممكن لأي OTA مستقبلي على جهاز Pixel لجلب الإصدار 4.1 من Linux kernel الذي تعمل عليه Google على.
بالنسبة للبعض منكم، SDCardFS ليس مفهومًا جديدًا. في الواقع، كانت أجهزة سامسونج تستخدمه منذ سنوات (كانت هي التي قامت بتطويره بعد كل شيء). منذ أن تم تقديم SDCardFS في AOSP العام الماضي، اختار بعض مطوري ROM وkernel المخصصين تطبيقه في عملهم. فكر CyanogenMOD في وقت ما في تنفيذه، لكنه تراجع عنه عندما واجه المستخدمون مشكلات في صورهم. ولكن نأمل مع سيطرة Google على هذا المشروع، أن يتمكن مستخدمو Android على جميع الأجهزة المستقبلية من الاستفادة من التحسينات المقدمة مع التخلي عن FUSE.