Детаљно истраживање СДЦардФС, Гоогле-ове замене за ФУСЕ, и начина на који ће његова примена смањити И/О трошкове.
Пре неколико месеци, Гоогле је додао нешто под називом „СДЦардФС” у званичне АОСП гране за Линук кернел. Тада је тај потез приметио само неки програмери кернела, али је иначе пролетео испод радара већине корисника. Није изненађење с обзиром на чињеницу да већина корисника, укључујући мене, заправо не зна шта се дешава испод хаубе Андроид ОС-а и његовог кернела.
Међутим, најновија епизода Андроид Девелоперс Бацкстаге подцаст је обновио интересовање за ову тему. Подцаст, чији је домаћин Цхет Хаасе (виши софтверски инжењер у Гуглу), истраживао је недавне и предстојеће промене у кернелу. У емисији је био програмер Линук кернела који је радио на Андроид тиму - Ром Лемарцханд. Двојац је првенствено разговарао о променама које су направљене да би се прилагодиле А/Б ажурирања, али у последњих 5 минута епизоде господин Лемарцханд је говорио о „следећој великој ствари“ на којој је његов тим радио - СДЦардФС.
Морам признати да сам сазнао за постојање СДЦардФС након слушања овог подкаста. Наравно, нисам био једини који се заинтересовао за ову тему, као недавна Реддит тема је показао. Међутим, нисам био задовољан основним објашњењем које је понуђено у подкасту, и у настојању да одбацим неке од које су се шириле погрешне информације, урадио сам неко сопствено истраживање и разговарао са неколико стручњака са релевантним знањем о материја.
Велико хвала програмеру софтвера Мицхалу Ковалцзику што је допринео својим знањем овом чланку и што је одвојио време да одговори на моја питања.
„Спољно“ је заиста унутрашње
Одмах на почетку, сигурно ће постојати неке заблуде које морамо да разјаснимо - иначе ће остатак чланка бити веома збуњујући. Корисно је разговарати о историји СД картица и Андроид телефона.
У раним данима Андроид телефона, скоро сваки уређај се ослањао на коришћење својих мицроСД картица за складиштење. То је било због чињенице да су се телефони у то време испоручивали са малим капацитетом интерне меморије. Међутим, СД картице које се користе за складиштење апликација често не пружају сјајно корисничко искуство, барем у поређењу са брзином којом интерна флеш меморија може да чита/пише податке. Због тога је све већа употреба СД картица за спољно складиштење података постајала брига за корисничко искуство за Гоогле.
Због раног ширења СД картица као екстерних уређаја за складиштење, Андроид конвенције о именовању складишта заснивале су се на чињеници да сваки уређај има стварни, физички слот за мицроСД картицу. Али чак и на уређајима који нису садржали слот за СД картицу, ознака /сдцард је и даље коришћена да указује на стварни чип интерне меморије. Још више збуњује чињеница да уређаји који користе и физичку СД картицу као и чип за складиштење великог капацитета често називају своје партиције засноване на СД картици. На пример, код ових уређаја тачка монтирања /сдцард односила би се на стварни интерни чип за складиштење, док би се нешто попут /стораге/сдцард1 односило на физичку спољну картицу.
Стога, иако се мицроСД картица практично сматра екстерном меморијом, конвенција о именовању је резултирала тиме да се „СДЦард“ дуго задржала иза било какве стварне употребе физичке картице. Ова конфузија са складиштем је такође задала главобољу програмерима апликација због чињенице да су подаци апликације и њени медији били раздвојени између две партиције.
Мали простор за складиштење раних интерних чипова за складиштење је довео до тога да су корисници фрустрирајуће открили да више не могу да инсталирају апликације (због пуне /дата партиције). У међувремену, њихове мицроСД картице већег капацитета су спуштене само на медије (као што су фотографије, музика и филмови). Корисници који су раније прегледали наше форуме могли би да се сете ових имена: Линк2СД и Аппс2СД. То су била (роот) решења која су корисницима омогућавала да инсталирају своје апликације и податке о њима на физичку СД картицу. Али то су била далеко од савршених решења, па је Гугл морао да се укључи.
Познато је да је Гоогле врло рано укинуо СД картице. Некус Оне остаје једини Некус уређај са утором за мицроСД картицу (и биће заувек пошто је бренд Некус фактички мртав). Са Некус С-ом, сада је постојала само једна, обједињена партиција за складиштење свих података апликације и медија – партиција /дата. Оно што је некада било познато као /сдцард тачка монтирања сада се једноставно односило на виртуелни систем датотека (примењен под ОСИГУРАЧ протокол као што је објашњено у наставку) који се налази на партицији података - /дата/медиа/0.
Да би одржао компатибилност и смањио забуну, Гоогле је и даље користио ову сада виртуелну „сдцард“ партицију за држање медија. Али сада када се ова виртуелна партиција „сдцард“ заправо налази унутар /дата, све што је ускладиштено у њој би се рачунало у складишни простор чипа за интерну меморију. Стога је на ОЕМ-има било да размотре колико простора да доделе апликацијама (/дата) у односу на медије (/дата/медиа).
Гугл се надао да ће произвођачи следити њихов пример и отарасити се СД картица. Срећом, временом су произвођачи телефона били у могућности да набаве ове компоненте већег капацитета, док су остали исплативи, тако да је потреба за СД картицама почела да се смањује. Али конвенције о именовању су опстале како би се смањио напор који би програмери и произвођачи оригиналне опреме морали да уложе да би се прилагодили. Тренутно, када говоримо о „спољној меморији“, мислимо на то било једну од две ствари: стварна преносива мицроСД картица или виртуелна партиција „СДЦард“ која се налази у /дата/медиа. Ово последње, практично говорећи, је заправо интерна меморија, али Гоогле-ова конвенција о именовању га разликује због чињенице да су ови подаци доступни кориснику (на пример када су прикључени на рачунар).
Тренутно, када говоримо о „спољној меморији“, мислимо на то било једну од две ствари: стварна преносива мицроСД картица или виртуелна партиција „СДЦард“ која се налази у /дата/медиа.
Историја Андроид виртуелних система датотека
Сада када се „сдцард“ третира као виртуелни систем датотека, то је значило да се може форматирати као било који систем датотека који Гоогле жели. Почевши од Некус С и Андроид 2.3, Гоогле је одлучио да форматира „сдцард“ као ВФАТ (виртуелни ФАТ). Овај потез је у то време имао смисла, пошто би монтирање ВФАТ-а омогућило скоро сваком рачунару да приступи подацима ускладиштеним на вашем телефону. Међутим, постојала су два велика проблема са овом почетном имплементацијом.
Први се првенствено односи на крајњег корисника (вас). Да бисте повезали свој уређај са рачунаром, користили бисте УСБ Масс Стораге Моде за пренос података. Ово је, међутим, захтевало да Андроид уређај искључи виртуелну партицију пре него што је рачунар могао да приступи подацима. Ако би корисник желео да користи свој уређај док је прикључен, многе ствари би се показале као недоступне.
Тхе увођење Протокола за пренос медија (МТП) решио ово прво питање. Када је прикључен, ваш рачунар види ваш уређај као уређај за „складиштење медија“. Захтева листу датотека са вашег телефона, а МТП враћа листу датотека које рачунар може да преузме са уређаја. Када се захтева брисање датотеке, МТП шаље команду за уклањање захтеване датотеке из складишта. За разлику од УСБ режима масовне меморије који заправо монтира „сдцард“, МТП омогућава кориснику да настави да користи свој уређај док је прикључен. Штавише, систем датотека присутан на Андроид телефону више није битан да би рачунар препознао датотеке на уређају.
Друго, постојала је чињеница да ВФАТ није пружио врсту робусног управљања дозволама које је било потребно Гоогле-у. У почетку би многи програмери апликација третирали „сдцард“ као депонију података својих апликација, без јединственог осећаја где да чувају своје датотеке. Многе апликације би једноставно креирале фасциклу са именом апликације и тамо чувале њене датотеке.
Скоро свака апликација у то време захтевала је ВРИТЕ_ЕКСТЕРНАЛ_СТОРАГЕ дозволу да уписују своје датотеке апликације у спољну меморију. Међутим, оно што је више забрињавало је чињеница да је скоро свака апликација такође захтевала РЕАД_ЕКСТЕРНАЛ_СТОРАГЕ дозволу - само да читају сопствене датотеке са подацима! То је значило да апликације могу лако да имају приступ подацима ускладиштеним било где на спољној меморији, а такву дозволу је корисник често давао јер је била потребна многим апликацијама да се изједначе функција.
Гугл је ово јасно видео као проблематичан. Цела идеја иза управљања дозволама је да се одвоји шта апликације могу, а чему не могу да имају приступ. Ако се скоро свакој апликацији одобри приступ за читање потенцијално осетљивих корисничких података, онда је та дозвола бесмислена. Стога је Гоогле одлучио да им је потребан нови приступ. Ту долази ФУСЕ.
Систем датотека у корисничком простору (ФУСЕ)
Почевши од Андроида 4.4, Гоогле је одлучио да више не монтира виртуелну „сдцард“ партицију као ВФАТ. Уместо тога, Гоогле је почео да користи ФУСЕ за емулацију ФАТ32 на виртуелној партицији „сдцард“. Са позивом програма сдцард ФУСЕ за емулацију дозвола директоријума у стилу ФАТ-он-сдцард, апликације би могле да почну да приступају његовим подацима ускладиштеним на спољној меморији без потребе за икаквим дозволама. Заиста, почевши од АПИ нивоа 19, РЕАД_ЕКСТЕРНАЛ_СТОРАГЕ више није био потребан за приступ датотекама које се налазе на спољној меморији - под условом да фасцикла са подацима коју је креирао ФУСЕ демон одговара имену пакета апликације. ФУСЕ би то урадио синтетизујући власника, групу и режиме датотека на спољној меморији када је апликација инсталирана.
ФУСЕ се разликује од модула у језгру јер омогућава непривилегованим корисницима да пишу виртуелне системе датотека. Разлог зашто је Гоогле имплементирао ФУСЕ је прилично једноставан - урадио је оно што су желели и већ је био добро схваћено и документовано у свету Линук-а. Да цитирам а Гоогле програмер по том питању:
„Пошто је ФУСЕ леп стабилан АПИ, у суштини нема потребе за одржавањем када се крећете између верзија језгра. Ако бисмо мигрирали на решење у језгру, пријавили бисмо се за одржавање скупа закрпа за сваку стабилну верзију кернела.“ -Јефф Схаркеи, софтверски инжењер у Гоогле-у
Међутим, постајало је сасвим јасно да ФУСЕ-ови режијски трошкови представљају хит у перформансама између осталих проблема. Програмер са којим сам разговарао у вези са овим питањем, Мицхал Ковалцзик, написао одличан пост на блогу пре више од годину дана са детаљима о актуелним проблемима са ФУСЕ. Више техничких детаља може се прочитати на његовом блогу, али ја ћу описати његове налазе (уз његову дозволу) лаички.
Проблем са ФУСЕ
У Андроид-у, демон корисничког простора „сдцард“ користи ФУСЕ за монтирање /дев/фусе на емулирани директоријум спољне меморије при покретању. Након тога, сдцард демон прозива ФУСЕ уређај за све поруке на чекању из кернела. Ако сте слушали подкаст, можда сте чули како господин Лемарцханд говори о ФУСЕ-у који уводи прекомерне трошкове током И/О операција – ево шта се у суштини дешава.
У стварном свету, овај хит перформанс утиче било који датотека сачувана на спољној меморији.
Проблем #1 - И/О Оверхеад
Рецимо да креирамо једноставну текстуалну датотеку, названу „тест.ткт“, и складиштимо је у /сдцард/тест.ткт (што, нека подсећам вас, заправо је /дата/медиа/0/тест.ткт под претпоставком да је тренутни корисник примарни корисник на уређај). Ако желимо да прочитамо (командна мачка) ову датотеку, очекивали бисмо да систем изда 3 команде: отвори, прочитај, па затвори. Заиста, као што господин Ковалцзик демонстрира коришћење страце, то се дешава:
Али пошто се датотека налази на спољној меморији којом управља демон сдцард, потребно је извршити много додатних операција. Према г. Ковалчику, у суштини је потребно 8 додатних корака за свака од ове 3 појединачне команде:
- Апликација корисничког простора издаје системски позив којим ће управљати ФУСЕ драјвер у кернелу (видимо га у првом излазу страце)
- ФУСЕ драјвер у кернелу обавештава демон корисничког простора (сдцард) о новом захтеву
- Демон корисничког простора чита /дев/фусе
- Демон корисничког простора анализира команду и препознаје рад са датотекама (нпр. отворен)
- Демон корисничког простора шаље системски позив стварном систему датотека (ЕКСТ4)
- Кернел управља физичким приступом подацима и шаље податке назад у кориснички простор
- Кориснички простор модификује (или не) податке и поново их прослеђује кроз /дев/фусе до кернела
- Кернел завршава оригинални системски позив и премешта податке у стварну апликацију корисничког простора (у нашем примеру мачка)
Ово изгледа као много прекомерних трошкова само на једну И/О команду која треба да се покрене. И био би у праву. Да би то демонстрирао, г. Ковалчик је покушао са два различита И/О теста: један који укључује копирање велике датотеке и други копирање пуно малих датотека. Он је упоредио брзину ФУСЕ (на виртуелној партицији монтираној као ФАТ32) која рукује овим операцијама са кернелу (на партицији података форматираној као ЕКСТ4), и открио је да ФУСЕ заиста значајно доприноси надземне.
У првом тесту је копирао датотеку од 725 МБ под оба услова тестирања. Открио је да имплементација ФУСЕ преноси велике датотеке 17% спорије.
У другом тесту, копирао је 10.000 фајлова - сваки од њих величине 5КБ. У овом сценарију, имплементација ФУСЕ је завршена 40 секунди спорије да копирате у основи 50МБ података.
У стварном свету, овај хит перформанс утиче било који датотека сачувана на спољној меморији. То значи да апликације као што су Мапе које чувају велике датотеке на /сдцард, Музичке апликације које чувају тоне музичких датотека, апликације за камеру и фотографије, итд. На сваку И/О операцију која се изводи и која укључује екстерну меморију утиче ФУСЕ-ово оптерећење. Али улазно/излазни трошкови нису једини проблем са ФУСЕ.
Проблем #2 - Двоструко кеширање
Кеширање података је важно за побољшање перформанси приступа подацима. Чувајући основне делове података у меморији, Линукс језгро може брзо да призове те податке када је то потребно. Али због начина на који је ФУСЕ имплементиран, Андроид складишти дупло већу количину кеша која је потребна.
Као што господин Ковалчик демонстрира, очекује се да ће датотека од 10 МБ бити сачувана у кешу као тачно 10 МБ, али се уместо тога повећава до величине кеша за око 20МБ. Ово је проблематично на уређајима са мање РАМ-а, пошто Линук кернел складишти користи кеш странице за складиштење података у меморија. Г. Ковалцзик је тестирао овај проблем двоструког кеширања користећи овај приступ:
- Направите датотеку познате величине (за тестирање, 10МБ)
- Копирајте га у /сдцард
- Испустите кеш странице
- Направите снимак коришћења кеша странице
- Прочитајте тест фајл
- Направите још један снимак коришћења кеша странице
Оно што је открио је да је пре његовог теста кернел користио 241МБ за кеширање страница. Када је прочитао свој тест фајл, очекивао је да ће видети 251МБ искоришћено за кеш странице. Уместо тога, открио је да то језгро користи 263МБс за кеш странице - о двоструко више од очекиваног. Разлог зашто се то дешава је тај што податке прво кешује корисничка апликација која је првобитно издала И/О позив (ФУСЕ), а затим сдцард демон (ЕКСТ4 ФС).
Проблем #3 - Непотпуна имплементација ФАТ32
Постоје још два проблема која произилазе из употребе ФУСЕ који емулира ФАТ32 који су мање познати у Андроид заједници.
Први укључује нетачне временске ознаке. Ако сте икада пренели датотеку (као што је фотографија) и приметили да је временска ознака нетачна, то је због Андроид имплементације ФУСЕ. Ово питање има постојао за године. Да будемо прецизнији, питање укључује утиме() системски позив који вам омогућава да промените време приступа и модификације датотеке. Нажалост, позиви упућени демону сдцард као стандардни корисник немају одговарајућу дозволу да изврше овај системски позив. Постоје решења за ово, али они захтевају од вас имају роот приступ.
Ако сте икада пренели датотеку (као што је фотографија) и приметили да је временска ознака нетачна, то је због Андроид имплементације ФУСЕ.
Следећи проблем је више забрињавајући за предузећа која користе нешто попут а смартСД картица. Пре ФУСЕ-а, произвођачи апликација су могли да прате О_ДИРЕЦТ заставица у циљу комуникације са уграђеним микроконтролером у картици. Са ФУСЕ, програмери могу приступити само кешираној верзији датотеке и не могу да виде ниједну команду коју шаље микроконтролер. Ово је проблематично за неке пословне/владине/банкарске апликације које комуницирају са мицроСД картицама са додатном вредношћу.
Думпинг ФУСЕ за СДЦардФС
Неки ОЕМС су рано препознали ове проблеме и почели да траже решење у кернелу за замену ФУСЕ. Самсунг је, на пример, развио СДЦардФС који је заснован на ВрапФС. Ово решење у језгру емулира ФАТ32 баш као што то чини ФУСЕ, али се изостављају И/О оверхеад, двоструко кеширање и друге проблеме које сам поменуо горе. (Да, дозволите ми да поновим ту поенту, ово решење које Гоогле сада примењује засновано је на Самсунговом раду).
Сам Гоогле је коначно признао недостатке повезане са ФУСЕ, због чега су почели да се крећу ка слоју емулације ФАТ32 у језгру који је развио Самсунг. Компанија, како је поменуто у Андроид Девелоперс Бацкстаге подцаст, ради на томе да СДЦардФС буде доступан за све уређаје у надолазећој верзији кернела. Тренутно можете видети њихов напредак рад у АОСП.
Као Гоогле програмер је раније објаснио, највећи изазов са имплементацијом решења у језгру је како мапирати име пакета у ИД апликације неопходан да би пакет приступио сопственим подацима у спољној меморији без потребе за тим дозволе. Али та изјава је дата пре годину дана и дошли смо до тачке у којој тим назива СДЦардФС њиховом „следећом великом ствари“. Већ су потврдили да је страшна грешка временске ознаке је поправљено, захваљујући удаљавању од ФУСЕ-а, тако да можемо да се радујемо што ћемо видети све промене које су настале напуштањем ФУСЕ-а.
Заблуде приликом провере чињеница
Ако сте стигли овако далеко у чланак, онда свака част што сте све до сада пратили! Желео сам да разјасним неколико питања која сам себи имао када сам писао овај чланак:
- СДЦардФС има нема везе са стварним СД картицама. Само је тако именован зато што управља И/О приступом за /сдцард. И као што се можда сећате, /сдцард је застарела ознака која се односи на „спољну“ меморију вашег уређаја (где апликације чувају своје медије).
- СДЦардФС је није традиционални систем датотека попут ФАТ32, ЕКСТ4 или Ф2ФС. То је систем датотека са омотачем који се може слагати и који прослеђује команде нижим, емулираним системима датотека (у овом случају, то би био ФАТ32 на /сдцард).
- Ништа се неће променити у односу на МТП. Наставићете да користите МТП за пренос датотека на/са рачунара (све док се Гоогле не определи за бољи протокол). Али ће барем грешка временске ознаке бити исправљена!
- Као што је раније поменуто, када Гугл говори о „спољној меморији“, они или говоре о (за све намере и сврхе) интерна /сдцард виртуелна ФАТ32 партиција ИЛИ говоре о стварној, физичкој, преносивој мицроСД картици картица. Терминологија је збуњујућа, али је оно што нас погађа.
Закључак
Удаљавањем од ФУСЕ и имплементацијом слоја емулације ФАТ32 у језгру (СДЦардФС), Гоогле ће смањити значајне улазно/излазне трошкове, елиминишући двоструко кеширање и решавајући неке нејасне проблеме у вези са емулацијом ФУСЕ-а ФАТ32.
Пошто ће ове промене бити унете у кернел, оне се могу увести без велике нове верзије Андроид-а поред њега. Неки корисници очекују да ће ове промене бити званично имплементиране у Андроид 8, али је могуће за било који будући ОТА на Пикел уређају да донесе Линук кернел верзију 4.1 на којој Гоогле ради на.
За неке од вас, СДЦардФС није нов концепт. У ствари, Самсунг уређаји га користе годинама (они су га ипак развили). Откако је СДЦардФС уведен у АОСП прошле године, неки програмери прилагођених РОМ-а и кернела одлучили су да га имплементирају у свој рад. ЦианогенМОД је у једном тренутку размишљао о његовој имплементацији, али га је вратио када су корисници наишли на проблеме са својим фотографијама. Али надамо се да ће Гоогле преузети контролу над овим пројектом, корисници Андроид-а на свим будућим уређајима могу искористити предности побољшања уведена напуштањем ФУСЕ-а.