צלילה לתוך SDCardFS: כיצד החלפת ה-FUSE של גוגל תפחית את תקורה של I/O

Xda אנדרואידOct 29, 2023

חקירה מעמיקה של SDCardFS, המחליף של גוגל ל-FUSE, וכיצד היישום שלו יקטין את תקורה של I/O.

לפני מספר חודשים, גוגל הוסיפה משהו שנקרא "SDCardFS" לסניפי AOSP הרשמיים עבור ליבת לינוקס. בזמנו, המהלך הבחין רק על ידי מפתחי ליבה מסוימים, אבל חוץ מזה טס מתחת לרדאר של רוב המשתמשים. אין הפתעה שם בהתחשב בעובדה שרוב המשתמשים, כולל אני, לא באמת יודעים מה קורה מתחת למכסה המנוע של מערכת ההפעלה אנדרואיד והקרנל שלה.

עם זאת, הפרק האחרון של מפתחי אנדרואיד מאחורי הקלעים הפודקאסט התחדש בעניין בנושא זה. הפודקאסט, בהנחייתו של Chet Haase (מהנדס תוכנה בכיר בגוגל), בחן שינויים אחרונים וצפויים שבוצעו בקרנל. בתוכנית היה מפתח ליבת לינוקס שעבד בצוות אנדרואיד - Rom Lemarchand. הצמד דנו בעיקר באילו שינויים נעשו כדי להתאים לעדכוני A/B, אבל ב-5 הדקות האחרונות של הפרק דיבר מר למרצ'נד על "הדבר הגדול הבא" שהצוות שלו עבד עליו - SDCardFS.

אני חייב להודות שלמדתי על קיומו של SDCardFS לאחר האזנה לפודקאסט הזה. כמובן, לא הייתי היחיד שהתעניין בנושא הזה, בתור א שרשור Reddit האחרון הראה. עם זאת, לא הייתי מרוצה מההסבר הבסיסי שהוצע בפודקאסט, ובמאמץ להפיג חלק מה מידע שגוי שהופץ מסביב, עשיתי קצת מחקר משלי ודיברתי עם כמה מומחים עם ידע רלוונטי בנושא חוֹמֶר.

תודה גדולה למפתחת התוכנה מיכל קובלצ'יק על שתרם מהידע שלו למאמר זה ועל שהקדשת מזמנך לענות על שאלותי.

"חיצוני" זה באמת פנימי

מיד בהתחלה, בטח יש כמה תפיסות שגויות שאנחנו צריכים להבהיר - אחרת שאר המאמר יהיה מאוד מבלבל. זה מועיל לדון בהיסטוריה של כרטיסי SD וטלפונים אנדרואיד.

בימים הראשונים של טלפונים אנדרואיד, כמעט כל מכשיר הסתמך על שימוש בכרטיסי ה-microSD שלהם לאחסון. זה נבע מהעובדה שטלפונים בזמנו נשלחו עם יכולות אחסון פנימיות זעירות. עם זאת, כרטיסי SD המשמשים לאחסון יישומים לרוב אינם מספקים חווית משתמש מהממת, לפחות בהשוואה למהירות שבה זיכרון פלאש פנימי יכול לקרוא/לכתוב נתונים. לכן, השימוש הגובר בכרטיסי SD לאחסון נתונים חיצוני הפך לדאגה לחוויית משתמש עבור Google.

בשל התפשטותם המוקדמת של כרטיסי SD כהתקני אחסון חיצוניים, מוסכמות שמות האחסון של אנדרואיד התבססו על העובדה שלכל מכשיר יש חריץ פיזי של כרטיס microSD. אבל אפילו במכשירים שלא הכילו חריץ לכרטיס SD, עדיין נעשה שימוש בתווית /sdcard כדי להצביע על שבב האחסון הפנימי בפועל. מבלבל יותר הוא העובדה שמכשירים שהשתמשו גם בכרטיס SD פיזי וגם בשבב אחסון בעל קיבולת גבוהה לאחסון היו לרוב שמות למחיצות שלהם מבוססות סביב כרטיס ה-SD. לדוגמה, במכשירים אלה נקודת ההרכבה /sdcard תתייחס לשבב האחסון הפנימי בפועל, בעוד שמשהו כמו /storage/sdcard1 יתייחס לכרטיס החיצוני הפיזי.

לפיכך, למרות שכרטיס ה-microSD נחשב למעשה לאחסון חיצוני, מוסכמות השמות הביאה לכך ש-"SDCard" נשאר הרבה מעבר לכל שימוש בפועל בכרטיס פיזי. הבלבול הזה עם אחסון סיפק גם כאב ראש מסוים למפתחי אפליקציות בשל העובדה שנתוני האפליקציה והמדיה שלה היו מופרדים בין שתי המחיצות.

שטח האחסון הנמוך של שבבי אחסון פנימיים מוקדמים גרם למשתמשים לגלות באופן מתסכל שהם לא יכולים יותר להתקין יישומים (בשל מחיצת /data מלאה). בינתיים, כרטיסי ה-microSD הקיבולת הגדולה יותר שלהם נדחקו לאחסון מדיה בלבד (כגון תמונות, מוזיקה וסרטים). משתמשים שגלשו בפורומים שלנו בזמנו עשויים לזכור את השמות הבאים: Link2SD ו-Apps2SD. אלו היו פתרונות (שורש) שאפשרו למשתמשים להתקין את היישומים שלהם ואת הנתונים שלהם כולם על כרטיס ה-SD הפיזי. אבל אלה היו רחוקים מלהיות פתרונות מושלמים, אז גוגל נאלצה להתערב.

באופן מפורסם, גוגל ניתקה את התקע בכרטיסי SD בשלב מוקדם מאוד. ה-Nexus One נשאר מכשיר ה-Nexus היחיד עם חריץ לכרטיס microSD (וזה לנצח יהיה מאז שהמותג Nexus מת למעשה). עם ה-Nexus S, הייתה כעת רק מחיצה אחת מאוחדת לאחסון כל נתוני האפליקציה והמדיה - מחיצת /data. מה שפעם היה ידוע בתור נקודת ההרכבה /sdcard היה פשוט מתייחס למערכת קבצים וירטואלית (מיושם תחת נתיך פרוטוקול כפי שנדון להלן) הממוקם במחיצת הנתונים - /data/media/0.

על מנת לשמור על תאימות ולהפחית בלבול, גוגל עדיין השתמשה במחיצת "SDCARD" הווירטואלית הזו כדי להחזיק מדיה. אבל עכשיו, כשהמחיצה הווירטואלית "sdcard" הזו הייתה למעשה ממוקמת בתוך /data, כל דבר המאוחסן בתוכה ייחשב כנגד שטח האחסון של שבב האחסון הפנימי. לפיכך, זה היה תלוי ביצרני OEM לשקול כמה מקום להקצות ליישומים (/data) לעומת מדיה (/data/media).

שני "כרטיסי SD" שונים מאוד

גוגל קיוותה שיצרנים ילכו בעקבותיהם וייפטרו מכרטיסי SD. למרבה המזל, עם הזמן יצרני טלפונים הצליחו להשיג את הרכיבים הללו בקיבולת גבוהה יותר תוך שהם נשארו חסכוניים, כך שהצורך בכרטיסי SD החל להצטמצם. אבל מוסכמות השמות נמשכו כדי להפחית את כמות המאמץ שמפתחים ויצרני OEM יצטרכו לעשות כדי להתאים. נכון לעכשיו, כאשר אנו מתייחסים ל"אחסון חיצוני" אנו מתכוונים אליו אחד משני דברים: כרטיס ה-microSD הנשלף בפועל או מחיצת "SDCard" הוירטואלית הממוקמת ב-/data/media. האחרון שבהם, למעשה, הוא למעשה אחסון פנימי, אך מוסכמות השמות של גוגל מבדילה אותו בשל העובדה שהנתונים הללו נגישים למשתמש (כגון כאשר הם מחוברים למחשב).

נכון לעכשיו, כאשר אנו מתייחסים ל"אחסון חיצוני" אנו מתכוונים אליו אחד משני דברים: כרטיס ה-microSD הנשלף בפועל או מחיצת "SDCard" הוירטואלית הממוקמת ב-/data/media.

ההיסטוריה של מערכות הקבצים הווירטואליות של אנדרואיד

כעת, כאשר מתייחסים ל"sdcard" כאל מערכת קבצים וירטואלית, זה אומר שניתן לעצב אותו כמו כל מערכת קבצים שגוגל רצתה. החל מה-Nexus S ו-Android 2.3, גוגל בחרה לעצב "sdcard" כ-VFAT (FAT וירטואלי). מהלך זה היה הגיוני בזמנו, מכיוון שהרכבת VFAT תאפשר כמעט לכל מחשב לגשת לנתונים המאוחסנים בטלפון שלך. עם זאת, היו שתי בעיות עיקריות ביישום הראשוני הזה.

הראשון נוגע בעיקר למשתמש הקצה (אתה). על מנת לחבר את המכשיר למחשב, תשתמש במצב אחסון המוני USB כדי להעביר נתונים. עם זאת, זה חייב את מכשיר האנדרואיד לבטל את טעינת המחיצה הווירטואלית לפני שהמחשב יוכל לגשת לנתונים. אם משתמש רצה להשתמש במכשיר שלו כשהוא מחובר לחשמל, דברים רבים יראו כלא זמינים.

ה הצגת פרוטוקול העברת המדיה (MTP) פתר את הבעיה הראשונה הזו. כאשר הוא מחובר לחשמל, המחשב שלך רואה את המכשיר שלך כהתקן "אחסון מדיה". הוא מבקש רשימה של קבצים מהטלפון שלך, ו-MTP מחזיר רשימה של קבצים שהמחשב יכול להוריד מהמכשיר. כאשר קובץ מתבקש להימחק, MTP שולח פקודה להסיר את הקובץ המבוקש מהאחסון. בניגוד ל-USB Mass Storage Mode שלמעשה מעלה את ה"sdcard", MTP מאפשר למשתמש להמשיך להשתמש במכשיר שלו בזמן שהוא מחובר לחשמל. יתר על כן, מערכת הקבצים הקיימת בטלפון אנדרואיד כבר לא חשובה למחשב לזהות את הקבצים במכשיר.

שנית, הייתה העובדה ש-VFAT לא סיפקה סוג של ניהול הרשאות חזק שגוגל הייתה צריכה. בשלב מוקדם, מפתחי יישומים רבים יתייחסו ל-"SDCARD" כאל מגרש לזרוק לנתוני האפליקציה שלהם, ללא תחושה מאוחדת היכן לאחסן את הקבצים שלהם. יישומים רבים פשוט יוצרים תיקיה עם שם האפליקציה שלה ומאחסנים שם את הקבצים שלה.

כמעט כל יישום שהיה בזמנו דרש את WRITE_EXTERNAL_STORAGE הרשאה לכתוב את קבצי היישום שלהם לאחסון החיצוני. עם זאת, מה שהיה מטריד יותר היה העובדה שכמעט כל יישום גם דרש את READ_EXTERNAL_STORAGE הרשאה - רק לקרוא את קבצי הנתונים שלהם! המשמעות היא שלאפליקציות יכלו בקלות לקבל גישה לנתונים המאוחסנים בכל מקום באחסון החיצוני, והרשאה כזו ניתנה לעתים קרובות על ידי המשתמש מכיוון שהיא נדרשה עבור אפליקציות רבות להתאזן פוּנקצִיָה.

ברור שגוגל ראתה את זה כבעייתי. כל הרעיון מאחורי ניהול ההרשאות הוא להפריד בין אילו אפליקציות יכולות ואינן יכולות לקבל גישה. אם כמעט לכל אפליקציה ניתנת גישת קריאה לנתוני משתמש שעלולים להיות רגישים, ההרשאה היא חסרת משמעות. לפיכך, גוגל החליטה שהם צריכים גישה חדשה. זה המקום שבו FUSE נכנס לתמונה.

מערכת קבצים במרחב המשתמש (FUSE)

החל מאנדרואיד 4.4, גוגל החליטה לא להעלות עוד את מחיצת ה"sdcard" הווירטואלית כ-VFAT. במקום זאת, גוגל החלה להשתמש ב-FUSE כדי לחקות את FAT32 במחיצה הוירטואלית "sdcard". עם תוכנית sdcard קורא FUSE כדי לחקות הרשאות ספרייה בסגנון FAT-on-sdcard, יישומים יכולים להתחיל לגשת לנתונים המאוחסנים באחסון חיצוני ללא צורך בהרשאות כלשהן. ואכן, החל מ-API Level 19, READ_EXTERNAL_STORAGE לא נדרש עוד כדי לגשת לקבצים הממוקמים באחסון חיצוני - בתנאי שתיקיית הנתונים שנוצרה על ידי הדמון FUSE תואמת את שם החבילה של האפליקציה. FUSE יטפל סינתזה של הבעלים, הקבוצה והמצבים של קבצים באחסון חיצוני כאשר אפליקציה מותקנת.

FUSE שונה ממודולים בתוך הליבה מכיוון שהוא מאפשר למשתמשים שאינם מורשים לכתוב מערכות קבצים וירטואליות. הסיבה שגוגל הטמיעה את FUSE היא די פשוטה - זה עשה מה שהם רצו וכבר היה מובן ומתועד היטב בעולם של לינוקס. כדי לצטט את א מפתח גוגל בעניין:

"מכיוון ש-FUSE הוא ממשק API יציב ונחמד, אין למעשה אפס עבודת תחזוקה הנדרשת בעת מעבר בין גרסאות ליבה. אם נעבור לפתרון בתוך הליבה, היינו נרשמים לתחזוקת ערכת תיקונים עבור כל גרסת ליבה יציבה." -ג'ף שארקי, מהנדס תוכנה בגוגל

עם זאת, היה ברור למדי שהתקורה של FUSE מציגה להיט בביצועים בין שאר הנושאים. המפתחת שאיתה דיברתי בעניין זה, מיכל קובלצ'יק, כתב פוסט מצוין בבלוג לפני יותר משנה פירט את הבעיות הנוכחיות עם FUSE. פרטים טכניים נוספים ניתן לקרוא בבלוג שלו, אבל אתאר את ממצאיו (ברשותו) במונחים של הדיוטות יותר.

הבעיה עם FUSE

באנדרואיד, דמון מרחב המשתמש "sdcard" משתמש ב-FUSE כדי להעלות את /dev/fuse לספריית האחסון החיצונית המדומה בעת האתחול. לאחר מכן, הדמון sdcard בודק את מכשיר ה-FUSE עבור כל הודעות ממתינות מהקרנל. אם הקשבתם לפודקאסט, אולי שמעתם את מר למרצ'נד מתייחס ל-FUSE מציג תקורה במהלך פעולות I/O - הנה בעצם מה שקורה.

בעולם האמיתי, להיט הביצועים הזה משפיע כל קובץ מאוחסן באחסון חיצוני.

בעיה מס' 1 - תקורה של I/O

נניח שאנו יוצרים קובץ טקסט פשוט, הנקרא "test.txt", ומאחסנים אותו ב-/sdcard/test.txt (שמאפשרים להזכירך, האם למעשה /data/media/0/test.txt בהנחה שהמשתמש הנוכחי הוא המשתמש הראשי ב- התקן). אם היינו רוצים לקרוא (פקודה חתול) את הקובץ הזה, היינו מצפים שהמערכת תוציא 3 פקודות: פתח, קרא ואז סגור. ואכן, כפי שמדגים מר קובלצ'יק באמצעות רצועה, זה מה שקורה:

אבל מכיוון שהקובץ ממוקם באחסון החיצוני המנוהל על ידי ה-sdcard daemon, יש הרבה פעולות נוספות שצריך לבצע. לדברי מר קובלצ'יק, יש בעצם 8 שלבים נוספים הדרושים עבור כל אחת משלוש הפקודות האישיות הללו:

  1. אפליקציית Userspace מנפיקה קריאת מערכת שתטופל על ידי מנהל ההתקן של FUSE בליבה (אנחנו רואים את זה בפלט ה-strace הראשון)
  2. מנהל ההתקן של FUSE בקרנל מודיע ל-userspace daemon (sdcard) על בקשה חדשה
  3. דמון מרחב המשתמש קורא /dev/fuse
  4. Userspace daemon מנתח פקודה ומזהה פעולת קובץ (לדוגמה. לִפְתוֹחַ)
  5. Userspace daemon מוציא קריאת מערכת למערכת הקבצים בפועל (EXT4)
  6. Kernel מטפל בגישה פיזית לנתונים ושולח נתונים בחזרה למרחב המשתמש
  7. Userspace משנה (או לא) נתונים ומעביר אותם דרך /dev/fuse לקרנל שוב
  8. הקרנל משלים קריאת מערכת מקורית ומעביר נתונים ליישום מרחב המשתמש בפועל (בדוגמה שלנו cat)

זה נראה כמו הרבה של תקורה רק לפקודת I/O יחידה שתתבצע. ואתה תהיה צודק. כדי להדגים זאת, מר קובלצ'יק ניסה שני מבחני קלט/פלט שונים: האחד כלל העתקת קובץ גדול והשני העתקה של הרבה קבצים קטנים. הוא השווה את המהירות של FUSE (במחיצה הוירטואלית המותקנת כ-FAT32) המטפל בפעולות אלה לעומת הקרנל (במחיצת הנתונים המעוצבת כ-EXT4), והוא גילה שה-FUSE אכן תורם משמעותית מעל.

בבדיקה הראשונה, הוא העתיק קובץ של 725MB בשני תנאי הבדיקה. הוא גילה שהיישום של FUSE העביר קבצים גדולים 17% יותר לאט.

בבדיקה השנייה הוא העתיק 10,000 קבצים - כל אחד מהם בגודל 5KBs. בתרחיש זה, יישום ה-FUSE הסתיים 40 שניות לאט יותר להעתיק בעצם 50MBs של נתונים.

בעולם האמיתי, להיט הביצועים הזה משפיע כל קובץ מאוחסן באחסון חיצוני. המשמעות היא אפליקציות כמו מפות המאחסנות קבצים גדולים ב-/sdcard, אפליקציות מוזיקה המאחסנות טונות של קבצי מוזיקה, אפליקציות מצלמה ותמונות וכו'. כל פעולת קלט/פלט שמתבצעת הכוללת את האחסון החיצוני מושפעת מהתקורה של FUSE. אבל תקורה של I/O היא לא הבעיה היחידה עם FUSE.

בעיה מס' 2 - מטמון כפול

שמירה במטמון של נתונים חשובה בשיפור ביצועי הגישה לנתונים. על ידי אחסון חלקי נתונים חיוניים בזיכרון, ליבת לינוקס מסוגלת לזכור במהירות את הנתונים הללו בעת הצורך. אבל בגלל האופן שבו FUSE מיושם, אנדרואיד מאחסנת את כמות המטמון הכפולה הדרושה.

כפי שמר קובלצ'יק מדגים, קובץ של 10MB צפוי להישמר במטמון כ-10 מגה-בייט בדיוק, אך במקום זאת לעלות לגודל המטמון בסביבות 20MBs. זה בעייתי במכשירים עם פחות זיכרון RAM, מכיוון שמאגרי ליבת לינוקס משתמשת במטמון עמודים כדי לאחסן נתונים ב זיכרון. מר קובלצ'יק בדק את בעיית השמירה הכפולה הזו באמצעות גישה זו:

  1. צור קובץ בגודל ידוע (לבדיקה, 10MBs)
  2. העתק אותו ל-/sdcard
  3. שחרר את מטמון העמוד
  4. צלם תמונת מצב של השימוש במטמון הדף
  5. קרא את קובץ הבדיקה
  6. צלם תמונה נוספת של השימוש במטמון הדף

מה שהוא גילה היה שלפני הבדיקה שלו, 241MBs היו בשימוש על ידי הליבה עבור מטמון דפים. ברגע שהוא קרא את קובץ הבדיקה שלו, הוא ציפה לראות 251MBs מנוצלים עבור מטמון הדפים. במקום זאת, הוא גילה שהגרעין הזה משתמש 263MBs עבור מטמון עמודים - בערך פי שניים מהצפוי. הסיבה שזה קורה היא בגלל שהנתונים מאוחסנים תחילה במטמון על ידי יישום המשתמש שהנפיק במקור את קריאת ה-I/O (FUSE), ושנית על ידי דמון ה-sdcard (EXT4 FS).

בעיה מס' 3 - יישום לא שלם של FAT32

ישנן עוד שתי בעיות הנובעות מהשימוש ב-FUSE המדמה FAT32 שפחות מוכרות בקהילת אנדרואיד.

הראשון כרוך חותמות זמן שגויות. אם אי פעם העברת קובץ (כגון תמונה) ושמת לב שחותמת הזמן שגויה, זה בגלל הטמעת FUSE של אנדרואיד. לנושא הזה יש היה קיים עבור שנים. ליתר דיוק, הנושא כרוך ב utime() קריאת מערכת המאפשרת לך לשנות את זמן הגישה והשינוי של קובץ. למרבה הצער, לקריאות שנעשות לדמון sdcard כמשתמש רגיל אין את ההרשאה המתאימה לביצוע קריאת מערכת זו. יש דרכים לעקיפת הבעיה, אבל הן מחייבות אותך יש גישה לשורש.

אם אי פעם העברת קובץ (כגון תמונה) ושמת לב שחותמת הזמן שגויה, זה בגלל הטמעת FUSE של אנדרואיד.

הבעיה הבאה נוגעת יותר לעסקים המשתמשים במשהו כמו א כרטיס smartSD. לפני FUSE, יצרני אפליקציות יכלו לפקח על דגל O_DIRECT על מנת לתקשר עם מיקרו-בקר מוטבע בכרטיס. עם FUSE, מפתחים יכולים לגשת רק לגרסת המטמון של קובץ, ואינם יכולים לראות פקודות כלשהן שנשלחות על ידי מיקרו-בקר. זה בעייתי עבור אפליקציות ארגוניות/ממשלתיות/בנקאות שמתקשרות עם כרטיסי microSD בעלי ערך מוסף.

השלכת FUSE עבור SDCardFS

כמה יצרני OEM זיהו את הבעיות הללו בשלב מוקדם, והחלו לחפש פתרון בתוך הליבה להחלפת FUSE. סמסונג, למשל, פיתחה SDCardFS אשר מבוסס על WrapFS. פתרון זה בתוך הליבה מחקה FAT32 בדיוק כמו FUSE עושה, אבל מוותר על תקורה I/O, מטמון כפול ובעיות אחרות שהזכרתי לעיל. (כן, הרשו לי לחזור על הנקודה הזו, הפתרון הזה שגוגל מיישמת כעת מבוסס על העבודה של סמסונג).

גוגל עצמן סוף סוף הכירו בחסרונות הקשורים ל-FUSE, וזו הסיבה שהם החלו להתקדם לעבר שכבת האמולציית FAT32 בתוך הליבה שפותחה על ידי סמסונג. החברה, כאמור ב מפתחי אנדרואיד מאחורי הקלעים podcast, עבדה על הפיכת SDCardFS לזמינה עבור כל המכשירים בגרסה הקרובה של הליבה. כרגע אתה יכול לראות את ההתקדמות שלהם עבודה ב-AOSP.

כ מפתח גוגל הסביר קודם לכן, האתגר הגדול ביותר ביישום פתרון בתוך הליבה הוא כיצד למפות את שם החבילה אליו מזהה אפליקציה הדרוש לחבילה כדי לגשת לנתונים שלה באחסון חיצוני מבלי להידרש לשום דבר הרשאות. אבל ההצהרה הזו נמסרה לפני שנה, והגענו לנקודה שבה הצוות מכנה SDCardFS "הדבר הגדול הבא" שלהם. הם כבר אישרו כי שגיאת חותמת זמן מפחידה תוקן, הודות להתרחקות מ-FUSE, כך שנוכל לצפות לראות את כל השינויים שנוצרו עם נטישת FUSE.

תפיסות שגויות של בדיקת עובדות

אם הגעתם עד לכאן לתוך המאמר, כל הכבוד על כך שהתעדכנתם עד כה! רציתי להבהיר כמה שאלות שהיו לי בעצמי כשכתבתי את המאמר הזה:

  • ל-SDCardFS יש שום קשר לכרטיסי SD בפועל. זה פשוט נקרא כך מכיוון שהוא מטפל בגישה ל-I/O עבור /sdcard. וכזכור, /sdcard הוא תווית מיושנת המתייחסת לאחסון "חיצוני" של המכשיר שלך (שם אפליקציות מאחסנות את המדיה שלהן).
  • SDCardFS הוא לא מערכת קבצים מסורתית כמו FAT32, EXT4 או F2FS. זוהי מערכת קבצי עטיפה הניתנת לערום המעבירה פקודות למערכות הקבצים הנמוכות יותר, המדמות (במקרה זה, זה יהיה FAT32 ב-/sdcard).
  • שום דבר לא ישתנה ביחס ל-MTP. תמשיך להשתמש ב-MTP כדי להעביר קבצים אל/ממחשבך (עד שגוגל תסתפק בפרוטוקול טוב יותר). אבל לפחות שגיאת חותמת הזמן תתוקן!
  • כפי שצוין קודם לכן, כאשר גוגל מתייחסת ל"אחסון חיצוני" הם מדברים על (לכל העניין ו למטרות) מחיצת FAT32 וירטואלית פנימית /sdcard או שהם מדברים על microSD אמיתי, פיזי ונשלף כַּרְטִיס. הטרמינולוגיה מבלבלת, אבל זה מה שמדהים אותנו.

סיכום

על ידי התרחקות מ-FUSE והטמעת שכבת אמולציית FAT32 בתוך הליבה (SDCardFS), גוגל תצמצם תקורה משמעותית של קלט/פלט, ביטול זיכרון מטמון כפול ופתרון כמה בעיות לא ברורות הקשורות לאמולציה של FUSE של FAT32.

מכיוון שהשינויים הללו יבוצעו בקרנל, הם יכולים להתגלגל ללא גרסה חדשה גדולה של אנדרואיד לצדה. חלק מהמשתמשים מצפים לראות את השינויים האלה מיושמים רשמית באנדרואיד 8, אבל זה אפשרי לכל OTA עתידי במכשיר Pixel כדי להביא את גרסת ליבת לינוקס 4.1 שגוגל עבדה בה עַל.

עבור חלקכם, SDCardFS אינו מושג חדש. למעשה, מכשירי סמסונג משתמשים בו כבר שנים (בכל זאת הם אלו שפיתחו אותו). מאז שהוצג SDCardFS ב-AOSP בשנה שעברה, כמה מפתחי ROM וקרנל מותאמים אישית בחרו ליישם אותו בעבודה שלהם. CyanogenMOD שקל בשלב מסוים ליישם אותו, אך החזיר אותו לאחור כאשר משתמשים נתקלו בבעיות בתמונות שלהם. אבל אני מקווה שגוגל תוביל את השלטון בפרויקט הזה, משתמשי אנדרואיד בכל המכשירים העתידיים יכולים לנצל את השיפורים שהוצגו עם נטישת FUSE.