Išsamus SDCardFS – „Google“ FUSE pakeitimo – tyrimas ir kaip jo įgyvendinimas sumažins I/O išlaidas.
Prieš kelis mėnesius „Google“ pridėjo kažką, vadinamą „SDCardFS“ į oficialius AOSP filialus, skirtus „Linux“ branduoliui. Tuo metu judėjimą pastebėjo tik kai kurie branduolio kūrėjai, bet šiaip skrido po daugumos vartotojų radaru. Nenuostabu, atsižvelgiant į tai, kad dauguma vartotojų, įskaitant mane, iš tikrųjų nežino, kas vyksta po „Android“ OS ir jos branduolio gaubtu.
Tačiau naujausias epizodas Android kūrėjai užkulisiuose podcast'as vėl susidomėjo šia tema. Podcast'as, kurį rengia Chet Haase (vyresnysis programinės įrangos inžinierius iš Google), išnagrinėjo naujausius ir būsimus branduolio pakeitimus. Laidoje dalyvavo „Linux“ branduolio kūrėjas, dirbantis „Android“ komandoje – Rom Lemarchand. Duetas pirmiausia aptarė, kokie pakeitimai buvo padaryti, kad atitiktų A/B atnaujinimus, tačiau paskutinėmis 5 serijos minutėmis ponas Lemarchandas kalbėjo apie „kitą didelį dalyką“, prie kurio dirbo jo komanda – SDCardFS.
Turiu pripažinti, kad apie SDCardFS egzistavimą sužinojau išklausęs šią podcast'ą. Žinoma, šia tema domėjausi ne aš vienas, nes a naujausia Reddit tema parodė. Tačiau manęs netenkino pagrindinis podcast'e pateiktas paaiškinimas ir stengiuosi išsklaidyti kai kuriuos skleidžiama klaidinga informacija, atlikau tam tikrus tyrimus ir kalbėjausi su keliais ekspertais, turinčiais atitinkamų žinių reikalas.
Didelis ačiū programinės įrangos kūrėjui Michal Kowalczyk už savo žiniomis prisidėjusį prie šio straipsnio ir skirtą laiko atsakyti į mano klausimus.
„Išorinis“ yra tikrai vidinis
Neabejotinai turime išaiškinti keletą klaidingų nuomonių – kitaip likusi straipsnio dalis bus labai paini. Naudinga aptarti SD kortelių ir „Android“ telefonų istoriją.
Pirmosiomis „Android“ telefonų dienomis beveik kiekvienas įrenginys naudojo „microSD“ korteles. Taip buvo dėl to, kad tuo metu telefonai buvo tiekiami su nedidelėmis vidinės atminties talpa. Tačiau SD kortelės, naudojamos programoms saugoti, dažnai nesuteikia puikios vartotojo patirties, bent jau lyginant su greičiu, kuriuo vidinė „flash“ atmintis gali skaityti / rašyti duomenis. Todėl vis didėjantis SD kortelių naudojimas išoriniam duomenų saugojimui tapo „Google“ vartotojų rūpesčiu.
Dėl ankstyvo SD kortelių, kaip išorinių saugojimo įrenginių, paplitimo, „Android“ saugyklos pavadinimų suteikimo taisyklės buvo pagrįstos tuo, kad kiekvienas įrenginys turėjo tikrą fizinį „microSD“ kortelės lizdą. Tačiau net ir įrenginiuose, kuriuose nebuvo SD kortelės lizdo, etiketė /sdcard vis tiek buvo naudojama nurodant tikrąją vidinės atminties lustą. Dar daugiau painiavos yra tai, kad įrenginiai, kuriuose buvo naudojama tiek fizinė SD kortelė, tiek didelės talpos atminties lustas, dažnai pavadintų savo skaidinius pagal SD kortelę. Pavyzdžiui, šiuose įrenginiuose /sdcard prijungimo taškas reikštų tikrąją vidinę atminties lustą, o kažkas panašaus į /storage/sdcard1 reikštų fizinę išorinę kortelę.
Taigi, nors „microSD“ kortelė praktiškai laikoma išorine saugykla, dėl pavadinimų suteikimo „SDCard“ išliko jau seniai po bet kokio faktinio fizinės kortelės naudojimo. Ši painiava su saugykla taip pat sukėlė galvos skausmą programų kūrėjams dėl to, kad programos duomenys ir jos laikmenos buvo atskirti tarp dviejų skaidinių.
Dėl mažos ankstyvųjų vidinės atminties lustų saugyklos vietos vartotojai nusivylė sužinoję, kad nebegali įdiegti programų (dėl to, kad /data skaidinys yra pilnas). Tuo tarpu jų didesnės talpos „microSD“ kortelės buvo nuleistos į tik laikmenas (pvz., nuotraukas, muziką ir filmus). Vartotojai, kurie anksčiau naršė mūsų forumus, gali prisiminti šiuos pavadinimus: Link2SD ir Apps2SD. Tai buvo (šakniniai) sprendimai, leidžiantys vartotojams įdiegti savo programas ir jų duomenis fizinėje SD kortelėje. Tačiau tai toli gražu nebuvo tobuli sprendimai, todėl „Google“ turėjo įsikišti.
Žinoma, „Google“ labai anksti išjungė SD kortelių kištuką. „Nexus One“ išlieka vienintelis „Nexus“ įrenginys su „microSD“ kortelės lizdu (ir taip bus amžinai, nes „Nexus“ prekės ženklas iš tikrųjų miręs). Su Nexus S dabar buvo tik vienas vieningas skaidinys, skirtas saugoti visus programos duomenis ir laikmenas – skaidinys /data. Tai, kas kažkada buvo žinoma kaip /sdcard prijungimo taškas, dabar buvo tiesiog nuoroda į virtualią failų sistemą (įdiegta pagal LYDUSIS SAUGIKLIS protokolą, kaip aprašyta toliau), esantį duomenų skaidinyje - /data/media/0.
Siekdama išlaikyti suderinamumą ir sumažinti painiavą, „Google“ vis tiek naudojo šį virtualų „sdcard“ skaidinį laikmenai laikyti. Tačiau dabar, kai šis „sdcard“ virtualus skaidinys iš tikrųjų buvo /data, viskas, kas jame saugoma, bus įskaityta į vidinės atminties lusto atminties vietą. Taigi OĮG turėjo nuspręsti, kiek vietos skirti programoms (/data), palyginti su laikmenomis (/data/media).
„Google“ tikėjosi, kad gamintojai pasektų jų pavyzdžiu ir atsikratytų SD kortelių. Laimei, laikui bėgant telefonų gamintojai sugebėjo įsigyti šių komponentų didesnio pajėgumo, tačiau išliko ekonomiškai efektyvūs, todėl SD kortelių poreikis pradėjo mažėti. Tačiau pavadinimų suteikimo taisyklės išliko siekiant sumažinti kūrėjų ir originalios įrangos gamintojų pastangas prisitaikyti. Šiuo metu, kai kalbame apie „išorinę saugyklą“, turime omenyje arba vienas iš dviejų dalykų: tikroji išimama „microSD“ kortelė arba virtualus „SDCard“ skaidinys, esantis /data/media. Pastaroji iš jų, praktiškai, iš tikrųjų yra vidinė atmintis, tačiau „Google“ pavadinimų suteikimo taisyklė ją išskiria dėl to, kad šie duomenys yra pasiekiami vartotojui (pvz., prijungus prie kompiuterio).
Šiuo metu, kai kalbame apie „išorinę saugyklą“, turime omenyje arba vienas iš dviejų dalykų: tikroji išimama „microSD“ kortelė arba virtualus „SDCard“ skaidinys, esantis /data/media.
„Android“ virtualių failų sistemų istorija
Dabar, kai „sdcard“ traktuojama kaip virtuali failų sistema, tai reiškė, kad ją galima suformatuoti kaip bet kurią „Google“ pageidaujamą failų sistemą. Pradedant nuo „Nexus S“ ir „Android 2.3“, „Google“ pasirinko formatuoti „sdcard“ kaip VFAT (virtualus FAT). Šis žingsnis tuo metu buvo prasmingas, nes įdiegus VFAT beveik bet kuris kompiuteris galėtų pasiekti jūsų telefone saugomus duomenis. Tačiau dėl šio pradinio įgyvendinimo kilo dvi pagrindinės problemos.
Pirmasis visų pirma susijęs su galutiniu vartotoju (jumis). Norėdami prijungti įrenginį prie kompiuterio, duomenims perduoti naudosite USB didelės atminties režimą. Tačiau tam reikėjo, kad „Android“ įrenginys atjungtų virtualų skaidinį, kad kompiuteris galėtų pasiekti duomenis. Jei vartotojas norėtų naudoti įrenginį, kai jis prijungtas, daugelis dalykų būtų rodomi kaip nepasiekiami.
The Media Transfer Protocol įvedimas (MTP) išsprendė šią pirmąją problemą. Kai prijungtas, kompiuteris mato jūsų įrenginį kaip „medijos saugyklos“ įrenginį. Ji prašo failų sąrašo iš jūsų telefono, o MTP pateikia failų, kuriuos kompiuteris gali atsisiųsti iš įrenginio, sąrašą. Kai prašoma ištrinti failą, MTP siunčia komandą pašalinti prašomą failą iš saugyklos. Skirtingai nuo USB didelės atminties režimo, kuriame iš tikrųjų pritvirtinama „sdcard“, MTP leidžia vartotojui toliau naudoti įrenginį, kai jis prijungtas. Be to, „Android“ telefone esanti failų sistema nebesvarbi, kad kompiuteris atpažintų įrenginyje esančius failus.
Antra, buvo tai, kad VFAT nepateikė tokio patikimo leidimų valdymo, kokio reikėjo „Google“. Iš pradžių daugelis programų kūrėjų „sdcard“ laikydavo savo programos duomenų išmetimo vieta, neturėdami vieningo supratimo, kur saugoti savo failus. Daugelis programų tiesiog sukurtų aplanką su programos pavadinimu ir jame saugotų failus.
Beveik kiekvienai programai tuo metu reikėjo WRITE_EXTERNAL_STORAGE leidimas rašyti savo programų failus į išorinę saugyklą. Tačiau dar didesnį nerimą kėlė tai, kad beveik kiekvienai programai taip pat reikėjo READ_EXTERNAL_STORAGE leidimas - tik skaityti savo duomenų failus! Tai reiškė, kad programos galėjo lengvai pasiekti duomenis, saugomus bet kurioje išorinės saugyklos vietoje, ir tokį leidimą dažnai suteikdavo vartotojas, nes jis buvo reikalingas daugeliui programų funkcija.
„Google“ aiškiai matė, kad tai problematiška. Visa leidimų valdymo idėja yra atskirti, prie ko programos gali ir ko negali pasiekti. Jei beveik kiekvienai programai suteikiama skaitymo prieiga prie potencialiai jautrių naudotojų duomenų, leidimas yra beprasmis. Taigi „Google“ nusprendė, kad jiems reikia naujo požiūrio. Štai čia ir atsiranda FUSE.
Failų sistema vartotojo erdvėje (FUSE)
Pradedant nuo 4.4 versijos „Android“, „Google“ nusprendė nebediegti virtualaus „sdcard“ skaidinio kaip VFAT. Vietoj to, „Google“ pradėjo naudoti FUSE, kad emuliuotų FAT32 „sdcard“ virtualiajame skaidinyje. Su sdcard programa skambina FUSE emuliuoti FAT-on-sdcard stiliaus katalogo leidimus, programos galėtų pradėti pasiekti išorinėje saugykloje saugomus duomenis nereikalaujant jokių leidimų. Iš tiesų, pradedant nuo 19 API lygio, READ_EXTERNAL_STORAGE nebereikėjo pasiekti esančių failų išorinėje saugykloje – su sąlyga, kad FUSE demono sukurtas duomenų aplankas sutampa su programos paketo pavadinimu. FUSE susitvarkytų išorinėje saugykloje esančių failų savininko, grupės ir režimų sintetinimas kai įdiegiama programa.
FUSE skiriasi nuo branduolio modulių, nes leidžia neprivilegijuotiems vartotojams rašyti virtualias failų sistemas. Priežastis, kodėl „Google“ įdiegė FUSE, yra gana paprasta – ji padarė tai, ko norėjo ir jau buvo gerai suprantamas ir dokumentuotas Linux pasaulyje. Cituoti a „Google“ kūrėjas šiuo klausimu:
„Kadangi FUSE yra puiki stabili API, pereinant tarp branduolio versijų iš esmės nereikia jokios priežiūros. Jei pereitume prie branduolio sprendimo, prisiregistruotume, kad išlaikytume pataisų rinkinį kiekvienai stabiliai branduolio versijai.“ – Jeffas Sharkey, „Google“ programinės įrangos inžinierius
Tačiau tapo visiškai aišku, kad FUSE pridėtinės išlaidos, be kitų problemų, sukėlė našumą. Kūrėjas, su kuriuo kalbėjausi šiuo klausimu, Michalas Kowalczykas, parašė puikų tinklaraščio įrašą daugiau nei prieš metus, išsamiai aprašydamas dabartines FUSE problemas. Daugiau techninių detalių galite perskaityti jo tinklaraštyje, bet aš aprašysiu jo išvadas (su jo leidimu) labiau neprofesionaliai.
Problema su FUSE
„Android“ sistemoje „sdcard“ vartotojo erdvės demonas naudoja FUSE, kad prijungtų /dev/fuse į emuliuotą išorinės atminties katalogą įkrovos metu. Po to sdcard demonas apklausia FUSE įrenginį, ar nėra laukiančių žinučių iš branduolio. Jei klausėtės podcast'o, galbūt girdėjote, kad ponas Lemarchandas kalba apie FUSE, įvedant pridėtines išlaidas įvesties / išvesties operacijų metu – štai kas atsitinka iš esmės.
Realiame pasaulyje šis našumo hitas turi įtakos bet koks failas, saugomas išorinėje saugykloje.
1 problema – I/O pridėtinės išlaidos
Tarkime, kad sukuriame paprastą tekstinį failą, vadinamą „test.txt“, ir išsaugome jį /sdcard/test.txt (kuris primenu, iš tikrųjų yra /data/media/0/test.txt, darant prielaidą, kad dabartinis vartotojas yra pagrindinis vartotojas prietaisas). Jei norėtume perskaityti (komandų katė) šį failą, tikėtume, kad sistema duos 3 komandas: atidaryti, skaityti, tada uždaryti. Iš tiesų, kaip P. Kowalczyk demonstruoja naudodamas trace, štai kas atsitinka:
Tačiau kadangi failas yra išorinėje saugykloje, kurią valdo sdcard demonas, reikia atlikti daug papildomų operacijų. P. Kowalczyko teigimu, iš esmės reikalingi 8 papildomi žingsniai kiekviena iš šių 3 atskirų komandų:
- „Userspace“ programa išduoda sistemos iškvietimą, kurį tvarkys branduolio FUSE tvarkyklė (jį matome pirmoje strace išvestyje)
- Branduolio FUSE tvarkyklė praneša vartotojo erdvės demonui (sdcard) apie naują užklausą
- Userspace demonas skaito /dev/fuse
- „Userspace“ demonas analizuoja komandą ir atpažįsta failo operacijas (pvz.,. atviras)
- „Userspace“ demonas iškviečia sistemos iškvietimą į tikrąją failų sistemą (EXT4)
- Branduolys tvarko fizinę prieigą prie duomenų ir siunčia duomenis atgal į vartotojo erdvę
- Userspace modifikuoja (arba ne) duomenis ir vėl perduoda juos per /dev/fuse į branduolį
- Branduolys užbaigia pradinį sistemos iškvietimą ir perkelia duomenis į tikrąją vartotojo erdvės programą (mūsų pavyzdyje katė)
Tai atrodo kaip daug pridėtinės vertės tik vienai įvesties / išvesties komandai, kuri turi būti paleista. Ir tu būtum teisus. Norėdamas tai įrodyti, J. Kowalczyk bandė atlikti du skirtingus įvesties/išvesties testus: vieną nukopijavo didelį failą, o kitą – daug mažų failų. Jis palygino FUSE (virtualiame skaidinyje, sumontuotame kaip FAT32), apdorojančio šias operacijas, greitį su branduolį (duomenų skaidinyje, suformatuotame kaip EXT4), ir jis nustatė, kad FUSE iš tiesų reikšmingai prisidėjo virš galvos.
Pirmajame bandyme jis nukopijavo 725 MB failą abiem bandymo sąlygomis. Jis nustatė, kad FUSE įgyvendinimas perdavė didelius failus 17% lėčiau.
Antrojo bandymo metu jis nukopijavo 10 000 failų – kiekvienas iš jų 5 KB dydžio. Pagal šį scenarijų FUSE diegimas buvo baigtas 40 sekundžių lėčiau nukopijuoti iš esmės 50 MB vertės duomenų.
Realiame pasaulyje šis našumo hitas turi įtakos bet koks failas, saugomas išorinėje saugykloje. Tai reiškia, kad programos, pvz., Žemėlapiai, kuriose saugomi dideli failai / sdcard, muzikos programos, kuriose saugoma daugybė muzikos failų, fotoaparato programos ir nuotraukos ir kt. Bet kuri atliekama įvesties / išvesties operacija, susijusi su išorine atmintimi, yra paveikta FUSE pridėtinių išlaidų. Tačiau I / O pridėtinės išlaidos nėra vienintelė FUSE problema.
2 problema – dvigubas kaupimas talpykloje
Duomenų kaupimas talpykloje yra svarbus gerinant prieigos prie duomenų našumą. Saugodamas atmintyje esminius duomenų elementus, „Linux“ branduolys prireikus gali greitai prisiminti tuos duomenis. Tačiau dėl FUSE įdiegimo būdo „Android“ saugo dvigubai daugiau talpyklos, kurios reikia.
Kaip demonstruoja p. Kowalczyk, tikimasi, kad 10 MB failas talpykloje bus išsaugotas tiksliai kaip 10 MB, bet vietoj to bus padidintas talpyklos dydis maždaug 20 MB. Tai kelia problemų įrenginiuose, kuriuose yra mažiau RAM, nes „Linux“ branduolio parduotuvės naudoja puslapio talpyklą duomenims saugoti atmintis. P. Kowalczyk išbandė šią dvigubos talpyklos problemą naudodamas šį metodą:
- Sukurkite žinomo dydžio failą (tikrinimui, 10 MB)
- Nukopijuokite jį į /sdcard
- Išmeskite puslapio talpyklą
- Padarykite puslapio talpyklos naudojimo momentinę nuotrauką
- Perskaitykite testo failą
- Padarykite dar vieną puslapio talpyklos naudojimo momentinę nuotrauką
Jis nustatė, kad prieš bandymą branduolys naudojo 241 MB puslapio talpyklai. Perskaitęs savo bandomąjį failą, jis tikėjosi, kad puslapio talpykla bus panaudota 251 MB. Vietoj to jis nustatė, kad branduolys buvo naudojamas 263 MB puslapio talpyklai – apie dvigubai daugiau nei tikėtasi. Taip nutinka todėl, kad duomenis pirmiausia talpina vartotojo programa, kuri iš pradžių iškvietė įvesties / išvesties skambutį (FUSE), o antra – sdcard demonas (EXT4 FS).
3 problema – neužbaigtas FAT32 diegimas
Yra dar dvi problemos, kylančios dėl FUSE, emuliuojančio FAT32, naudojimo, kurios yra mažiau žinomos „Android“ bendruomenėje.
Pirmasis apima neteisingos laiko žymos. Jei kada nors perkėlėte failą (pvz., nuotrauką) ir pastebėjote, kad laiko žyma neteisinga, taip yra dėl to, kad „Android“ įdiegė FUSE. Ši problema turi egzistavo metų. Tiksliau tariant, problema susijusi su utime () sistemos skambutis, leidžiantis pakeisti failo prieigos ir modifikavimo laiką. Deja, skambučiai į sdcard demoną, kaip standartinis vartotojas, neturi tinkamo leidimo vykdyti šį sistemos iškvietimą. Yra būdų, kaip tai išspręsti, tačiau jie reikalauja jūsų turėti root prieigą.
Jei kada nors perkėlėte failą (pvz., nuotrauką) ir pastebėjote, kad laiko žyma neteisinga, taip yra dėl to, kad „Android“ įdiegė FUSE.
Kita problema labiau rūpi įmonėms, naudojančioms kažką panašaus į a smartSD kortelė. Prieš naudodami FUSE, programų kūrėjai galėjo stebėti O_DIRECT vėliava norint susisiekti su įdėtu mikrovaldikliu į kortelę. Naudodami FUSE kūrėjai gali pasiekti tik talpykloje saugomą failo versiją ir nemato jokių mikrovaldiklio siunčiamų komandų. Tai kelia problemų kai kurioms įmonių / vyriausybės / bankų programoms, kurios palaiko ryšį su pridėtinės vertės „microSD“ kortelėmis.
Dempingo SDCardFS saugiklis
Kai kurie originalios įrangos gamintojai šias problemas pastebėjo anksti ir pradėjo ieškoti branduolyje esančio sprendimo, kuris pakeistų FUSE. Pavyzdžiui, „Samsung“ sukūrė SDCardFS kuris yra pagrįstas WrapFS. Šis branduolyje esantis sprendimas emuliuoja FAT32, kaip ir FUSE, bet atsisako įvesties / išvesties, dvigubos talpyklos ir kitų anksčiau minėtų problemų. (Taip, leiskite man pakartoti tai, šis sprendimas, kurį dabar diegia „Google“, yra pagrįstas „Samsung“ darbu).
Pati „Google“ pagaliau pripažino trūkumus, susijusius su FUSE, todėl jie pradėjo judėti į „Samsung“ sukurtą branduolio FAT32 emuliacijos sluoksnį. Bendrovė, kaip minėta Android kūrėjai užkulisiuose podcast'as, stengėsi, kad SDCardFS būtų prieinamas visiems būsimos branduolio versijos įrenginiams. Šiuo metu galite matyti jų eigą dirbti AOSP.
Kaip „Google“ kūrėjas paaiškino anksčiau, didžiausias iššūkis diegiant branduolio sprendimą yra susieti paketo pavadinimą su programos ID reikalingas, kad paketas galėtų pasiekti savo duomenis išorinėje saugykloje nereikalaujant leidimai. Tačiau šis pareiškimas buvo pateiktas prieš metus, ir mes pasiekėme tašką, kai komanda SDCardFS vadina „kitu dideliu dalyku“. Jie jau patvirtino, kad baisi laiko žymos klaida buvo ištaisyta, nes buvo atsisakyta FUSE, todėl galime laukti visų pakeitimų, atsiradusių atsisakius FUSE.
Faktų tikrinimo klaidingos nuomonės
Jei priėjote iki šio straipsnio, ačiū, kad iki šiol neatsilikote nuo visko! Norėjau paaiškinti keletą klausimų, kurie man kilo rašant šį straipsnį:
- SDCardFS turi nieko bendro su tikromis SD kortelėmis. Jis tiesiog pavadintas taip, nes tvarko /sdcard įvesties / išvesties prieigą. Ir, kaip galbūt prisimenate, /sdcard yra pasenusi etiketė, nurodanti „išorinę“ jūsų įrenginio saugyklą (kur programos saugo savo laikmeną).
- SDCardFS yra ne tradicinė failų sistema kaip FAT32, EXT4 arba F2FS. Tai yra sukrauti įpakavimo failų sistema, perduodanti komandas žemesnėms, emuliuotoms failų sistemoms (šiuo atveju tai būtų FAT32 / sdcard).
- MTP atžvilgiu niekas nepasikeis. Ir toliau naudosite MTP failams perkelti į kompiuterį/iš jo (kol „Google“ nustatys geresnį protokolą). Bet bent jau laiko žymos klaida bus ištaisyta!
- Kaip minėta anksčiau, kai „Google“ nurodo „išorinę saugyklą“, jie kalba arba apie (visais tikslais ir tikslams) vidinis / sdcard virtualus FAT32 skaidinys ARBA jie kalba apie tikrą, fizinį, nuimamą „microSD“ kortelę. Terminologija yra paini, bet tai mus pribloškė.
Išvada
Atsitraukusi nuo FUSE ir įdiegusi branduolyje esantį FAT32 emuliacijos sluoksnį (SDCardFS), „Google“ sumažins didelių įvesties / išvesties išlaidų, pašalinant dvigubą talpyklą ir išsprendžiant kai kurias neaiškias problemas, susijusias su jo FUSE emuliacija. FAT32.
Kadangi šie pakeitimai bus atlikti branduolyje, jie gali būti išleisti kartu su ja neįdiegus didelės naujos „Android“ versijos. Kai kurie vartotojai tikisi, kad šie pakeitimai bus oficialiai įdiegti „Android 8“, tačiau tai įmanoma bet kokiai būsimai OTA Pixel įrenginyje, kad būtų įdiegta 4.1 „Linux“ branduolio versija, kurią naudojo „Google“. įjungta.
Kai kuriems iš jūsų SDCardFS nėra nauja koncepcija. Tiesą sakant, „Samsung“ įrenginiai jį naudoja daugelį metų (galų gale, jie buvo tie, kurie jį sukūrė). Nuo tada, kai praėjusiais metais AOSP buvo pristatyta SDCardFS, kai kurie pasirinktinių ROM ir branduolio kūrėjai nusprendė jį įdiegti savo darbe. Vienu metu „CyanogenMOD“ svarstė galimybę jį įdiegti, bet atšaukė, kai naudotojai susidūrė su problemomis su savo nuotraukomis. Tačiau tikimės, kad šiame projekte pradėjus valdyti „Google“, „Android“ naudotojai visuose būsimuose įrenginiuose galės pasinaudoti patobulinimais, pateiktais atsisakydami FUSE.