الغوص في SDCardFS: كيف ستؤدي عملية استبدال FUSE من Google إلى تقليل النفقات العامة للإدخال / الإخراج

قبل عدة أشهر ، أضافت Google ما يسمى " SDCardFS " إلى فروع AOSP الرسمية لنواة Linux. في ذلك الوقت ، لوحظت هذه الخطوة فقط من قبل بعض مطوري النواة ، ولكن على خلاف ذلك حلقت تحت رادار معظم المستخدمين. ليس من المستغرب أن تفكر في حقيقة أن معظم المستخدمين ، بمن فيهم أنا ، لا يعرفون حقًا ما يحدث تحت غطاء نظام التشغيل Android ونظام التشغيل الخاص به.

ومع ذلك ، جددت الحلقة الأخيرة من podcast Android Developers Backstage الاهتمام بهذا الموضوع. استكمل البودكاست ، الذي استضافه شيت هاسي (كبير مهندسي البرمجيات في Google) ، التغييرات الأخيرة والقادمة التي تمت على النواة. على العرض ، كان هناك مطور يعمل بنظام Linux kernel يعمل على فريق Android - Rom Lemarchand. ناقش الثنائي في المقام الأول التغييرات التي تم إجراؤها لاستيعاب تحديثات A / B ، ولكن في الدقائق الخمس الأخيرة من الحلقة تحدث السيد Lemarchand عن "الشيء الكبير التالي" الذي كان فريقه يعمل عليه - SDCardFS .

يجب أن أعترف أنني علمت بوجود SDCardFS بعد الاستماع إلى هذا البودكاست. بالطبع ، لم أكن الشخص الوحيد الذي يهتم بهذا الموضوع ، كما ظهر في سلسلة رسائل Reddit. ومع ذلك ، لم أكن راضيًا عن التفسير الأساسي الذي تم تقديمه في البودكاست ، وفي محاولة لتبديد بعض المعلومات الخاطئة التي يجري نشرها حولها ، قمت ببعض الأبحاث الخاصة بي وتحدثت مع عدد قليل من الخبراء ذوي المعرفة ذات الصلة حول شيء.

شكرًا جزيلاً لمطور البرامج Michal Kowalczyk على إسهامه بمعرفته في هذا المقال ولأخذ الوقت الكافي للإجابة على أسئلتي.


"الخارجية" الداخلية حقا

مباشرة ، لا بد أن تكون هناك بعض المفاهيم الخاطئة التي يتعين علينا إزالتها - وإلا فإن بقية المقالة ستكون مربكة للغاية. من المفيد مناقشة تاريخ بطاقات SD وهواتف Android.

في الأيام الأولى لهواتف Android ، اعتمد كل جهاز تقريبًا على استخدام بطاقات microSD الخاصة بهم للتخزين. وكان هذا يرجع إلى حقيقة أن الهواتف في الوقت الذي يتم شحنها مع قدرات التخزين الداخلية ضئيلة. ومع ذلك ، فإن بطاقات SD المستخدمة لتخزين التطبيقات غالبًا لا توفر تجربة مستخدم ممتاز ، على الأقل مقارنة بالسرعة التي يمكن بها لذاكرة فلاش الداخلية قراءة / كتابة البيانات. لذلك ، أصبح الاستخدام المتزايد لبطاقات SD لتخزين البيانات الخارجية مصدر قلق لتجربة المستخدم بالنسبة إلى Google.

نظرًا للتكاثر المبكر لبطاقات SD كأجهزة تخزين خارجية ، فقد اعتمدت اتفاقيات تسمية التخزين في Android على حقيقة أن كل جهاز لديه فتحة بطاقة microSD فعلية ومادية. ولكن حتى على الأجهزة التي لا تحتوي على فتحة لبطاقة SD ، لا تزال التسمية / sdcard تستخدم للإشارة إلى شريحة التخزين الداخلية الفعلية. الأمر الأكثر إثارة للحيرة هو أن الأجهزة التي تستخدم كلاً من بطاقة SD الفعلية وكذلك شريحة التخزين عالية السعة للتخزين تقوم غالبًا بتسمية أقسامها القائمة حول بطاقة SD. على سبيل المثال ، في هذه الأجهزة ، تشير نقطة تحميل / sdcard إلى شريحة التخزين الداخلية الفعلية ، بينما يشير شيء مثل / storage / sdcard1 إلى البطاقة الخارجية الفعلية.

وبالتالي ، على الرغم من أن بطاقة microSD تعتبر من الناحية العملية تخزينًا خارجيًا ، فقد نتج عن اصطلاح التسمية "SDCard" الالتصاق طويلًا بأي استخدام فعلي للبطاقة المادية. هذا الارتباك مع التخزين يوفر أيضًا بعض الصداع لمطوري التطبيقات بسبب حقيقة أن بيانات التطبيق ووسائطه تم الفصل بينهما.

أدت مساحة التخزين المنخفضة لرقائق التخزين الداخلية المبكرة إلى اكتشاف المستخدمين بشكل محبط أنهم لم يتمكنوا من تثبيت التطبيقات (بسبب امتلاء قسم / البيانات). وفي الوقت نفسه ، تم تحويل بطاقات microSD ذات السعة الكبيرة إلى الاحتفاظ بالوسائط فقط (مثل الصور والموسيقى والأفلام). قد يتذكر المستخدمون الذين قاموا باستعراض منتدياتنا خلال اليوم هذه الأسماء: Link2SD و Apps2SD. كانت هذه الحلول (الجذر) التي مكّنت المستخدمين من تثبيت تطبيقاتهم وبياناتهم جميعًا على بطاقة SD الفعلية. ولكن هذه الحلول كانت بعيدة عن الحلول المثالية ، لذلك كان على Google أن تتدخل.

اشتهرت Google بسحب قابس بطاقات SD في وقت مبكر جدًا. يظل Nexus One هو الجهاز الوحيد من Nexus مع فتحة لبطاقة microSD (وسيظل كذلك إلى الأبد لأن علامة Nexus التجارية قد ماتت بالفعل). باستخدام جهاز Nexus S ، أصبح هناك الآن قسم واحد موحد لتخزين جميع بيانات التطبيق والوسائط - قسم / البيانات. ما كان يعرف سابقًا باسم / نقطة تحميل sdcard الآن كان يشير ببساطة إلى نظام ملفات ظاهري (يتم تطبيقه بموجب بروتوكول FUSE كما هو موضح أدناه) الموجود في قسم البيانات - / data / media / 0.

من أجل الحفاظ على التوافق وتقليل الالتباس ، لا تزال Google تستخدم هذا القسم "sdcard" الظاهري الآن لعقد الوسائط. ولكن الآن بعد أن تم وضع هذا القسم الظاهري "sdcard" فعليًا داخل / بيانات ، فإن أي شيء يتم تخزينه فيه يمكن حسابه مقابل مساحة التخزين في رقاقة التخزين الداخلية. وبالتالي ، كان الأمر متروكًا لمصنعي المعدات الأصلية للنظر في مقدار المساحة المخصصة للتطبيقات (/ البيانات) مقابل الوسائط (/ البيانات / الوسائط).

اثنين من بطاقات SD مختلفة

كانت Google تأمل في أن يتبع المصنعون مثالهم والتخلص من بطاقات SD. لحسن الحظ ، تمكّن مصنعو الهواتف بمرور الوقت من تحديد مصدر هذه المكونات بسعات أعلى مع الحفاظ على فعالية التكلفة ، لذلك بدأت الحاجة إلى بطاقات SD تنفد. لكن اصطلاحات التسمية استمرت في تقليل مقدار الجهد الذي يتعين على مطوّري المعدات الأصلية ومصنعي المعدات الأصلية القيام به لضبطه. في الوقت الحالي ، عندما نشير إلى "وحدة التخزين الخارجية" ، فإننا نشير إلى أي من أمرين: بطاقة microSD الفعلية القابلة للإزالة أو قسم "SDCard" الافتراضي الموجود في / data / media. هذه الأخيرة ، من الناحية العملية ، هي في الواقع تخزين داخلي ، ولكن اصطلاح تسمية Google يميزها نظرًا لحقيقة أن هذه البيانات في متناول المستخدم (مثل عند توصيلها بالكمبيوتر).

في الوقت الحالي ، عندما نشير إلى "وحدة التخزين الخارجية" ، فإننا نشير إلى أي من أمرين: بطاقة microSD الفعلية القابلة للإزالة أو قسم "SDCard" الافتراضي الموجود في / data / media.


تاريخ نظام الملفات الافتراضي لنظام أندرويد

الآن وقد تم التعامل مع "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 - فقط لقراءة ملفات البيانات الخاصة بهم! هذا يعني أنه يمكن للتطبيقات الوصول بسهولة إلى البيانات المخزنة في أي مكان على وحدة التخزين الخارجية ، وغالبًا ما منح المستخدم هذا الإذن لأنه كان مطلوبًا للعديد من التطبيقات حتى تعمل.

جوجل يرى بوضوح هذا مشكلة. الفكرة الكاملة وراء إدارة الأذونات هي الفصل بين التطبيقات التي يمكن وما لا يمكن الوصول إليها. إذا تم منح كل تطبيق تقريبًا حق الوصول للقراءة إلى بيانات المستخدم التي يحتمل أن تكون حساسة ، فإن الإذن لا معنى له. وهكذا ، قررت جوجل أنها تحتاج إلى نهج جديد. هذا هو المكان الذي يأتي فيوز.


نظام الملفات في Userspace (FUSE)

بدءًا من Android 4.4 ، قررت Google عدم تثبيت قسم "sdcard" الافتراضي كـ VFAT. بدلاً من ذلك ، بدأت Google في استخدام FUSE لمحاكاة FAT32 على القسم الظاهري "sdcard". مع استدعاء برنامج sdcard FUSE لمحاكاة أذونات دليل نمط FAT-on-sdcard ، يمكن أن تبدأ التطبيقات في الوصول إلى البيانات المخزنة على وحدة التخزين الخارجية دون الحاجة إلى أي أذونات . في الواقع ، بدءًا من المستوى 19 من واجهة برمجة التطبيقات ، لم يعد READ_EXTERNAL_STORAGE مطلوبًا للوصول إلى الملفات الموجودة على وحدة التخزين الخارجية - بشرط أن يطابق مجلد البيانات الذي تم إنشاؤه بواسطة البرنامج الخفي FUSE اسم حزمة التطبيق. سوف يتعامل FUSE مع توليف مالك الملفات ومجموعةها وأنماطها على وحدة التخزين الخارجية عند تثبيت أحد التطبيقات.

يختلف FUSE عن الوحدات النمطية في النواة لأنه يتيح للمستخدمين غير المميزين كتابة أنظمة ملفات افتراضية. السبب الذي جعل Google ينفذ FUSE بسيطًا إلى حد ما - لقد فعل ما أرادوه وفُهم بالفعل وتم توثيقه جيدًا في عالم Linux. لاقتباس مطور Google في هذا الشأن:

"نظرًا لأن FUSE عبارة عن واجهة برمجة تطبيقات مستقرة ومستقرة ، فهناك أساسًا أعمال صيانة صفرية مطلوبة عند الانتقال بين إصدارات kernel. إذا انتقلنا إلى حل داخلي ، فسنكون مشتركين للحفاظ على مجموعة من التصحيحات لكل إصدار ثابت من النواة. "-جيف شاركي ، مهندس برامج في Google

ومع ذلك ، أصبح من الواضح تمامًا أن النفقات العامة لشركة FUSE كانت تحقق نجاحًا كبيرًا في الأداء من بين مشكلات أخرى. قام المطور Michal Kowalczyk ، المطور المطور الذي تحدثت إليه بشأن هذا الموضوع ، بنشر منشور مدونة ممتاز منذ أكثر من عام يشرح بالتفصيل المشكلات الحالية مع FUSE. يمكن قراءة المزيد من التفاصيل الفنية على مدونته ، لكنني سأصف النتائج التي توصل إليها (بإذنه) بعبارات أكثر للشخص العادي.


مشكلة فيوز

في Android ، يستخدم البرنامج الخفي لمساحة "sdcard" FUSE لتركيب / dev / fuse على دليل التخزين الخارجي المقلد عند التمهيد. بعد ذلك ، يقوم البرنامج الخفي sdcard باستقصاء جهاز FUSE لأي رسائل معلقة من النواة. إذا كنت قد استمعت إلى البودكاست ، فربما تكون قد سمعت السيد Lemarchand يشير إلى FUSE وهو يقدم النفقات العامة أثناء عمليات I / O - هنا هو ما يحدث بشكل أساسي.

في العالم الحقيقي ، يؤثر هذا الأداء على أي ملف مخزّن على وحدة التخزين الخارجية.

المشكلة رقم 1 - I / O النفقات العامة

دعنا نقول إننا نقوم بإنشاء ملف نصي بسيط ، يسمى "test.txt" ، ونخزنه في / sdcard/test.txt (والذي ، اسمحوا لي أن أذكرك ، هو في الواقع /data/media/0/test.txt على افتراض المستخدم الحالي هو المستخدم الرئيسي على الجهاز). إذا أردنا قراءة (أمر القيادة) هذا الملف ، فإننا نتوقع أن يصدر النظام أوامر 3: فتح ، قراءة ، ثم إغلاق. في الواقع ، كما يوضح السيد كوالسيك باستخدام الضيق ، هذا ما يحدث:

ولكن نظرًا لوجود الملف على وحدة التخزين الخارجية التي تتم إدارتها بواسطة البرنامج الخفي sdcard ، فهناك العديد من العمليات الإضافية التي يلزم تنفيذها. وفقًا للسيد كوالسيك ، هناك 8 خطوات إضافية ضرورية لكل من هذه الأوامر الفردية الثلاثة :

  1. مشكلات نظام تطبيق Userspace التي سيتم معالجتها بواسطة برنامج تشغيل FUSE في kernel (نراها في إخراج الشريط الأول)
  2. يقوم برنامج تشغيل FUSE في kernel بإعلام برنامج userpace daemon (sdcard) حول الطلب الجديد
  3. يقرأ مساحة المستخدم الخفية / ديف / فيوز
  4. يوزع الأمر userpace parses ويتعرف على تشغيل الملفات (على سبيل المثال ، فتح)
  5. Userspace daemon يصدر استدعاء النظام إلى نظام الملفات الفعلي (EXT4)
  6. يعالج Kernel الوصول إلى البيانات الفعلية ويرسل البيانات مرة أخرى إلى مساحة المستخدمين
  7. يقوم Userspace بتعديل (أو عدم) البيانات وتمريرها عبر / dev / fuse إلى kernel مرة أخرى
  8. يُكمل Kernel مكالمة النظام الأصلية وينقل البيانات إلى تطبيق مساحة المستخدمين الفعلية (في مثال قطة لدينا)

هذا يبدو مثل الكثير من الحمل فقط لأمر I / O واحد ليتم تشغيلها. وكنت على حق. لإثبات ذلك ، حاول السيد كوولتشيك اختبارين مختلفين للإدخال / الإخراج: أحدهما يتضمن نسخ ملف كبير والآخر ينسخ الكثير من الملفات الصغيرة. قام بمقارنة سرعة FUSE (على القسم الظاهري المركب كـ FAT32) بمعالجة هذه العمليات مقابل النواة (في قسم البيانات المنسق كـ EXT4) ، ووجد أن FUSE كانت تساهم بالفعل في زيادة النفقات العامة بشكل كبير.

في الاختبار الأول ، قام بنسخ ملف 725 ميجابايت في ظل كل ظروف الاختبار. وجد أن تنفيذ FUSE نقل الملفات الكبيرة 17 ٪ أكثر ببطء .

في الاختبار الثاني ، قام بنسخ 10000 ملف - كل منها بحجم 5 كيلوبايت. في هذا السيناريو ، كان تنفيذ FUSE أكثر من 40 ثانية أبطأ لنسخ البيانات بقيمة 50 ميغابايت بشكل أساسي.

في العالم الحقيقي ، يؤثر هذا الأداء على أي ملف مخزّن على وحدة التخزين الخارجية. هذا يعني أن التطبيقات مثل خرائط تخزين الملفات الكبيرة على / sdcard ، وتطبيقات الموسيقى التي تخزن الكثير من ملفات الموسيقى ، وتطبيقات الكاميرا والصور ، وما إلى ذلك تتأثر أي عملية إدخال / إخراج يجري تنفيذها تنطوي على وحدة التخزين الخارجية بنفقات FUSE العامة. لكن I / O الحمل ليس هو المشكلة الوحيدة مع FUSE.

المشكلة رقم 2 - التخزين المؤقت المزدوج

التخزين المؤقت للبيانات مهم في تحسين أداء الوصول إلى البيانات. من خلال تخزين أجزاء أساسية من البيانات في الذاكرة ، يمكن لنواة Linux استعادة تلك البيانات بسرعة عند الحاجة. ولكن نظرًا للطريقة التي يتم بها تطبيق FUSE ، يقوم Android بتخزين مقدار ذاكرة التخزين المؤقت المطلوب.

كما يوضح Mr. Kowalczyk ، من المتوقع أن يتم حفظ ملف بحجم 10 ميغابايت في ذاكرة التخزين المؤقت مثل 10 ميغابايت بالضبط ، ولكن بدلاً من ذلك يصل حجم ذاكرة التخزين المؤقت إلى حوالي 20 ميغابايت. هذا يمثل مشكلة على الأجهزة ذات ذاكرة الوصول العشوائي الأقل ، حيث تستخدم Linux kernel ذاكرة التخزين المؤقت للصفحة لتخزين البيانات في الذاكرة. السيد Kowalczyk اختبر هذه المشكلة التخزين المؤقت المزدوج باستخدام هذا النهج:

  1. إنشاء ملف بحجم معروف (للاختبار ، 10 ميغابايت)
  2. انسخها إلى / sdcard
  3. إسقاط ذاكرة التخزين المؤقت الصفحة
  4. التقط لقطة لاستخدام ذاكرة التخزين المؤقت للصفحة
  5. قراءة ملف الاختبار
  6. التقط لقطة أخرى لاستخدام ذاكرة التخزين المؤقت للصفحة

ما وجده أنه قبل اختباره ، كان يتم استخدام 241 ميغابايت بواسطة النواة لذاكرة التخزين المؤقت للصفحة. بمجرد قراءة ملف الاختبار الخاص به ، توقع أن يرى 251 ميغابايت تستخدم لذاكرة التخزين المؤقت للصفحة. بدلاً من ذلك ، وجد أن kernel كان يستخدم 263 ميغابايت لذاكرة التخزين المؤقت للصفحة - أي ضعف ما كان متوقعًا . سبب حدوث ذلك هو أن البيانات يتم تخزينها مؤقتًا أولاً بواسطة تطبيق المستخدم الذي أصدر أصلاً استدعاء الإدخال / الإخراج (FUSE) ، والثاني بواسطة البرنامج الخفي sdcard (EXT4 FS).

المشكلة رقم 3 - التنفيذ غير الكامل لـ FAT32

هناك مشكلتان أخريان ناشئتان عن استخدام FUSE لمضاهاة FAT32 الأقل شهرة في مجتمع Android.

الأول ينطوي على الطوابع الزمنية غير صحيحة . إذا قمت بنقل ملف من أي وقت مضى (مثل صورة) ولاحظت أن الطابع الزمني غير صحيح ، فهذا بسبب تطبيق Android لـ FUSE. هذه المشكلة موجودة منذ سنوات . لكي تكون أكثر تحديدًا ، تتضمن المشكلة استدعاء نظام utime () الذي يسمح لك بتغيير وقت الوصول وتعديل الملف. لسوء الحظ ، لا تتمتع المكالمات التي تم إجراؤها على البرنامج الخفي sdcard كمستخدم قياسي بالإذن المناسب لتنفيذ مكالمة النظام هذه. هناك حلول لهذا ، ولكنها تتطلب منك أن يكون لديك وصول إلى الجذر.

إذا قمت بنقل ملف من أي وقت مضى (مثل صورة) ولاحظت أن الطابع الزمني غير صحيح ، فهذا بسبب تطبيق Android لـ FUSE.

المشكلة التالية تهم الشركات التي تستخدم شيئًا مثل بطاقة SmartSD. قبل FUSE ، كان بإمكان صانعي التطبيقات مراقبة علامة O_DIRECT من أجل التواصل مع متحكم مدمج في البطاقة. مع FUSE ، يمكن للمطورين الوصول فقط إلى النسخة المخبأة من الملف ، ولا يمكنهم رؤية أي أوامر يتم إرسالها بواسطة متحكم. هذا يمثل مشكلة لبعض تطبيقات المؤسسات / الحكومة / المصرفية التي تتصل ببطاقات microSD ذات القيمة المضافة.


الإغراق فيوز ل SDCardFS

تعرفت بعض OEMS على هذه المشكلات في وقت مبكر ، وبدأت في البحث عن حل داخلي لاستبدال FUSE. قامت شركة Samsung ، على سبيل المثال ، بتطوير SDCardFS الذي يستند إلى WrapFS. يحاكي هذا الحل in-kernel FAT32 مثلما يفعل FUSE ، ولكن يتجاهل الحمل / الإخراج المؤقت ، والتخزين المؤقت المزدوج ، وغيرها من المشكلات التي ذكرتها أعلاه. (نعم ، اسمحوا لي أن أكرر هذه النقطة ، أن هذا الحل الذي تقوم Google بتطبيقه الآن يعتمد على عمل Samsung ).

أقرت Google أخيرًا بالعيوب المرتبطة بـ FUSE ، وهذا هو السبب في أنها بدأت تتحرك نحو طبقة مضاهاة FAT32 الداخلية التي طورتها شركة Samsung. تعمل الشركة ، كما هو مذكور في بودكاست Android Developers Backstage ، على توفير SDCardFS لجميع الأجهزة في إصدار قادم من النواة. يمكنك حاليًا رؤية تقدم أعمالهم في AOSP.

كما أوضح أحد مطوري Google في وقت سابق ، فإن التحدي الأكبر في تطبيق حل داخلي هو كيفية تعيين اسم الحزمة لمعرف التطبيق الضروري لحزمة للوصول إلى بياناتها في وحدة تخزين خارجية دون الحاجة إلى أي أذونات. ولكن تم الإدلاء بهذا التصريح قبل عام ، ووصلنا إلى النقطة التي يدعو فيها الفريق SDCardFS إلى "الشيء الكبير التالي". لقد أكدوا بالفعل أن خطأ الطابع الزمني المروع قد تم إصلاحه ، وذلك بفضل الابتعاد عن FUSE ، حتى يتسنى لنا أن نتطلع إلى رؤية جميع التغييرات التي طرحت مع التخلي عن FUSE.


التحقق من صحة المفاهيم الخاطئة

إذا كنت قد وصلت إلى هذا الحد في المقالة ، فعندئذٍ يمكنك متابعة كل شيء حتى الآن! أردت أن أوضح بعض الأسئلة التي كانت لدي عند كتابة هذا المقال:

  • لا علاقة لـ SDCardFS ببطاقات SD الفعلية . تتم تسمية فقط على هذا النحو لأنه يعالج وصول I / O لـ / sdcard. وكما تتذكر ، فإن / sdcard هي علامة قديمة تشير إلى التخزين "الخارجي" لجهازك (حيث تخزن التطبيقات وسائطها).
  • SDCardFS ليس نظام ملفات تقليدي مثل FAT32 أو EXT4 أو F2FS. إنه نظام ملفات مجمّع قابل للتكديس يقوم بتمرير الأوامر إلى أنظمة الملفات الأقل مضاهاة (في هذه الحالة ، سيكون FAT32 على / sdcard).
  • لن يتغير شيء بالنسبة إلى MTP . ستستمر في استخدام MTP لنقل الملفات إلى / من جهاز الكمبيوتر الخاص بك (حتى يستقر Google على بروتوكول أفضل). ولكن على الأقل سيتم إصلاح خطأ الطابع الزمني!
  • كما ذكرنا من قبل ، عندما تشير Google إلى "وحدة التخزين الخارجية" ، فهي إما تتحدث عن قسم FAT32 الظاهري / SDCARD الداخلي / SDCARD (أو لجميع الأغراض) أو يتحدثون عن بطاقة microSD فعلية وجسدية وقابلة للنقل. المصطلحات مربكة ، لكن هذا ما صدمنا به.

خاتمة

من خلال الابتعاد عن FUSE وتطبيق طبقة مضاهاة FAT32 داخلية (SDCardFS) ، ستعمل Google على تقليل النفقات العامة للإدخال / الإخراج الكبيرة ، والتخلص من التخزين المؤقت المزدوج ، وحل بعض المشكلات الغامضة المتعلقة بمضاهاة FUSE لـ FAT32.

نظرًا لأن هذه التغييرات سيتم إجراؤها على نواة ، فيمكن طرحها دون إصدار جديد رئيسي من نظام Android بجانبه. يتوقع بعض المستخدمين رؤية هذه التغييرات مطبقة رسميًا في Android 8 ، ولكن من الممكن لأي OTA في المستقبل على جهاز Pixel أن يقدم إصدار Linux kernel 4.1 الذي تعمل عليه Google.

بالنسبة لبعضكم ، SDCardFS ليس مفهوما جديدا. في الواقع ، كانت أجهزة Samsung تستخدمها لسنوات (كانت تلك الأجهزة لتطويرها بعد كل شيء). منذ تقديم SDCardFS في AOSP العام الماضي ، اختار بعض مطوري ROM و kernel المخصصين تطبيقه في عملهم. نظرت CyanogenMOD في مرحلة ما في تنفيذه ، لكن أعادته عندما واجه المستخدمون مشاكل مع صورهم. ولكن نأمل مع Google أن تستحوذ على هذا المشروع ، يمكن لمستخدمي Android على جميع الأجهزة المستقبلية الاستفادة من التحسينات المقدمة مع التخلي عن FUSE.