Padziļināta izpēte par SDCardFS, Google FUSE aizstājēju, un to, kā tā ieviešana samazinās I/O pieskaitāmās izmaksas.
Pirms vairākiem mēnešiem Google pievienoja kaut ko ar nosaukumu "SDCardFS” uz oficiālajām AOSP filiālēm Linux kodolam. Toreiz kustību pamanīja tikai daži kodola izstrādātāji, bet citādi lidoja zem lielākās daļas lietotāju radara. Nav pārsteigums, ņemot vērā faktu, ka lielākā daļa lietotāju, tostarp es, īsti nezina, kas notiek zem Android OS un tās kodola pārsega.
Tomēr jaunākā sērija Android izstrādātāju aizkulisēs aplāde atjaunoja interesi par šo tēmu. Podcast aplāde, kuru vadīja Čets Hāss (Google vecākais programmatūras inženieris), izpētīja nesen veiktās un gaidāmās kodolā veiktās izmaiņas. Šovā piedalījās Linux kodola izstrādātājs, kurš strādāja Android komandā Rom Lemarchand. Duets galvenokārt apsprieda, kādas izmaiņas tika veiktas, lai pielāgotos A/B atjauninājumiem, bet epizodes pēdējās 5 minūtēs Lemarčenda kungs runāja par "nākamo lielo lietu", pie kuras viņa komanda strādāja. SDCardFS.
Jāatzīst, ka par SDCardFS esamību uzzināju pēc šī podkāsta noklausīšanās. Protams, es nebiju vienīgais, kurš interesējās par šo tēmu, jo a nesenais Reddit pavediens ir parādījis. Tomēr es nebiju apmierināts ar pamata skaidrojumu, kas tika piedāvāts podkāstā, un cenšoties kliedēt dažus tiek izplatīta dezinformācija, es pats veicu dažus pētījumus un runāju ar dažiem ekspertiem, kuriem ir attiecīgās zināšanas jautājums.
Liels paldies programmatūras izstrādātājam Mihalam Kovaļčikam par savu zināšanu ieguldījumu šī raksta tapšanā un par to, ka veltījāt laiku, lai atbildētu uz maniem jautājumiem.
"Ārējais" patiešām ir iekšējs
Uzreiz noteikti ir daži maldīgi priekšstati, kas mums ir jānoskaidro — pretējā gadījumā pārējā raksta daļa būs ļoti mulsinoša. Ir noderīgi apspriest SD karšu un Android tālruņu vēsturi.
Android tālruņu sākumposmā gandrīz katra ierīce glabāšanai izmantoja savas microSD kartes. Tas bija saistīts ar faktu, ka tālruņi tajā laikā tika piegādāti ar nelielu iekšējās atmiņas ietilpību. Tomēr SD kartes, ko izmanto lietojumprogrammu glabāšanai, bieži vien nenodrošina izcilu lietotāja pieredzi, vismaz salīdzinājumā ar ātrumu, ar kādu iekšējā zibatmiņa var lasīt/rakstīt datus. Tāpēc arvien pieaugošā SD karšu izmantošana ārējai datu glabāšanai kļuva par Google lietotāju pieredzi.
Sakarā ar SD karšu kā ārēju atmiņas ierīču agrīnu izplatību, Android krātuves nosaukumu piešķiršanas konvencijas tika balstītas uz faktu, ka katrai ierīcei bija faktisks, fizisks microSD kartes slots. Bet pat ierīcēs, kurās nebija SD kartes slota, /sdcard etiķete joprojām tika izmantota, lai norādītu uz faktisko iekšējās atmiņas mikroshēmu. Mulsinošāku rada fakts, ka ierīces, kurās glabāšanai izmantoja gan fizisko SD karti, gan lielas ietilpības atmiņas mikroshēmu, bieži vien nosaukuši nodalījumus, pamatojoties uz SD karti. Piemēram, šajās ierīcēs /sdcard pievienošanas punkts attiektos uz faktisko iekšējās atmiņas mikroshēmu, savukārt kaut kas līdzīgs /storage/sdcard1 attiektos uz fizisko ārējo karti.
Tādējādi, lai gan microSD karte praktiski tiek uzskatīta par ārēju krātuvi, nosaukšanas vienošanās rezultātā “SDCard” palika līdzi jau ilgu laiku pēc faktiskās fiziskās kartes izmantošanas. Šī neskaidrība ar krātuvi arī radīja zināmas galvassāpes lietojumprogrammu izstrādātājiem, jo lietojumprogrammu dati un to datu nesēji tika nodalīti starp diviem nodalījumiem.
Agrīnās iekšējās krātuves mikroshēmu mazās krātuves vietas dēļ lietotāji neapmierināti atklāja, ka vairs nevar instalēt lietojumprogrammas (tā kā /data nodalījums ir pilns). Tikmēr to lielākās ietilpības microSD kartes tika novirzītas tikai uz multivides (piemēram, fotoattēlu, mūzikas un filmu) glabāšanu. Lietotāji, kuri savulaik pārlūkoja mūsu forumus, varētu atcerēties šos nosaukumus: Link2SD un Apps2SD. Tie bija (saknes) risinājumi, kas ļāva lietotājiem instalēt savas lietojumprogrammas un to datus fiziskajā SD kartē. Taču tie bija tālu no ideāliem risinājumiem, tāpēc Google bija jāiejaucas.
Ir zināms, ka Google jau ļoti agri izvilka SD kartes. Nexus One joprojām ir vienīgā Nexus ierīce ar microSD kartes slotu (un tā būs mūžīgi, jo Nexus zīmols faktiski ir miris). Ar Nexus S tagad bija tikai viens, vienots nodalījums visu lietojumprogrammu datu un datu nesēju glabāšanai — /data nodalījums. Tas, kas kādreiz bija pazīstams kā /sdcard pievienošanas punkts, tagad vienkārši atsaucās uz virtuālo failu sistēmu (ieviesta saskaņā ar DROŠINĀTĀJS protokols, kā aprakstīts tālāk), kas atrodas datu nodalījumā - /data/media/0.
Lai saglabātu savietojamību un mazinātu neskaidrības, Google joprojām izmantoja šo tagad virtuālo “sdcard” nodalījumu multivides glabāšanai. Bet tagad, kad šis “SDcard” virtuālais nodalījums faktiski atradās /data, viss tajā saglabātais tiks ieskaitīts iekšējās atmiņas mikroshēmas krātuves vietā. Tādējādi OEM bija jāizvērtē, cik daudz vietas atvēlēt lietojumprogrammām (/data) salīdzinājumā ar datu nesēju (/data/media).
Google cerēja, ka ražotāji sekos viņu piemēram un atbrīvosies no SD kartēm. Par laimi, laika gaitā tālruņu ražotāji varēja iegādāties šos komponentus ar lielāku jaudu, vienlaikus saglabājot rentabilitāti, tāpēc nepieciešamība pēc SD kartēm sāka izsīkt. Taču nosaukumu piešķiršanas noteikumi joprojām ir samazinājuši pūles, kas izstrādātājiem un oriģinālo iekārtu ražotājiem būtu jāpielāgojas. Pašlaik, runājot par “ārējo krātuvi”, mēs runājam par to viena no divām lietām: faktiskā noņemamā microSD karte vai virtuālais “SDCard” nodalījums, kas atrodas mapē /data/media. Pēdējais no tiem, praktiski runājot, faktiski ir iekšējā atmiņa, taču Google nosaukšanas noteikumi to atšķir tāpēc, ka šie dati ir pieejami lietotājam (piemēram, kad tie ir pievienoti datoram).
Pašlaik, runājot par “ārējo krātuvi”, mēs runājam par to viena no divām lietām: faktiskā noņemamā microSD karte vai virtuālais “SDCard” nodalījums, kas atrodas mapē /data/media.
Android virtuālo failu sistēmu vēsture
Tagad, kad “sdcard” tiek uzskatīta par virtuālu failu sistēmu, tas nozīmēja, ka to var formatēt kā jebkuru failu sistēmu, ko vēlas Google. Sākot ar Nexus S un Android 2.3, Google izvēlējās formatēt “sdcard” kā VFAT (virtuālo FAT). Šī kustība tajā laikā bija saprātīga, jo VFAT uzstādīšana ļautu gandrīz jebkuram datoram piekļūt jūsu tālrunī saglabātajiem datiem. Tomēr ar šo sākotnējo ieviešanu bija divas lielas problēmas.
Pirmais galvenokārt attiecas uz gala lietotāju (jūs). Lai savienotu ierīci ar datoru, datu pārsūtīšanai jāizmanto USB lielapjoma atmiņas režīms. Tomēr Android ierīcei bija jāatvieno virtuālais nodalījums, pirms dators varēja piekļūt datiem. Ja lietotājs vēlas izmantot ierīci, kamēr tā ir pievienota, daudzas lietas tiktu rādītas kā nepieejamas.
The Media Transfer Protocol ieviešana (MTP) atrisināja šo pirmo problēmu. Kad tas ir pievienots, dators redz jūsu ierīci kā “multivides atmiņas” ierīci. Tā pieprasa failu sarakstu no jūsu tālruņa, un MTP atgriež failu sarakstu, ko dators var lejupielādēt no ierīces. Kad fails tiek pieprasīts dzēst, MTP nosūta komandu, lai noņemtu pieprasīto failu no krātuves. Atšķirībā no USB lielapjoma atmiņas režīma, kurā faktiski tiek pievienota “sdcard”, MTP ļauj lietotājam turpināt lietot ierīci, kamēr tā ir pievienota. Turklāt Android tālrunī esošajai failu sistēmai vairs nav nozīmes, lai dators atpazītu ierīcē esošos failus.
Otrkārt, bija fakts, ka VFAT nenodrošināja tādu stabilu atļauju pārvaldību, kāda bija nepieciešama Google. Sākotnēji daudzi lietojumprogrammu izstrādātāji uzskatīja “sdcard” par savu lietojumprogrammu datu izgāztuvi, kam nebija vienotas izpratnes par to, kur glabāt savus failus. Daudzas lietojumprogrammas vienkārši izveido mapi ar tās lietotnes nosaukumu un saglabā tās failus.
Gandrīz katrai lietojumprogrammai tajā laikā bija nepieciešams WRITE_EXTERNAL_STORAGE atļauja rakstīt savus lietojumprogrammu failus ārējā atmiņā. Tomēr vēl satraucošāks bija fakts, ka gandrīz katrā pieteikumā bija arī nepieciešams READ_EXTERNAL_STORAGE atļauja - tikai lasīt savus datu failus! Tas nozīmēja, ka lietojumprogrammas varēja viegli piekļūt datiem, kas saglabāti jebkurā ārējā atmiņā, un šādu atļauju bieži piešķīra lietotājs, jo tas bija nepieciešams daudzām lietotnēm, lai tās izlīdzinātu funkciju.
Google to skaidri uzskatīja par problemātisku. Visa atļauju pārvaldības ideja ir nodalīt, kurām lietotnēm var piekļūt un kurām nevar piekļūt. Ja gandrīz katrai lietotnei tiek piešķirta lasīšanas piekļuve potenciāli sensitīviem lietotāja datiem, atļauja ir bezjēdzīga. Tādējādi Google nolēma, ka viņiem ir vajadzīga jauna pieeja. Šeit parādās FUSE.
Failu sistēma lietotāja telpā (FUSE)
Sākot ar operētājsistēmu Android 4.4, Google nolēma vairs nepievienot virtuālo “sdcard” nodalījumu kā VFAT. Tā vietā Google sāka izmantot FUSE, lai emulētu FAT32 “sdcard” virtuālajā nodalījumā. Ar sdcard programmas izsaukšanu FUSE, lai emulētu FAT-on-sdcard stila direktoriju atļaujas, lietojumprogrammas varētu sākt piekļūt datiem, kas glabājas ārējā atmiņā neprasot nekādas atļaujas. Patiešām, sākot ar API 19. līmeni, READ_EXTERNAL_STORAGE vairs nebija nepieciešama, lai piekļūtu esošajiem failiem ārējā atmiņā — ar nosacījumu, ka FUSE dēmona izveidotā datu mape atbilst lietotnes pakotnes nosaukumam. FUSE tiktu galā sintezējot ārējā atmiņā esošo failu īpašnieku, grupu un režīmus kad ir instalēta lietojumprogramma.
FUSE atšķiras no kodola moduļiem, jo tas ļauj lietotājiem, kas nav priviliģēti, rakstīt virtuālās failu sistēmas. Iemesls, kāpēc Google ieviesa FUSE, ir diezgan vienkāršs - tas darīja to, ko viņi gribēja un jau bija labi saprotams un dokumentēts Linux pasaulē. Citējot a Google izstrādātājs šajā jautājumā:
"Tā kā FUSE ir jauka, stabila API, pārejot starp kodola versijām, nav nepieciešama apkope. Ja mēs migrētu uz kodola risinājumu, mēs reģistrētos, lai uzturētu ielāpu kopu katrai stabilai kodola versijai." -Džefs Šārkijs, Google programmatūras inženieris
Tomēr kļuva pilnīgi skaidrs, ka FUSE pieskaitāmās izmaksas citu problēmu starpā izraisīja veiktspējas uzlabojumus. Izstrādātājs, ar kuru runāju par šo jautājumu, Mihals Kovaļčiks, uzrakstīja lielisku emuāra ierakstu vairāk nekā pirms gada, detalizēti izklāstot pašreizējās problēmas ar FUSE. Sīkāku tehnisko informāciju var izlasīt viņa emuārā, bet es aprakstīšu viņa atklājumus (ar viņa atļauju) vairāk nespeciālistiskā izteiksmē.
Problēma ar FUSE
Operētājsistēmā Android “sdcard” userspace dēmons izmanto FUSE, lai ielādēšanas laikā pievienotu /dev/fuse emulētajā ārējās krātuves direktorijā. Pēc tam sdcard dēmons aptauj FUSE ierīcē visus neapstiprinātos ziņojumus no kodola. Ja klausījāties aplādes apraidi, iespējams, esat dzirdējis, ka Lemarchand kungs atsaucas uz FUSE, kas ievades/izvades operāciju laikā ievieš pieskaitāmās izmaksas. Būtībā tas notiek šādi.
Reālajā pasaulē šis veiktspējas hits ietekmē jebkura fails, kas saglabāts ārējā atmiņā.
Problēma #1 — I/O pieskaitāmās izmaksas
Pieņemsim, ka mēs izveidojam vienkāršu teksta failu ar nosaukumu “test.txt” un saglabājam to mapē /sdcard/test.txt (kas, ļauj Es jums atgādinu, faktiski ir /data/media/0/test.txt, pieņemot, ka pašreizējais lietotājs ir primārais lietotājs ierīce). Ja mēs vēlētos lasīt (komandu kaķis) šo failu, mēs sagaidām, ka sistēma izdos 3 komandas: atvērt, lasīt, tad aizvērt. Patiešām, kā Kovalčika kungs demonstrē lietošanu strace, tā notiek:
Taču, tā kā fails atrodas ārējā atmiņā, ko pārvalda sdcard dēmons, ir jāveic daudzas papildu darbības. Pēc Kowalczyk kunga teiktā, būtībā ir nepieciešami 8 papildu soļi katra no šīm 3 individuālajām komandām:
- Userspace lietojumprogramma izdod sistēmas izsaukumu, ko kodolā apstrādās FUSE draiveris (to redzam pirmajā strace izvadē)
- FUSE draiveris kodolā paziņo userspace dēmonam (sdcard) par jaunu pieprasījumu
- Userspace dēmons nolasa /dev/fuse
- Userspace dēmons parsē komandu un atpazīst faila darbību (piemēram, atvērts)
- Userspace dēmons izdod sistēmas izsaukumu faktiskajai failu sistēmai (EXT4)
- Kodols apstrādā fizisko piekļuvi datiem un nosūta datus atpakaļ uz lietotāja telpu
- Userspace modificē (vai ne) datus un vēlreiz nodod tos caur /dev/fuse kodolam
- Kodols pabeidz sākotnējo sistēmas izsaukumu un pārvieto datus uz faktisko userspace lietojumprogrammu (mūsu piemērā cat)
Šis šķiet daudz pieskaitāmās izmaksas tikai vienai I/O komandai, kas jāpalaiž. Un tev būtu taisnība. Lai to pierādītu, Kovalčika kungs izmēģināja divus dažādus I/O testus: vienu, kas ietvēra liela faila kopēšanu, bet otru daudzu mazu failu kopēšanu. Viņš salīdzināja FUSE ātrumu (virtuālajā nodalījumā, kas uzstādīts kā FAT32), apstrādājot šīs darbības, ar kodols (datu nodalījumā, kas formatēts kā EXT4), un viņš atklāja, ka FUSE patiešām sniedz nozīmīgu ieguldījumu virs galvas.
Pirmajā testā viņš abos testa apstākļos kopēja 725 MB failu. Viņš atklāja, ka FUSE ieviešana pārsūtīja lielus failus 17% lēnāk.
Otrajā testā viņš nokopēja 10 000 failu - katrs no tiem 5 KB lielums. Šajā scenārijā FUSE ieviešana bija beigusies 40 sekundes lēnāk lai kopētu būtībā 50 MB vērtu datu.
Reālajā pasaulē šis veiktspējas hits ietekmē jebkura fails, kas saglabāts ārējā atmiņā. Tas nozīmē, ka programmas, piemēram, Maps, kas glabā lielus failus /sdcard, mūzikas programmas, kurās tiek glabātas daudz mūzikas failu, kameras lietotnes un fotoattēli utt. Jebkuras I/O darbības, kas saistītas ar ārējo atmiņu, ietekmē FUSE pieskaitāmās izmaksas. Taču I/O pieskaitāmās izmaksas nav vienīgā FUSE problēma.
Problēma #2 — dubultā kešatmiņa
Datu kešatmiņa ir svarīga, lai uzlabotu datu piekļuves veiktspēju. Saglabājot atmiņā svarīgus datus, Linux kodols spēj ātri atsaukt šos datus, kad tas ir nepieciešams. Taču FUSE ieviešanas veida dēļ Android uzglabā divas reizes vairāk kešatmiņas, kas nepieciešama.
Kā parāda Kovalčika kungs, 10 MB fails tiks saglabāts kešatmiņā kā tieši 10 MB, bet tā vietā tiks palielināts kešatmiņas lielums. par aptuveni 20 MB. Tas ir problemātiski ierīcēs ar mazāku operatīvo atmiņu, jo Linux kodola veikali datu glabāšanai izmanto lapas kešatmiņu atmiņa. Kovalčika kungs pārbaudīja šo dubultās kešatmiņas problēmu, izmantojot šo pieeju:
- Izveidojiet zināma izmēra failu (testēšanai, 10 MB)
- Kopējiet to mapē /sdcard
- Izmetiet lapas kešatmiņu
- Uzņemiet momentuzņēmumu par lapas kešatmiņas izmantošanu
- Izlasiet testa failu
- Uzņemiet vēl vienu lapas kešatmiņas izmantošanas momentuzņēmumu
Viņš atklāja, ka pirms pārbaudes kodols lapas kešatmiņai izmantoja 241 MB. Kad viņš izlasīja testa failu, viņš gaidīja, ka lapas kešatmiņai tiks izmantots 251 MB. Tā vietā viņš atklāja, ka šis kodols izmantoja 263 MB lapas kešatmiņai - apmēram divreiz, nekā bija gaidīts. Iemesls tam ir tas, ka datus vispirms kešatmiņā ievieto lietotāja lietojumprogramma, kas sākotnēji izdevusi I/O zvanu (FUSE), un otrkārt, sdcard dēmons (EXT4 FS).
Problēma #3 — nepilnīga FAT32 ieviešana
Ir vēl divas problēmas, kas izriet no FUSE, kas emulē FAT32, izmantošanu, kas Android kopienā ir mazāk zināmas.
Pirmais ietver nepareizi laikspiedoli. Ja kādreiz esat pārsūtījis failu (piemēram, fotoattēlu) un pamanījāt, ka laikspiedols ir nepareizs, tas ir saistīts ar Android FUSE ieviešanu. Šim jautājumam ir pastāvēja gadiem. Precīzāk sakot, problēma ir saistīta ar utime () sistēmas izsaukums, kas ļauj mainīt faila piekļuves un modifikācijas laiku. Diemžēl zvaniem, kas veikti uz sdcard dēmonu kā standarta lietotājam, nav atbilstošas atļaujas izpildīt šo sistēmas izsaukumu. Tam ir risinājumi, taču tie ir nepieciešami jums ir root piekļuve.
Ja kādreiz esat pārsūtījis failu (piemēram, fotoattēlu) un pamanījāt, ka laikspiedols ir nepareizs, tas ir saistīts ar Android FUSE ieviešanu.
Nākamā problēma vairāk attiecas uz uzņēmumiem, kas izmanto kaut ko līdzīgu a smartSD karte. Pirms FUSE lietotņu veidotāji varēja uzraudzīt O_DIRECT karodziņš lai sazinātos ar kartē iebūvētu mikrokontrolleri. Izmantojot FUSE, izstrādātāji var piekļūt tikai faila kešatmiņā saglabātajai versijai un nevar redzēt nekādas mikrokontrollera nosūtītās komandas. Tas ir problemātiski dažām uzņēmumu/valdības/banku lietotnēm, kas sazinās ar pievienotās vērtības microSD kartēm.
Dempings DROŠINĀTĀJS SDCardFS
Daži oriģinālo iekārtu ražotāji šīs problēmas atpazina jau agri un sāka meklēt kodola risinājumu, lai aizstātu FUSE. Samsung, piemēram, izstrādāja SDCardFS kuras pamatā ir WrapFS. Šis kodola risinājums emulē FAT32 tāpat kā FUSE, taču tas novērš I/O pieskaitāmās izmaksas, dubulto kešatmiņu un citas problēmas, kuras esmu minējis iepriekš. (Jā, ļaujiet man to atkārtot, šis risinājums, ko Google tagad ievieš, ir balstīts uz Samsung darbu).
Pats Google beidzot ir atzinis ar FUSE saistītos trūkumus, tāpēc viņi ir sākuši virzīties uz Samsung izstrādāto kodola FAT32 emulācijas slāni. Uzņēmums, kā minēts Android izstrādātāju aizkulisēs podcast, ir strādājis pie tā, lai SDCardFS būtu pieejama visām ierīcēm gaidāmajā kodola versijā. Pašlaik jūs varat redzēt viņu progresu strādāt AOSP.
Kā Google izstrādātājs paskaidroja iepriekš, lielākais izaicinājums, ieviešot kodola risinājumu, ir pakotnes nosaukuma kartēšana uz lietojumprogrammas ID, kas nepieciešams, lai pakotne piekļūtu saviem datiem ārējā atmiņā, neprasot to atļaujas. Bet šis paziņojums tika izteikts pirms gada, un mēs esam sasnieguši punktu, kurā komanda SDCardFS sauc par savu "nākamo lielo lietu". Viņi jau ir apstiprinājuši, ka šausmīga laika zīmoga kļūda ir izlabots, pateicoties pārejai no FUSE, tāpēc varam gaidīt visas izmaiņas, kas radušās, atsakoties no FUSE.
Faktu pārbaudes maldīgi priekšstati
Ja esat sasniedzis raksta tik tālu, tad slava, ka sekojat līdz šim visam! Es vēlējos noskaidrot dažus jautājumus, kas man radās, rakstot šo rakstu:
- SDCardFS ir nav nekāda sakara ar faktiskajām SD kartēm. Tas ir vienkārši nosaukts kā tāds, jo tas apstrādā I/O piekļuvi /sdcard. Kā jūs atceraties, /sdcard ir novecojusi etiķete, kas attiecas uz jūsu ierīces “ārējo” krātuvi (kur lietotnes glabā savus multivides failus).
- SDCardFS ir nav tradicionāla failu sistēma piemēram, FAT32, EXT4 vai F2FS. Tā ir sakrautam iesaiņojuma failu sistēma, kas nodod komandas zemākajām, emulētajām failu sistēmām (šajā gadījumā /sdcard tas būtu FAT32).
- Attiecībā uz MTP nekas nemainīsies. Jūs turpināsiet izmantot MTP, lai pārsūtītu failus uz/no datora (līdz Google izvēlēsies labāku protokolu). Bet vismaz laikspiedola kļūda tiks novērsta!
- Kā minēts iepriekš, kad Google atsaucas uz "ārējo krātuvi", viņi runā vai nu par (visiem nolūkiem un iekšējais / sdcard virtuālais FAT32 nodalījums VAI viņi runā par faktisku, fizisku, noņemamu microSD. karti. Terminoloģija ir mulsinoša, bet tas ir tas, ar ko mēs esam pārsteigti.
Secinājums
Pārejot no FUSE un ieviešot kodola FAT32 emulācijas slāni (SDCardFS), Google samazinās ievērojamas I/O pieskaitāmās izmaksas, novēršot dubulto kešatmiņu un atrisinot dažas neskaidras problēmas, kas saistītas ar tā FUSE emulāciju FAT32.
Tā kā šīs izmaiņas tiks veiktas kodolā, tās var ieviest bez nozīmīgas jaunas Android versijas. Daži lietotāji sagaida, ka šīs izmaiņas tiks oficiāli ieviestas operētājsistēmā Android 8, taču tas ir iespējams jebkurai turpmākai OTA Pixel ierīcē, lai nodrošinātu Linux kodola versiju 4.1, ar kuru Google ir strādājis ieslēgts.
Dažiem no jums SDCardFS nav jauns jēdziens. Faktiski Samsung ierīces to ir izmantojušas gadiem ilgi (galu galā tās bija tās, kas to izstrādāja). Kopš SDCardFS pagājušajā gadā tika ieviests AOSP, daži pielāgoti ROM un kodola izstrādātāji ir izvēlējušies to ieviest savā darbā. CyanogenMOD vienā brīdī apsvēra tā ieviešanu, taču to atcēla, kad lietotāji saskārās ar problēmām ar fotoattēliem. Bet cerams, ka Google pārņems valdību šajā projektā, Android lietotāji visās turpmākajās ierīcēs varēs izmantot uzlabojumus, kas ieviesti, atsakoties no FUSE.