Sukella SDCardFS: ään: Kuinka Googlen FUSE-vaihto vähentää I/O-ylikustannuksia

Perusteellinen tutkimus SDCardFS: stä, Googlen FUSE: n korvaamisesta, ja siitä, kuinka sen käyttöönotto vähentää I/O-ylimääräisiä kustannuksia.

Muutama kuukausi sitten Google lisäsi jotain nimeltä "SDCardFS” virallisiin AOSP-haaroihin Linux-ytimelle. Tuolloin liikkeen huomasi vain jotkut ytimen kehittäjät, mutta muuten lensi useimpien käyttäjien tutkan alla. Ei mikään yllätys, kun otetaan huomioon se tosiasia, että useimmat käyttäjät, mukaan lukien minä, eivät todellakaan tiedä, mitä Android-käyttöjärjestelmän ja sen ytimen alla tapahtuu.

Kuitenkin viimeisin jakso Android-kehittäjien kulissien takana podcast herätti kiinnostusta tähän aiheeseen. Chet Haasen (Googlen vanhempi ohjelmistosuunnittelija) isännöimässä podcastissa tutkittiin viimeaikaisia ja tulevia ytimeen tehtyjä muutoksia. Ohjelmassa oli Android-tiimin parissa työskentelevä Linux-ytimen kehittäjä Rom Lemarchand. Kaksikko keskusteli ensisijaisesti siitä, mitä muutoksia tehtiin A/B-päivitysten mukauttamiseksi, mutta jakson viimeisen 5 minuutin aikana Mr. Lemarchand puhui "seuraavasta suuresta asiasta", jonka parissa hänen tiiminsä työskenteli -

SDCardFS.

Minun on myönnettävä, että sain tietää SDCardFS: n olemassaolosta tämän podcastin kuuntelun jälkeen. En tietenkään ollut ainoa, joka oli kiinnostunut tästä aiheesta, koska a tuore Reddit-ketju on osoittanut. En kuitenkaan ollut tyytyväinen podcastissa esitettyyn perusselitykseen, ja yritin hälventää joitain väärän tiedon leviämisen vuoksi tein oman tutkimukseni ja keskustelin muutamien asiantuntijoiden kanssa, joilla oli asiaankuuluvaa tietoa asia.

Suuret kiitokset ohjelmistokehittäjä Michal Kowalczykille tämän artikkelin kirjoittamisesta ja siitä, että käytit aikaa vastata kysymyksiini.

"Ulkoinen" on todella sisäinen

Heti alkuun tulee varmasti joitain väärinkäsityksiä, jotka meidän on selvitettävä - muuten artikkelin loppuosa on hyvin hämmentävää. On hyödyllistä keskustella SD-korttien ja Android-puhelimien historiasta.

Android-puhelimien alkuaikoina lähes kaikki laitteet luottivat microSD-korttiensa käyttöön tallentamiseen. Tämä johtui siitä, että puhelimet toimitettiin tuolloin pienellä sisäisellä tallennuskapasiteetilla. Sovellusten tallentamiseen käytettävät SD-kortit eivät kuitenkaan usein tarjoa loistavaa käyttökokemusta, ainakaan verrattuna nopeuteen, jolla sisäinen flash-muisti pystyy lukemaan/kirjoittamaan tietoja. Siksi SD-korttien lisääntyvä käyttö ulkoiseen tietojen tallentamiseen oli tulossa Googlen käyttäjäkokemuksen huolenaiheeksi.

Koska SD-kortit yleistyivät varhaisessa vaiheessa ulkoisina tallennuslaitteina, Androidin tallennustilan nimeämiskäytännöt perustuivat siihen, että jokaisessa laitteessa oli todellinen, fyysinen microSD-korttipaikka. Mutta jopa laitteissa, joissa ei ollut SD-korttipaikkaa, /sdcard-tarraa käytettiin silti osoittamaan todellista sisäistä tallennussirua. Hämmentävämpää on se, että laitteet, jotka käyttivät sekä fyysistä SD-korttia että suurikapasiteettista tallennussirua, nimeävät usein osiensa SD-kortin ympärille. Esimerkiksi näissä laitteissa /sdcard-liitoskohta viittaa varsinaiseen sisäiseen tallennussiruun, kun taas jokin kuten /storage/sdcard1 viittaa fyysiseen ulkoiseen korttiin.

Vaikka microSD-korttia pidetään käytännössä ulkoisena tallennustilana, nimeämiskäytäntö johti siihen, että "SDCard" pysyi mukana kauan ennen fyysisen kortin todellista käyttöä. Tämä hämmennys tallennustilan kanssa aiheutti myös päänsärkyä sovelluskehittäjille, koska sovellustiedot ja sen mediat erotettiin kahden osion välillä.

Varhaisten sisäisten tallennussirujen alhainen tallennustila johti siihen, että käyttäjät huomasivat turhautuneesti, etteivät he voineet enää asentaa sovelluksia (koska /data-osio oli täynnä). Samaan aikaan heidän suuremman kapasiteetin microSD-kortit siirrettiin säilyttämään vain mediaa (kuten valokuvia, musiikkia ja elokuvia). Käyttäjät, jotka selaisivat foorumeita aikoinaan, saattavat muistaa nämä nimet: Link2SD ja Apps2SD. Nämä olivat (juuri)ratkaisuja, joiden avulla käyttäjät pystyivät asentamaan sovelluksensa ja sen tiedot fyysiselle SD-kortille. Mutta nämä olivat kaukana täydellisistä ratkaisuista, joten Googlen täytyi puuttua asiaan.

Tunnetusti Google otti SD-korttien pistokkeen hyvin varhain. Nexus One on edelleen ainoa Nexus-laite, jossa on microSD-korttipaikka (ja se tulee olemaan ikuisesti, koska Nexus-tuotemerkki on käytännössä kuollut). Nexus S: ssä oli nyt vain yksi yhtenäinen osio kaikkien sovellustietojen ja median tallentamiseen - /data-osio. Se mikä aiemmin tunnettiin /sdcard-liitospisteenä, viittasi nyt yksinkertaisesti virtuaaliseen tiedostojärjestelmään (toteutettu SULAKE protokolla alla kuvatulla tavalla), joka sijaitsee dataosiossa - /data/media/0.

Yhteensopivuuden ylläpitämiseksi ja sekaannusten vähentämiseksi Google käytti edelleen tätä nyt virtuaalista "sdcard"-osiota median säilyttämiseen. Mutta nyt, kun tämä "sdcard"-virtuaaliosio todella sijaitsi /data-kansiossa, kaikki siihen tallennettu laskettaisiin mukaan sisäisen tallennussirun tallennustilaan. Näin ollen OEM-valmistajien oli harkittava, kuinka paljon tilaa varata sovelluksille (/data) verrattuna mediaan (/data/media).

Kaksi hyvin erilaista "SD-korttia"

Google toivoi, että valmistajat seuraisivat heidän esimerkkiään ja pääsisivät eroon SD-korteista. Onneksi ajan myötä puhelinvalmistajat pystyivät hankkimaan näitä komponentteja suuremmalla kapasiteetilla säilyttäen samalla kustannustehokkuuden, joten SD-korttien tarve alkoi olla vähissä. Nimeämiskäytännöt ovat kuitenkin edelleen vähentäneet ponnisteluja, jotka kehittäjien ja OEM-valmistajien on tehtävä sopeutuakseen. Tällä hetkellä, kun viittaamme "ulkoiseen tallennustilaan", tarkoitamme jompikumpi kahdesta asiasta: todellinen irrotettava microSD-kortti tai virtuaalinen "SDCard"-osio, joka sijaitsee /data/mediassa. Näistä jälkimmäinen käytännössä on itse asiassa sisäistä tallennustilaa, mutta Googlen nimeämiskäytäntö erottaa sen, koska käyttäjä voi käyttää näitä tietoja (kuten tietokoneeseen kytkettynä).

Tällä hetkellä, kun viittaamme "ulkoiseen tallennustilaan", tarkoitamme jompikumpi kahdesta asiasta: todellinen irrotettava microSD-kortti tai virtuaalinen "SDCard"-osio, joka sijaitsee /data/mediassa.

Androidin virtuaalisten tiedostojärjestelmien historia

Nyt kun "sdcard" on käsitelty virtuaalisena tiedostojärjestelmänä, se tarkoitti, että se voitiin muotoilla mihin tahansa tiedostojärjestelmään, jonka Google halusi. Nexus S: stä ja Android 2.3:sta lähtien Google päätti alustaa "sdcardin" VFAT: ksi (virtuaali FAT). Tämä siirto oli tuolloin järkevä, koska VFATin asentaminen mahdollistaisi melkein minkä tahansa tietokoneen pääsyn puhelimeesi tallennettuihin tietoihin. Tässä alkuperäisessä toteutuksessa oli kuitenkin kaksi suurta ongelmaa.

Ensimmäinen koskee ensisijaisesti loppukäyttäjää (sinua). Jos haluat yhdistää laitteesi tietokoneeseen, käytät USB-massamuistitilaa tietojen siirtämiseen. Tämä kuitenkin vaati Android-laitteen poistamaan virtuaalisen osion ennen kuin tietokone pääsi käsiksi tietoihin. Jos käyttäjä haluaisi käyttää laitettaan ollessaan kytkettynä verkkovirtaan, monet asiat näkyvät poissa käytöstä.

The Media Transfer Protocol -protokollan käyttöönotto (MTP) ratkaisi tämän ensimmäisen ongelman. Kun tietokone on kytketty verkkovirtaan, se näkee laitteesi "mediatallennuslaitteena". Se pyytää tiedostoluetteloa puhelimestasi, ja MTP palauttaa luettelon tiedostoista, jotka tietokone voi ladata laitteesta. Kun tiedostoa pyydetään poistamaan, MTP lähettää komennon poistaa pyydetyn tiedoston tallennustilasta. Toisin kuin USB-massamuistitila, joka todella asentaa "sd-kortin", MTP sallii käyttäjän jatkaa laitteen käyttöä, kun se on kytkettynä. Lisäksi Android-puhelimen tiedostojärjestelmällä ei ole enää väliä, jotta tietokone tunnistaa laitteen tiedostot.

Toiseksi, VFAT ei tarjonnut Googlen tarvitsemaa vankkaa käyttöoikeuksien hallintaa. Varhain monet sovelluskehittäjät pitivät "sd-korttia" sovellustietojensa kaatopaikkana ilman yhtenäistä käsitystä tiedostojensa tallentamisesta. Monet sovellukset luovat yksinkertaisesti kansion sovelluksen nimellä ja tallentavat tiedostonsa sinne.

Melkein jokainen sovellus siihen aikaan vaati WRITE_EXTERNAL_STORAGE lupa kirjoittaa sovellustiedostonsa ulkoiseen tallennustilaan. Huolestuttavampaa oli kuitenkin se, että lähes jokainen hakemus vaati myös READ_EXTERNAL_STORAGE lupa - vain lukea omia datatiedostojaan! Tämä tarkoitti, että sovellukset voivat helposti päästä käsiksi mihin tahansa ulkoiseen tallennustilaan tallennettuihin tietoihin, ja käyttäjä myönsi usein tällaisen luvan, koska se vaadittiin monien sovellusten tasaamiseksi toiminto.

Google piti tätä selvästi ongelmallisena. Koko ajatus käyttöoikeuksien hallinnan takana on erottaa, mihin sovelluksiin on pääsy ja mihin ei. Jos lähes jokaiselle sovellukselle myönnetään lukuoikeus mahdollisesti arkaluontoisiin käyttäjätietoihin, lupa on merkityksetön. Siksi Google päätti, että he tarvitsevat uuden lähestymistavan. Siinä FUSE tulee sisään.

Tiedostojärjestelmä käyttäjätilassa (FUSE)

Android 4.4:stä alkaen Google päätti olla asentamatta virtuaalista "sdcard"-osiota VFAT-muodossa. Sen sijaan Google alkoi käyttää FUSEa emuloidakseen FAT32:ta "sdcard"-virtuaaliosiossa. Sdcard-ohjelma kutsuu FUSE emuloi FAT-on-sdcard-tyylisiä hakemistooikeuksia, sovellukset voivat alkaa käyttää ulkoiseen tallennustilaan tallennettuja tietojaan ilman mitään lupia. Itse asiassa API-tasosta 19 alkaen READ_EXTERNAL_STORAGEa ei enää vaadittu päästäkseen tiedostoihin ulkoisessa tallennustilassa - edellyttäen, että FUSE-daemonin luoma tietokansio vastaa sovelluksen paketin nimeä. FUSE selviäisi syntetisoi ulkoisen tallennustilan tiedostojen omistajat, ryhmät ja tilat kun sovellus on asennettu.

FUSE eroaa ytimen sisäisistä moduuleista, koska se sallii etuoikeutettujen käyttäjien kirjoittaa virtuaalisia tiedostojärjestelmiä. Syy, miksi Google otti käyttöön FUSE: n, on melko yksinkertainen - se teki mitä he halusivat ja oli jo hyvin ymmärretty ja dokumentoitu Linuxin maailmassa. Lainatakseni a Googlen kehittäjä asiasta:

"Koska FUSE on mukava vakaa API, ytimen versioiden välillä siirryttäessä huoltotöitä ei vaadita käytännössä lainkaan. Jos siirtyisimme ytimen sisäiseen ratkaisuun, hyväksyisimme korjaustiedostojen ylläpidon jokaiselle vakaalle ydinversiolle." -Jeff Sharkey, Googlen ohjelmistosuunnittelija

Oli kuitenkin käymässä selväksi, että FUSE: n yleiskustannukset toivat osuman suorituskykyyn muiden ongelmien ohella. Kehittäjä, jonka kanssa puhuin tästä asiasta, Michal Kowalczyk, kirjoitti erinomaisen blogikirjoituksen yli vuosi sitten yksityiskohtaisesti FUSE: n nykyiset ongelmat. Lisää teknisiä yksityiskohtia voi lukea hänen blogistaan, mutta kuvailen hänen havaintojaan (hänen luvalla) maallikollisemmin.

Ongelma FUSE: n kanssa

Androidissa "sdcard" userspace -daemon käyttää FUSEa liittääkseen /dev/fuse emuloituun ulkoiseen tallennushakemistoon käynnistyksen yhteydessä. Sen jälkeen sdcard-daemon kysyy FUSE-laitteelta mahdolliset odottavat viestit ytimestä. Jos kuuntelit podcastia, olet saattanut kuulla Mr. Lemarchandin viittaavan FUSE: n käyttöön I/O-toimintojen aikana - tässä on periaatteessa mitä tapahtuu.

Todellisessa maailmassa tämä suorituskykyhitti vaikuttaa minkä tahansa ulkoiseen tallennustilaan tallennettu tiedosto.

Ongelma 1 - I/O Overhead

Oletetaan, että luomme yksinkertaisen tekstitiedoston nimeltä "test.txt" ja tallennamme sen kansioon /sdcard/test.txt (joka Muistutan teitä, on itse asiassa /data/media/0/test.txt, jos nykyinen käyttäjä on pääkäyttäjä laite). Jos halusimme lukea (komentokissa) tämän tiedoston, odotamme järjestelmän antavan kolme komentoa: avaa, lue ja sulje sitten. Todellakin, kuten herra Kowalczyk osoittaa käytön strace, näin tapahtuu:

Mutta koska tiedosto sijaitsee ulkoisessa tallennustilassa, jota sdcard-daemon hallitsee, on suoritettava monia lisätoimintoja. Kowalczykin mukaan tarvitaan olennaisesti 8 lisävaihetta kukin näistä 3 yksittäisestä komennosta:

Userspace-sovellus antaa järjestelmäkutsun, jonka FUSE-ohjain käsittelee ytimessä (näemme sen ensimmäisessä strace-ulostulossa)
Ytimen FUSE-ohjain ilmoittaa userspace-daemonille (sdcard) uudesta pyynnöstä
Userspace-daemon lukee /dev/fuse
Userspace daemon jäsentää komennon ja tunnistaa tiedoston toiminnan (esim. avata)
Userspace-daemon antaa järjestelmäkutsun varsinaiselle tiedostojärjestelmälle (EXT4)
Ydin käsittelee fyysisen tiedon pääsyn ja lähettää tiedot takaisin käyttäjätilaan
Userspace muokkaa (tai ei) tietoja ja välittää ne /dev/fuse kautta ytimeen uudelleen
Ydin suorittaa alkuperäisen järjestelmäkutsun ja siirtää tiedot todelliseen käyttäjätilasovellukseen (esimerkissämme cat)

Tämä näyttää siltä paljon vain yhteen suoritettavaan I/O-komentoon. Ja olisit oikeassa. Osoittaakseen tämän, herra Kowalczyk yritti kahta erilaista I/O-testiä: toisessa kopioitiin suuri tiedosto ja toisessa kopioitiin paljon pieniä tiedostoja. Hän vertasi näitä toimintoja käsittelevän FUSE: n (virtuaaliosion FAT32:na) nopeutta ydin (EXT4:ksi alustettu data-osio), ja hän havaitsi, että FUSE todellakin vaikutti merkittävästi yläpuolella.

Ensimmäisessä testissä hän kopioi 725 Mt: n tiedoston molemmissa testiolosuhteissa. Hän havaitsi, että FUSE-toteutus siirsi suuria tiedostoja 17 % hitaammin.

Toisessa testissä hän kopioi 10 000 tiedostoa, joista jokainen oli kooltaan 5 kt. Tässä skenaariossa FUSE-toteutus oli ohi 40 sekuntia hitaammin kopioida periaatteessa 50 megatavua dataa.

Todellisessa maailmassa tämä suorituskykyhitti vaikuttaa minkä tahansa ulkoiseen tallennustilaan tallennettu tiedosto. Tämä tarkoittaa, että sovellukset, kuten Maps, jotka tallentavat suuria tiedostoja /sdcard-kortille, musiikkisovellukset, jotka tallentavat paljon musiikkitiedostoja, kamerasovelluksia ja valokuvia jne. FUSE: n yleiskustannukset vaikuttavat kaikkiin suoritettaviin I/O-toimintoihin, joihin liittyy ulkoinen tallennustila. Mutta I/O overhead ei ole FUSE: n ainoa ongelma.

Ongelma 2 - Kaksoisvälimuisti

Tietojen välimuisti on tärkeää tiedonsaannin suorituskyvyn parantamiseksi. Tallentamalla tärkeitä tietoja muistiin, Linux-ydin pystyy nopeasti palauttamaan tiedot tarvittaessa. Mutta FUSE-käyttötavasta johtuen Android tallentaa kaksinkertaisen määrän välimuistia, joka tarvitaan.

Kuten herra Kowalczyk osoittaa, 10 megatavun tiedoston odotetaan tallentuvan välimuistiin täsmälleen 10 megatavua, mutta sen sijaan välimuistin kokoa kasvatetaan noin 20 Mt: lla. Tämä on ongelmallista laitteissa, joissa on vähemmän RAM-muistia, koska Linux-ytimen myymälät käyttävät sivuvälimuistia tietojen tallentamiseen muisti. Mr. Kowalczyk testasi tätä kaksoisvälimuistiongelmaa käyttämällä tätä lähestymistapaa:

Luo tunnetun kokoinen tiedosto (testausta varten, 10 Mt)
Kopioi se kansioon /sdcard
Pudota sivun välimuisti
Ota tilannekuva sivun välimuistin käytöstä
Lue testitiedosto
Ota toinen tilannekuva sivun välimuistin käytöstä

Hän havaitsi, että ennen testiään ydin käytti 241 Mt sivun välimuistiin. Kun hän oli lukenut testitiedostonsa, hän odotti näkevänsä 251 megatavua sivun välimuistiin. Sen sijaan hän havaitsi, että ydin käytti 263 Mt sivun välimuistille - noin kaksi kertaa odotettua. Syy tähän on se, että tiedot tallennetaan ensin välimuistiin käyttäjäsovelluksella, joka alun perin antoi I/O-kutsun (FUSE), ja toiseksi sdcard-daemonilla (EXT4 FS).

Ongelma 3 - FAT32:n epätäydellinen toteutus

FAT32:ta emuloivan FUSE: n käytöstä aiheutuu kaksi muuta ongelmaa, jotka ovat vähemmän tunnettuja Android-yhteisössä.

Ensimmäinen sisältää virheelliset aikaleimat. Jos olet joskus siirtänyt tiedoston (kuten valokuvan) ja huomannut, että aikaleima on virheellinen, se johtuu Androidin FUSE-toteutuksesta. Tämä ongelma on ollut olemassa vuotta. Tarkemmin sanottuna ongelmaan liittyy utime () järjestelmäkutsu, jonka avulla voit muuttaa tiedoston käyttö- ja muokkausaikaa. Valitettavasti tavallisena käyttäjänä sdcard-daemonille soitetuilla kutsuilla ei ole asianmukaista lupaa suorittaa tätä järjestelmäkutsua. Tähän on olemassa kiertotapoja, mutta ne edellyttävät sinua on pääkäyttäjän oikeudet.

Jos olet joskus siirtänyt tiedoston (kuten valokuvan) ja huomannut, että aikaleima on virheellinen, se johtuu Androidin FUSE-toteutuksesta.

Seuraava ongelma koskee enemmän yrityksiä, jotka käyttävät jotain kuten a smartSD-kortti. Ennen FUSEa sovellusten valmistajat saattoivat valvoa O_DIRECT lippu kommunikoidakseen kortissa olevan mikro-ohjaimen kanssa. FUSE: n avulla kehittäjät voivat käyttää vain tiedoston välimuistiversiota eivätkä näe mikro-ohjaimen lähettämiä komentoja. Tämä on ongelmallista joissakin yritys-/valtio-/pankkisovelluksissa, jotka kommunikoivat lisäarvoa tuottavien microSD-korttien kanssa.

Sulakkeen tyhjennys SDCardFS: lle

Jotkut OEM-valmistajat tunnistivat nämä ongelmat varhain ja alkoivat etsiä ytimen sisäistä ratkaisua FUSE: n korvaamiseksi. Esimerkiksi Samsung kehitti SDCardFS joka perustuu WrapFS: ään. Tämä ytimen sisäinen ratkaisu emuloi FAT32:ta aivan kuten FUSE, mutta ohittaa I/O-yleiskulut, kaksoisvälimuistin ja muut edellä mainitsemani ongelmat. (Kyllä, toistan tämän asian, tämä Googlen nyt toteuttama ratkaisu perustuu Samsungin työhön).

Google itsekin on vihdoin tunnustanut FUSEen liittyvät haitat, minkä vuoksi he ovat alkaneet siirtyä Samsungin kehittämään ytimen sisäiseen FAT32-emulointikerrokseen. Yritys, kuten mainitaan Android-kehittäjien kulissien takana podcast, on työskennellyt saadakseen SDCardFS: n saataville kaikille laitteille ytimen tulevassa versiossa. Tällä hetkellä voit nähdä heidän edistymisensä työskentele AOSP: ssä.

Kuten a Googlen kehittäjä selitti aiemmin, suurin haaste ytimen sisäisen ratkaisun käyttöönotossa on paketin nimen yhdistäminen sovellustunnus, jota paketti tarvitsee käyttääkseen omia tietojaan ulkoisessa tallennustilassa ilman mitään luvat. Mutta tämä lausunto annettiin vuosi sitten, ja olemme saavuttaneet pisteen, jossa tiimi kutsuu SDCardFS: ää "seuraavaksi suureksi asiakseen". He ovat jo vahvistaneet, että pelätty aikaleimavirhe on korjattu FUSE: sta luopumisen ansiosta, joten voimme odottaa innolla näkevämme kaikki muutokset, joita FUSE: n luopuminen tuo mukanaan.

Faktantarkistusvirheitä

Jos olet päässyt näin pitkälle artikkelissa, kiitos, että olet pysynyt mukana kaikessa tähän mennessä! Halusin selventää muutamia kysymyksiä, joita minulla oli itselläni tätä artikkelia kirjoittaessani:

SDCardFS on mitään tekemistä todellisten SD-korttien kanssa. Se on vain nimetty sellaiseksi, koska se käsittelee /sdcardin I/O-käyttöä. Ja kuten ehkä muistat, /sdcard on vanhentunut etiketti, joka viittaa laitteesi "ulkoiseen" tallennustilaan (johon sovellukset tallentavat mediansa).
SDCardFS on ei perinteinen tiedostojärjestelmä kuten FAT32, EXT4 tai F2FS. Se on pinottava kääretiedostojärjestelmä, joka välittää komennot alemmille, emuloiduille tiedostojärjestelmille (tässä tapauksessa se olisi /sdcardin FAT32).
Mikään ei muutu MTP: n suhteen. Jatkat MTP: n käyttöä tiedostojen siirtämiseen tietokoneellesi/tietokoneeltasi (kunnes Google päättää paremman protokollan). Mutta ainakin aikaleimavirhe korjataan!
Kuten aiemmin mainittiin, kun Google viittaa "ulkoiseen tallennustilaan", he joko puhuvat (kaikki aikomukset ja tarkoituksiin) sisäinen /sdcard virtuaalinen FAT32-osio TAI he puhuvat todellisesta, fyysisestä, irrotettavasta microSD-kortista kortti. Terminologia on hämmentävää, mutta se on se, mistä olemme järkyttyneet.

Johtopäätös

Siirtymällä pois FUSE: sta ja ottamalla käyttöön ytimen sisäisen FAT32-emulointikerroksen (SDCardFS), Google vähentää merkittävä I/O-ylirasitus, joka poistaa kaksinkertaisen välimuistin ja ratkaisee joitain epäselviä ongelmia, jotka liittyvät sen FUSE: n emulointiin. FAT32.

Koska nämä muutokset tehdään ytimeen, ne voidaan ottaa käyttöön ilman suurta uutta Android-versiota sen rinnalla. Jotkut käyttäjät odottavat näkevänsä nämä muutokset virallisesti Android 8:ssa, mutta se on mahdollista tulevaa OTA: ta varten Pixel-laitteella tuodakseen Linux-ytimen version 4.1, jota Google on käyttänyt päällä.

Joillekin teistä SDCardFS ei ole uusi käsite. Itse asiassa Samsung-laitteet ovat käyttäneet sitä jo vuosia (he olivat sen kehittäjiä). Siitä lähtien, kun SDCardFS otettiin käyttöön AOSP: ssä viime vuonna, jotkut mukautetun ROM- ja ytimen kehittäjät ovat päättäneet ottaa sen käyttöön työhönsä. CyanogenMOD harkitsi jossain vaiheessa sen käyttöönottoa, mutta peruutti sen, kun käyttäjät kohtasivat ongelmia valokuvissaan. Mutta toivottavasti Googlen hallitsee tätä projektia, Android-käyttäjät kaikissa tulevissa laitteissa voivat hyödyntää FUSE: n hylkäämisen myötä tehtyjä parannuksia.