Eintauchen in SDCardFS: Wie der FUSE-Ersatz von Google den I/O-Overhead reduziert

Xda AndroidOct 29, 2023

Eine ausführliche Untersuchung von SDCardFS, Googles Ersatz für FUSE, und wie seine Implementierung den I/O-Overhead reduzieren wird.

Vor einigen Monaten fügte Google etwas hinzu mit dem Namen „SDCardFS” zu den offiziellen AOSP-Zweigen für den Linux-Kernel. Zu diesem Zeitpunkt wurde der Umzug nur von bemerkt einige Kernel-Entwickler, blieb aber ansonsten unter dem Radar der meisten Benutzer. Kein Wunder, wenn man bedenkt, dass die meisten Benutzer, mich eingeschlossen, nicht wirklich wissen, was unter der Haube des Android-Betriebssystems und seines Kernels vor sich geht.

Allerdings ist die neueste Folge der Android-Entwickler Backstage Podcast erneuerte das Interesse an diesem Thema. Der von Chet Haase (einem leitenden Softwareentwickler bei Google) moderierte Podcast untersuchte aktuelle und bevorstehende Änderungen am Kernel. In der Show war ein Linux-Kernel-Entwickler, der im Android-Team arbeitete – Rom Lemarchand. Das Duo diskutierte hauptsächlich darüber, welche Änderungen vorgenommen wurden, um A/B-Updates zu ermöglichen, aber in den letzten fünf Minuten der Folge sprach Herr Lemarchand über „das nächste große Ding“, an dem sein Team arbeitete –

SDCardFS.

Ich muss zugeben, dass ich nach dem Anhören dieses Podcasts von der Existenz von SDCardFS erfahren habe. Natürlich war ich nicht der Einzige, der sich für dieses Thema interessierte aktueller Reddit-Thread hat gezeigt. Ich war jedoch mit der grundlegenden Erklärung, die im Podcast angeboten wurde, nicht zufrieden und bemühte mich, einige davon auszuräumen Da Fehlinformationen verbreitet werden, habe ich selbst recherchiert und mit einigen Experten gesprochen, die über einschlägige Kenntnisse verfügen Gegenstand.

Vielen Dank an den Softwareentwickler Michal Kowalczyk, der sein Wissen in diesen Artikel eingebracht und sich die Zeit genommen hat, meine Fragen zu beantworten.

„Extern“ ist wirklich intern

Es muss gleich zu Beginn einige Missverständnisse geben, die wir aufklären müssen – sonst wird der Rest des Artikels sehr verwirrend. Es ist hilfreich, die Geschichte von SD-Karten und Android-Telefonen zu besprechen.

In den frühen Tagen der Android-Telefone war fast jedes Gerät darauf angewiesen, seine microSD-Karten zur Speicherung zu verwenden. Dies lag daran, dass die damaligen Telefone nur über winzige interne Speicherkapazitäten verfügten. Allerdings bieten SD-Karten, die zum Speichern von Anwendungen verwendet werden, oft kein herausragendes Benutzererlebnis, zumindest im Vergleich zur Geschwindigkeit, mit der der interne Flash-Speicher Daten lesen/schreiben kann. Daher wurde die zunehmende Verwendung von SD-Karten zur externen Datenspeicherung für Google zu einem Problem für die Benutzererfahrung.

Aufgrund der frühen Verbreitung von SD-Karten als externe Speichergeräte basierten die Speicherbenennungskonventionen von Android auf der Tatsache, dass jedes Gerät über einen tatsächlichen, physischen microSD-Kartensteckplatz verfügte. Aber selbst auf Geräten, die keinen SD-Kartensteckplatz hatten, wurde die Bezeichnung /sdcard immer noch verwendet, um auf den eigentlichen internen Speicherchip hinzuweisen. Noch verwirrender ist die Tatsache, dass Geräte, die sowohl eine physische SD-Karte als auch einen Speicherchip mit hoher Kapazität zur Speicherung verwenden, ihre Partitionen häufig nach der SD-Karte benennen. Bei diesen Geräten würde sich beispielsweise der Einhängepunkt /sdcard auf den tatsächlichen internen Speicherchip beziehen, während sich etwas wie /storage/sdcard1 auf die physische externe Karte beziehen würde.

Obwohl die microSD-Karte praktisch als externer Speicher angesehen wird, führte die Namenskonvention dazu, dass „SDCard“ lange über die tatsächliche Verwendung einer physischen Karte hinaus bestehen blieb. Diese Verwechslung mit dem Speicher bereitete Anwendungsentwicklern auch einige Kopfschmerzen, da Anwendungsdaten und ihre Medien zwischen den beiden Partitionen getrennt waren.

Der geringe Speicherplatz früher interner Speicherchips führte dazu, dass Benutzer frustriert feststellen mussten, dass sie keine Anwendungen mehr installieren konnten (weil die /data-Partition voll war). In der Zwischenzeit wurden die microSD-Karten mit größerer Kapazität nur für die Speicherung von Medien (z. B. Fotos, Musik und Filme) verwendet. Benutzer, die damals in unseren Foren surften, erinnern sich vielleicht an diese Namen: Link2SD und Apps2SD. Hierbei handelte es sich um (Root-)Lösungen, die es Benutzern ermöglichten, ihre Anwendungen und deren Daten vollständig auf der physischen SD-Karte zu installieren. Aber das waren alles andere als perfekte Lösungen, also musste Google eingreifen.

Bekanntlich hat Google schon sehr früh den Stecker für SD-Karten gezogen. Das Nexus One bleibt das einzige Nexus-Gerät mit einem microSD-Kartensteckplatz (und das wird auch für immer so bleiben, da die Marke Nexus praktisch tot ist). Beim Nexus S gab es nur noch eine einheitliche Partition zum Speichern aller Anwendungsdaten und Medien – die /data-Partition. Was einst als Mount-Punkt /sdcard bekannt war, bezog sich jetzt einfach auf ein virtuelles Dateisystem (implementiert unter SICHERUNG Protokoll wie unten beschrieben) in der Datenpartition - /data/media/0.

Um die Kompatibilität aufrechtzuerhalten und Verwirrung zu vermeiden, nutzte Google weiterhin diese jetzt virtuelle „SD-Karten“-Partition zum Speichern von Medien. Aber da sich diese virtuelle „SD-Karten“-Partition nun tatsächlich in /data befand, würde alles, was darin gespeichert ist, auf den Speicherplatz des internen Speicherchips angerechnet. Daher lag es an den OEMs, zu überlegen, wie viel Platz sie Anwendungen (/data) im Vergleich zu Medien (/data/media) zuweisen sollten.

Zwei sehr unterschiedliche „SD-Karten“

Google hoffte, dass die Hersteller ihrem Beispiel folgen und SD-Karten abschaffen würden. Glücklicherweise konnten Telefonhersteller diese Komponenten im Laufe der Zeit mit höheren Kapazitäten beschaffen und gleichzeitig kostengünstig bleiben, so dass der Bedarf an SD-Karten immer geringer wurde. Die Namenskonventionen wurden jedoch beibehalten, um den Anpassungsaufwand für Entwickler und OEMs zu verringern. Wenn wir derzeit von „externem Speicher“ sprechen, beziehen wir uns auf eines von zwei Dingen: die tatsächliche entfernbare microSD-Karte oder die virtuelle „SDCard“-Partition in /data/media. Letzteres davon ist praktisch gesehen ist eigentlich interner Speicher, aber die Namenskonvention von Google unterscheidet sie dadurch, dass diese Daten für den Benutzer zugänglich sind (z. B. wenn er an den Computer angeschlossen ist).

Wenn wir derzeit von „externem Speicher“ sprechen, beziehen wir uns auf eines von zwei Dingen: die tatsächliche entfernbare microSD-Karte oder die virtuelle „SDCard“-Partition in /data/media.

Die Geschichte der virtuellen Dateisysteme von Android

Da „sdcard“ nun als virtuelles Dateisystem behandelt wird, bedeutet dies, dass es als jedes von Google gewünschte Dateisystem formatiert werden kann. Beginnend mit dem Nexus S und Android 2.3 hat sich Google dafür entschieden, „sdcard“ als VFAT (virtuelles FAT) zu formatieren. Dieser Schritt war damals sinnvoll, da durch die Installation von VFAT fast jeder Computer auf die auf Ihrem Telefon gespeicherten Daten zugreifen konnte. Allerdings gab es bei dieser ersten Implementierung zwei große Probleme.

Die erste betrifft in erster Linie den Endbenutzer (Sie). Um Ihr Gerät an Ihren Computer anzuschließen, verwenden Sie den USB-Massenspeichermodus zur Datenübertragung. Allerdings musste das Android-Gerät die virtuelle Partition aushängen, bevor der Computer auf die Daten zugreifen konnte. Wenn ein Benutzer sein Gerät verwenden wollte, während es angeschlossen war, wurden viele Dinge als nicht verfügbar angezeigt.

Der Einführung des Media Transfer Protocol (MTP) hat dieses erste Problem gelöst. Wenn es angeschlossen ist, erkennt Ihr Computer Ihr Gerät als „Medienspeichergerät“. Es fordert eine Liste von Dateien von Ihrem Telefon an und MTP gibt eine Liste von Dateien zurück, die der Computer vom Gerät herunterladen kann. Wenn das Löschen einer Datei angefordert wird, sendet MTP einen Befehl zum Entfernen der angeforderten Datei aus dem Speicher. Im Gegensatz zum USB-Massenspeichermodus, bei dem die „SD-Karte“ tatsächlich gemountet wird, ermöglicht MTP dem Benutzer, sein Gerät weiterhin zu verwenden, während es angeschlossen ist. Darüber hinaus spielt das auf dem Android-Telefon vorhandene Dateisystem keine Rolle mehr, damit der Computer die Dateien auf dem Gerät erkennt.

Zweitens gab es die Tatsache, dass VFAT nicht die Art von robuster Berechtigungsverwaltung bereitstellte, die Google benötigte. Anfangs betrachteten viele Anwendungsentwickler die „SD-Karte“ als Ablageplatz für die Daten ihrer Anwendungen, ohne einheitliche Vorstellung davon, wo sie ihre Dateien speichern sollten. Viele Anwendungen würden einfach einen Ordner mit ihrem App-Namen erstellen und ihre Dateien dort speichern.

Fast jede Anwendung da draußen erforderte das WRITE_EXTERNAL_STORAGE Erlaubnis, ihre Anwendungsdateien auf den externen Speicher zu schreiben. Besorgniserregender war jedoch die Tatsache, dass fast jede Anwendung auch das erforderte READ_EXTERNAL_STORAGE Erlaubnis - nur um ihre eigenen Datendateien zu lesen! Dies bedeutete, dass Anwendungen problemlos auf Daten zugreifen konnten, die irgendwo im externen Speicher gespeichert waren. und eine solche Erlaubnis wurde oft vom Benutzer erteilt, da sie für viele Apps erforderlich war Funktion.

Google sah dies eindeutig als problematisch an. Die gesamte Idee hinter der Berechtigungsverwaltung besteht darin, zu trennen, auf welche Apps Zugriff haben kann und auf welche nicht. Wenn nahezu jeder App Lesezugriff auf potenziell sensible Benutzerdaten gewährt wird, ist die Berechtigung bedeutungslos. Daher entschied Google, dass sie einen neuen Ansatz brauchten. Hier kommt FUSE ins Spiel.

Dateisystem im Userspace (FUSE)

Ab Android 4.4 hat Google beschlossen, die virtuelle „SD-Karten“-Partition nicht mehr als VFAT bereitzustellen. Stattdessen begann Google, FUSE zu verwenden, um FAT32 auf der virtuellen Partition „SD-Karte“ zu emulieren. Mit dem Aufruf des SD-Kartenprogramms FUSE zum Emulieren von Verzeichnisberechtigungen im FAT-on-SD-Card-Stil, könnten Anwendungen damit beginnen, auf die im externen Speicher gespeicherten Daten zuzugreifen ohne dass dafür irgendwelche Berechtigungen erforderlich sind. Tatsächlich war READ_EXTERNAL_STORAGE ab API Level 19 nicht mehr erforderlich, um auf gefundene Dateien zuzugreifen auf externem Speicher – vorausgesetzt, dass der vom FUSE-Daemon erstellte Datenordner mit dem Paketnamen der App übereinstimmt. FUSE würde damit umgehen Zusammenfassen des Eigentümers, der Gruppe und der Modi von Dateien im externen Speicher wenn eine Anwendung installiert ist.

FUSE unterscheidet sich von In-Kernel-Modulen dadurch, dass es nichtprivilegierten Benutzern das Schreiben virtueller Dateisysteme ermöglicht. Der Grund, warum Google FUSE implementiert hat, ist ziemlich einfach: Es hat getan, was sie wollten und bereits getan hat gut verstanden und dokumentiert in der Welt von Linux. Um a zu zitieren Google-Entwickler zu diesem Thema:

„Da FUSE eine schöne stabile API ist, ist beim Wechsel zwischen Kernel-Versionen im Wesentlichen kein Wartungsaufwand erforderlich. Wenn wir zu einer In-Kernel-Lösung migrieren würden, würden wir uns für die Wartung einer Reihe von Patches für jede stabile Kernel-Version anmelden.“ -Jeff Sharkey, Software Engineer bei Google

Es wurde jedoch immer deutlicher, dass der Overhead von FUSE unter anderem zu Leistungseinbußen führte. Der Entwickler, mit dem ich diesbezüglich gesprochen habe, Michal Kowalczyk, habe einen hervorragenden Blogbeitrag verfasst vor über einem Jahr, in dem die aktuellen Probleme mit FUSE detailliert beschrieben wurden. Weitere technische Details können in seinem Blog nachgelesen werden, aber ich werde seine Ergebnisse (mit seiner Erlaubnis) eher in Laiensprache beschreiben.

Das Problem mit FUSE

In Android verwendet der Userspace-Daemon „sdcard“ FUSE, um /dev/fuse beim Booten im emulierten externen Speicherverzeichnis bereitzustellen. Danach fragt der SD-Karten-Daemon das FUSE-Gerät nach ausstehenden Nachrichten vom Kernel ab. Wenn Sie sich den Podcast angehört haben, haben Sie vielleicht gehört, dass Herr Lemarchand sich auf die Einführung von Overhead durch FUSE bei I/O-Vorgängen bezieht – hier ist im Wesentlichen, was passiert.

In der realen Welt wirkt sich dieser Leistungseinbruch aus beliebig Datei auf externem Speicher gespeichert.

Problem Nr. 1 – E/A-Overhead

Nehmen wir an, wir erstellen eine einfache Textdatei namens „test.txt“ und speichern sie in /sdcard/test.txt (was z. B Ich möchte Sie daran erinnern, dass es sich tatsächlich um /data/media/0/test.txt handelt, vorausgesetzt, der aktuelle Benutzer ist der Hauptbenutzer Gerät). Wenn wir diese Datei lesen wollten (Befehl cat), würden wir erwarten, dass das System drei Befehle ausgibt: Öffnen, Lesen und dann Schließen. In der Tat, wie Herr Kowalczyk anhand von demonstriert strace, das passiert:

Da sich die Datei jedoch auf dem externen Speicher befindet, der vom SD-Karten-Daemon verwaltet wird, müssen viele zusätzliche Vorgänge ausgeführt werden. Laut Herrn Kowalczyk sind hierfür im Wesentlichen 8 zusätzliche Schritte erforderlich jeder dieser 3 einzelnen Befehle:

  1. Die Userspace-Anwendung gibt einen Systemaufruf aus, der vom FUSE-Treiber im Kernel verarbeitet wird (wir sehen es in der ersten Strace-Ausgabe).
  2. Der FUSE-Treiber im Kernel benachrichtigt den Userspace-Daemon (SD-Karte) über neue Anforderungen
  3. Der Userspace-Daemon liest /dev/fuse
  4. Der Userspace-Daemon analysiert den Befehl und erkennt den Dateivorgang (z. B. offen)
  5. Der Userspace-Daemon gibt einen Systemaufruf an das eigentliche Dateisystem (EXT4) aus.
  6. Der Kernel verwaltet den physischen Datenzugriff und sendet Daten zurück an den Benutzerbereich
  7. Userspace ändert (oder auch nicht) Daten und leitet sie über /dev/fuse erneut an den Kernel weiter
  8. Der Kernel schließt den ursprünglichen Systemaufruf ab und verschiebt Daten in die eigentliche Userspace-Anwendung (in unserem Beispiel cat).

Das scheint so eine Menge von Overhead nur auf einen einzigen auszuführenden E/A-Befehl. Und du hättest recht. Um dies zu demonstrieren, versuchte Herr Kowalczyk zwei verschiedene E/A-Tests: Bei einem wurde eine große Datei kopiert, bei dem anderen wurden viele kleine Dateien kopiert. Er verglich die Geschwindigkeit von FUSE (auf der als FAT32 gemounteten virtuellen Partition) bei der Verarbeitung dieser Vorgänge mit der Kernel (auf der als EXT4 formatierten Datenpartition) und er stellte fest, dass FUSE tatsächlich einen erheblichen Beitrag leistete Overhead.

Im ersten Test kopierte er unter beiden Testbedingungen eine 725 MB große Datei. Er stellte fest, dass die FUSE-Implementierung große Dateien übertrug 17 % langsamer.

Im zweiten Test kopierte er 10.000 Dateien – jede davon 5 KB groß. In diesem Szenario war die FUSE-Implementierung beendet 40 Sekunden langsamer um grundsätzlich Daten im Wert von 50 MB zu kopieren.

In der realen Welt wirkt sich dieser Leistungseinbruch aus beliebig Datei auf externem Speicher gespeichert. Dies bedeutet, dass Apps wie Karten große Dateien auf der SD-Karte speichern, Musik-Apps, die Unmengen an Musikdateien speichern, Kamera-Apps und Fotos usw. Alle ausgeführten E/A-Vorgänge, die den externen Speicher betreffen, werden durch den Overhead von FUSE beeinflusst. Aber der I/O-Overhead ist nicht das einzige Problem bei FUSE.

Problem Nr. 2 – Doppeltes Caching

Das Zwischenspeichern von Daten ist wichtig für die Verbesserung der Datenzugriffsleistung. Durch die Speicherung wichtiger Daten im Speicher ist der Linux-Kernel in der Lage, diese Daten bei Bedarf schnell abzurufen. Aufgrund der Art und Weise, wie FUSE implementiert ist, speichert Android jedoch die doppelte Menge an Cache, die benötigt wird.

Wie Herr Kowalczyk demonstriert, wird erwartet, dass eine 10-MB-Datei genau 10 MB im Cache gespeichert wird, aber stattdessen die Cache-Größe erreicht um etwa 20 MB. Dies ist auf Geräten mit weniger RAM problematisch, da die Linux-Kernelspeicher den Seitencache zum Speichern von Daten verwenden Erinnerung. Herr Kowalczyk hat dieses Doppel-Caching-Problem mit folgendem Ansatz getestet:

  1. Erstellen Sie eine Datei mit bekannter Größe (zum Testen 10 MB).
  2. Kopieren Sie es nach /sdcard
  3. Löschen Sie den Seitencache
  4. Machen Sie einen Schnappschuss der Seiten-Cache-Nutzung
  5. Lesen Sie die Testdatei
  6. Machen Sie einen weiteren Schnappschuss der Seiten-Cache-Nutzung

Er stellte fest, dass vor seinem Test 241 MB vom Kernel für den Seitencache verwendet wurden. Nachdem er seine Testdatei gelesen hatte, ging er davon aus, dass 251 MB für den Seitencache verwendet werden würden. Stattdessen stellte er fest, dass dieser Kernel verwendet wurde 263 MB für Seitencache - ungefähr doppelt so viel wie erwartet. Der Grund dafür ist, dass die Daten zunächst von der Benutzeranwendung zwischengespeichert werden, die ursprünglich den E/A-Aufruf ausgegeben hat (FUSE), und zweitens vom SD-Karten-Daemon (EXT4 FS).

Problem Nr. 3 – Unvollständige Implementierung von FAT32

Es gibt zwei weitere Probleme, die sich aus der Verwendung von FUSE zur Emulation von FAT32 ergeben und in der Android-Community weniger bekannt sind.

Das erste betrifft Falsche Zeitstempel. Wenn Sie jemals eine Datei (z. B. ein Foto) übertragen haben und festgestellt haben, dass der Zeitstempel falsch ist, liegt das an der FUSE-Implementierung von Android. Dieses Problem hat existierte für Jahre. Genauer gesagt geht es um das Problem utime() Systemaufruf, mit dem Sie die Zugriffs- und Änderungszeit einer Datei ändern können. Leider verfügen Aufrufe an den SDCard-Daemon als Standardbenutzer nicht über die entsprechende Berechtigung, diesen Systemaufruf auszuführen. Hierfür gibt es Problemumgehungen, die jedoch von Ihnen verlangt werden Root-Zugriff haben.

Wenn Sie jemals eine Datei (z. B. ein Foto) übertragen haben und festgestellt haben, dass der Zeitstempel falsch ist, liegt das an der FUSE-Implementierung von Android.

Das nächste Problem betrifft eher Unternehmen, die so etwas wie a verwenden smartSD-Karte. Vor FUSE konnten App-Hersteller dies überwachen O_DIRECT-Flag um mit einem eingebetteten Mikrocontroller in der Karte zu kommunizieren. Mit FUSE können Entwickler nur auf die zwischengespeicherte Version einer Datei zugreifen und keine von einem Mikrocontroller gesendeten Befehle sehen. Dies ist problematisch für einige Unternehmens-/Behörden-/Banking-Apps, die mit Mehrwert-microSD-Karten kommunizieren.

Dumping von FUSE für SDCardFS

Einige OEMs erkannten diese Probleme schon früh und suchten nach einer Kernel-Lösung als Ersatz für FUSE. Samsung hat zum Beispiel entwickelt SDCardFS welches auf WrapFS basiert. Diese In-Kernel-Lösung emuliert FAT32 genau wie FUSE, verzichtet jedoch auf den I/O-Overhead, das doppelte Caching und andere oben erwähnte Probleme. (Ja, lassen Sie mich diesen Punkt wiederholen, Diese Lösung, die Google jetzt implementiert, basiert auf der Arbeit von Samsung).

Google selbst hat endlich die mit FUSE verbundenen Nachteile erkannt und hat daher damit begonnen, auf die von Samsung entwickelte In-Kernel-FAT32-Emulationsschicht umzusteigen. Das Unternehmen, wie in der erwähnt Android-Entwickler Backstage Podcast, hat daran gearbeitet, SDCardFS in einer kommenden Version des Kernels für alle Geräte verfügbar zu machen. Sie können derzeit den Fortschritt ihrer sehen Arbeit in AOSP.

Als ein Der Google-Entwickler hat es zuvor erklärtDie größte Herausforderung bei der Implementierung einer In-Kernel-Lösung besteht darin, wie der Paketname zugeordnet werden kann Anwendungs-ID, die erforderlich ist, damit ein Paket auf seine eigenen Daten im externen Speicher zugreifen kann, ohne dass eine solche erforderlich ist Berechtigungen. Aber diese Aussage wurde vor einem Jahr gemacht und wir sind an dem Punkt angelangt, an dem das Team SDCardFS als ihr „nächstes großes Ding“ bezeichnet. Sie haben bereits bestätigt, dass die gefürchteter Zeitstempelfehler wurde dank der Abkehr von FUSE behoben. Wir können uns also auf alle Änderungen freuen, die mit der Aufgabe von FUSE einhergehen.

Missverständnisse bei der Faktenprüfung

Wenn Sie bis hierhin mit dem Artikel gekommen sind, dann ein großes Lob dafür, dass Sie bisher mit allem Schritt gehalten haben! Ich wollte einige Fragen klären, die ich selbst hatte, als ich diesen Artikel schrieb:

  • SDCardFS hat nichts mit echten SD-Karten zu tun. Es wird nur so benannt, weil es den E/A-Zugriff für /sdcard verwaltet. Und wie Sie sich vielleicht erinnern, ist /sdcard eine veraltete Bezeichnung, die sich auf den „externen“ Speicher Ihres Geräts bezieht (wo Apps ihre Medien speichern).
  • SDCardFS ist kein traditionelles Dateisystem wie FAT32, EXT4 oder F2FS. Es handelt sich um ein stapelbares Wrapper-Dateisystem, das Befehle an die unteren, emulierten Dateisysteme weiterleitet (in diesem Fall wäre es FAT32 auf der /sdcard).
  • Bezüglich MTP wird sich nichts ändern. Sie werden weiterhin MTP verwenden, um Dateien von/zu Ihrem Computer zu übertragen (bis Google sich für ein besseres Protokoll entscheidet). Aber zumindest wird der Zeitstempelfehler behoben!
  • Wie bereits erwähnt, spricht Google, wenn es von „externem Speicher“ spricht, entweder (im Grunde genommen) und Zwecke) interne /sdcard virtuelle FAT32-Partition ODER es handelt sich um eine tatsächliche, physische, entfernbare microSD Karte. Die Terminologie ist verwirrend, aber es ist das, was uns beeindruckt.

Abschluss

Durch die Abkehr von FUSE und die Implementierung einer FAT32-Emulationsschicht im Kernel (SDCardFS) wird Google die Kosten reduzieren Erheblicher I/O-Overhead, Eliminierung von doppeltem Caching und Lösung einiger unklarer Probleme im Zusammenhang mit der FUSE-Emulation von FAT32.

Da diese Änderungen an einem Kernel vorgenommen werden, können sie ohne eine größere neue Android-Version eingeführt werden. Einige Benutzer erwarten, dass diese Änderungen offiziell in Android 8 implementiert werden, aber es ist möglich Für jeden zukünftigen OTA auf einem Pixel-Gerät soll die Linux-Kernel-Version 4.1 bereitgestellt werden, an der Google gearbeitet hat An.

Für einige von Ihnen ist SDCardFS kein neues Konzept. Tatsächlich nutzen Samsung-Geräte es schon seit Jahren (sie waren schließlich diejenigen, die es entwickelt haben). Seitdem SDCardFS letztes Jahr in AOSP eingeführt wurde, haben sich einige benutzerdefinierte ROM- und Kernel-Entwickler dafür entschieden, es in ihre Arbeit zu implementieren. CyanogenMOD hatte einmal darüber nachgedacht, es zu implementieren, hat es jedoch zurückgenommen, als Benutzer Probleme mit ihren Fotos hatten. Da Google bei diesem Projekt jedoch die Führung übernimmt, können Android-Nutzer hoffentlich auf allen künftigen Geräten von den Verbesserungen profitieren, die durch den Verzicht auf FUSE eingeführt wurden.