Google'ın FUSE'nin yerine geçen SDCardFS'ye ve bunun uygulanmasının G/Ç yükünü nasıl azaltacağına ilişkin derinlemesine bir inceleme.
Birkaç ay önce Google şöyle bir şey ekledi: "SDCardFS”Linux çekirdeğinin resmi AOSP şubelerine. O zamanlar bu hareket yalnızca bazı çekirdek geliştiricileri, ancak bunun dışında çoğu kullanıcının radarının altından geçti. Ben de dahil olmak üzere çoğu kullanıcının Android işletim sistemi ve çekirdeğinin altında neler olup bittiğini gerçekten bilmediği gerçeği göz önüne alındığında bunda sürpriz yok.
Ancak dizinin son bölümü Android Geliştiricileri Sahne Arkası podcast bu konuya olan ilgiyi yeniden canlandırdı. Chet Haase'nin (Google'da kıdemli bir yazılım mühendisi) sunduğu podcast, çekirdeğe yapılan son ve yakında yapılacak değişiklikleri araştırdı. Gösteride Android ekibinde çalışan bir Linux çekirdeği geliştiricisi vardı: Rom Lemarchand. İkili öncelikle A/B güncellemelerine uyum sağlamak için ne gibi değişiklikler yapıldığını tartıştı ancak bölümün son 5 dakikasında Bay Lemarchand ekibinin üzerinde çalıştığı "bir sonraki büyük şey"den bahsetti:
İtiraf etmeliyim ki SDCardFS'nin varlığını bu podcast'i dinledikten sonra öğrendim. Elbette bu konuyla ilgilenen tek kişi ben değildim. son Reddit konusu gösterdi. Ancak podcast'te sunulan temel açıklamadan memnun değildim ve bazı açıklamaları ortadan kaldırma çabası içindeydim. Ortalıkta yanlış bilgiler yayıldığından, ben de biraz araştırma yaptım ve konuyla ilgili bilgisi olan birkaç uzmanla konuştum. konu.
Yazılım geliştiricisi Michal Kowalczyk'e bilgi birikimiyle bu makaleye katkıda bulunduğu ve sorularımı yanıtlamaya zaman ayırdığı için çok teşekkür ederim.
"Dışsal" Gerçekten İçseldir
En başından itibaren düzeltmemiz gereken bazı yanlış anlamalar mutlaka olacaktır, aksi takdirde makalenin geri kalanı oldukça kafa karıştırıcı olacaktır. SD kartların ve Android telefonların geçmişini tartışmak faydalı olacaktır.
Android telefonların ilk günlerinde neredeyse her cihaz depolama için microSD kartlarını kullanıyordu. Bunun nedeni, o dönemde telefonların çok küçük dahili depolama kapasiteleriyle gönderilmesiydi. Ancak uygulamaları depolamak için kullanılan SD kartlar, en azından dahili flash belleğin veri okuma/yazma hızıyla karşılaştırıldığında çoğu zaman mükemmel bir kullanıcı deneyimi sağlamaz. Bu nedenle, harici veri depolama için SD Kartların artan kullanımı Google için bir kullanıcı deneyimi endişesi haline geliyordu.
SD kartların harici depolama cihazları olarak erken dönemde yaygınlaşması nedeniyle, Android'in depolama adlandırma kuralları, her cihazın gerçek, fiziksel bir microSD kart yuvasına sahip olduğu gerçeğine dayanıyordu. Ancak SD Kart yuvası içermeyen cihazlarda bile, /sdcard etiketi hala gerçek dahili depolama yongasını işaret etmek için kullanılıyordu. Daha da kafa karıştırıcı olan şey, depolama için hem fiziksel bir SD kartı hem de yüksek kapasiteli bir depolama yongasını kullanan cihazların, bölümlerini genellikle SD Kartı temel alarak adlandırmasıdır. Örneğin, bu cihazlarda /sdcard bağlama noktası gerçek dahili depolama yongasını belirtirken, /storage/sdcard1 gibi bir şey fiziksel harici kartı ifade eder.
Bu nedenle, microSD kart pratikte harici depolama olarak kabul edilse de, adlandırma kuralı, "SDCard"ın fiziksel bir kartın fiili kullanımından çok daha uzun süre önce ortalıkta kalmasına neden oldu. Depolamayla ilgili bu karışıklık, uygulama verilerinin ve medyasının iki bölüm arasında ayrılmış olması nedeniyle uygulama geliştiricilerine de bazı baş ağrıları yaşattı.
İlk dahili depolama yongalarının düşük depolama alanı, kullanıcıların artık uygulama yükleyemeyeceklerini sinir bozucu bir şekilde öğrenmelerine neden oldu (/data bölümünün dolu olması nedeniyle). Bu arada, daha büyük kapasiteli microSD kartları yalnızca medyayı (fotoğraf, müzik ve filmler gibi) tutmaya bırakıldı. Eskiden forumlarımıza göz atan kullanıcılar şu isimleri hatırlayabilir: Link2SD ve Apps2SD. Bunlar, kullanıcıların uygulamalarını ve verilerini tamamen fiziksel SD karta yüklemelerine olanak tanıyan (kök) çözümlerdi. Ancak bunlar mükemmel çözümlerden uzaktı, bu nedenle Google'ın devreye girmesi gerekiyordu.
Google'ın SD kartların fişini çok erken çektiğini biliyoruz. Nexus One, microSD kart yuvasına sahip tek Nexus cihazı olmaya devam ediyor (ve Nexus markası fiilen öldüğü için sonsuza kadar da öyle kalacak). Nexus S ile artık tüm uygulama verilerini ve medyayı depolamak için tek bir birleşik bölüm vardı: /data bölümü. Bir zamanlar /sdcard bağlama noktası olarak bilinen şey artık yalnızca sanal bir dosya sistemine atıfta bulunuyordu ( SİGORTA aşağıda tartışıldığı gibi protokol) veri bölümünde bulunur - /data/media/0.
Uyumluluğu korumak ve kafa karışıklığını azaltmak için Google, medyayı tutmak için artık sanal olan bu "sdcard" bölümünü kullanmaya devam etti. Ancak artık bu "sdcard" sanal bölümü aslında /data içinde yer aldığından, içinde depolanan her şey dahili depolama yongasının depolama alanı kapsamında sayılacaktır. Bu nedenle, uygulamalara (/data) ve medyaya (/data/media) ne kadar alan ayrılacağını düşünmek OEM'lere kalmıştı.
Google, üreticilerin kendi örneklerini takip etmelerini ve SD kartlardan kurtulmalarını umuyordu. Neyse ki, zaman içinde telefon üreticileri bu bileşenleri daha yüksek kapasitelerde tedarik ederken aynı zamanda uygun maliyetli kalmayı başardılar, dolayısıyla SD kartlara olan ihtiyaç azalmaya başladı. Ancak adlandırma kuralları, geliştiricilerin ve OEM'lerin uyum sağlamak için göstermeleri gereken çaba miktarını azaltmak amacıyla varlığını sürdürdü. Şu anda “harici depolama” derken kast ettiğimiz şey iki şeyden biri: /data/media'da bulunan gerçek çıkarılabilir microSD kart veya sanal "SDCard" bölümü. Bunlardan ikincisi, pratik olarak konuşursak, aslında dahili depolamadır, ancak Google'ın adlandırma kuralı, bu verilere kullanıcının erişebilmesi (örneğin bilgisayara takıldığında) nedeniyle bunu farklılaştırıyor.
Şu anda “harici depolama” derken kast ettiğimiz şey iki şeyden biri: /data/media'da bulunan gerçek çıkarılabilir microSD kart veya sanal "SDCard" bölümü.
Android'in Sanal Dosya Sistemlerinin Tarihi
Artık "sdcard" sanal bir dosya sistemi olarak değerlendiriliyor; bu, Google'ın istediği herhangi bir dosya sistemi olarak biçimlendirilebileceği anlamına geliyordu. Nexus S ve Android 2.3'ten başlayarak Google, "sdcard"ı VFAT (sanal FAT) olarak biçimlendirmeyi seçti. Bu hamle o zamanlar mantıklıydı çünkü VFAT'nin takılması neredeyse her bilgisayarın telefonunuzda depolanan verilere erişmesine olanak tanıyacaktı. Ancak bu ilk uygulamada iki önemli sorun vardı.
Birincisi öncelikle son kullanıcıyı (sizi) ilgilendiriyor. Cihazınızı bilgisayarınıza bağlamak için veri aktarımı amacıyla USB Yığın Depolama Modunu kullanıyor olacaksınız. Ancak bu, bilgisayarın verilere erişebilmesi için Android cihazının sanal bölümün bağlantısını kesmesini gerektiriyordu. Bir kullanıcı cihazını fişe takılıyken kullanmak isterse birçok şey kullanılamıyor olarak görünürdü.
Medya Aktarım Protokolünün tanıtımı (MTP) bu ilk sorunu çözdü. Bilgisayarınız prize takıldığında cihazınızı bir “medya depolama” cihazı olarak görür. Telefonunuzdan bir dosya listesi ister ve MTP, bilgisayarın cihazdan indirebileceği dosyaların bir listesini döndürür. Bir dosyanın silinmesi istendiğinde MTP, istenen dosyayı depodan kaldırmak için bir komut gönderir. Aslında "sdcard"ı takan USB Yığın Depolama Modundan farklı olarak MTP, kullanıcının cihazını takılıyken kullanmaya devam etmesine olanak tanır. Ayrıca, Android telefonda bulunan dosya sisteminin artık bilgisayarın cihazdaki dosyaları tanıması açısından bir önemi yoktur.
İkincisi, VFAT'ın Google'ın ihtiyaç duyduğu türden sağlam izin yönetimini sağlamadığı gerçeği vardı. Başlangıçta pek çok uygulama geliştiricisi, dosyalarının nerede saklanacağına dair birleşik bir anlayışa sahip olmadan, "sdcard"ı uygulamalarının verileri için bir çöplük alanı olarak görüyordu. Çoğu uygulama, uygulama adını içeren bir klasör oluşturur ve dosyalarını orada saklar.
O dönemde neredeyse her uygulama, WRITE_EXTERNAL_STORAGE uygulama dosyalarını harici depolama birimine yazma izni. Ancak daha da rahatsız edici olan şey, hemen hemen her uygulamanın aynı zamanda bu belgeyi de gerektirmesiydi. READ_EXTERNAL_STORAGE izin - sadece kendi veri dosyalarını okumak için! Bu, uygulamaların harici depolamanın herhangi bir yerinde depolanan verilere kolayca erişebileceği anlamına geliyordu. ve böyle bir izin çoğu zaman kullanıcı tarafından veriliyordu çünkü birçok uygulamanın bunu yapması bile gerekiyordu. işlev.
Google bunu açıkça sorunlu olarak gördü. İzin yönetiminin ardındaki fikir, uygulamaların erişebileceği ve erişemeyeceği şeyleri ayırmaktır. Neredeyse her uygulamaya potansiyel olarak hassas kullanıcı verilerine okuma erişimi veriliyorsa bu iznin hiçbir anlamı yoktur. Bu nedenle Google yeni bir yaklaşıma ihtiyaç duyduğuna karar verdi. FUSE'nin devreye girdiği yer burasıdır.
Kullanıcı Alanındaki Dosya Sistemi (FUSE)
Android 4.4'ten başlayarak Google, sanal "sdcard" bölümünü artık VFAT olarak bağlamamaya karar verdi. Bunun yerine Google, "sdcard" sanal bölümünde FAT32'yi taklit etmek için FUSE'yi kullanmaya başladı. Sdcard programı çağrılırken SD kartta FAT tarzı dizin izinlerini taklit etmek için FUSEuygulamalar harici depolama biriminde depolanan verilere erişmeye başlayabilir herhangi bir izin gerektirmeden. Aslında, API Düzeyi 19'dan başlayarak, artık konumdaki dosyalara erişmek için READ_EXTERNAL_STORAGE gerekli değildi. harici depolamada - FUSE arka plan programı tarafından oluşturulan veri klasörünün uygulamanın paket adıyla eşleşmesi şartıyla. FUSE halleder harici depolamadaki dosyaların sahibini, grubunu ve modlarını sentezleme bir uygulama yüklendiğinde.
FUSE, ayrıcalıklı olmayan kullanıcıların sanal dosya sistemleri yazmasına izin vermesi nedeniyle çekirdek içi modüllerden farklıdır. Google'ın FUSE'ı uygulamasının nedeni oldukça basit: onların istediklerini yaptı ve zaten yapıldı. iyi anlaşılmış ve belgelenmiş Linux dünyasında. Bir alıntı yapmak için Konuyla ilgili Google geliştiricisi:
"FUSE güzel ve kararlı bir API olduğundan, çekirdek sürümleri arasında geçiş yaparken aslında sıfır bakım çalışması gerekiyor. Çekirdek içi bir çözüme geçiş yapsaydık, her kararlı çekirdek sürümü için bir dizi yama bulundurmak üzere kaydolmuş olurduk." -Jeff Sharkey, Google Yazılım Mühendisi
Ancak FUSE'nin genel giderlerinin diğer sorunların yanı sıra performansta da bir darbeye yol açtığı açıkça görülüyordu. Bu konuyla ilgili konuştuğum geliştirici Michal Kowalczyk, mükemmel bir blog yazısı kaleme aldı bir yıldan fazla bir süre önce FUSE ile ilgili güncel sorunları ayrıntılarıyla anlatıyordum. Daha fazla teknik ayrıntı onun blogunda okunabilir, ancak bulgularını (onun izniyle) daha sıradan birinin terimleriyle anlatacağım.
SİGORTA Sorunu
Android'de, "sdcard" kullanıcı alanı arka plan programı, önyükleme sırasında /dev/fuse'u öykünülmüş harici depolama dizinine bağlamak için FUSE'yi kullanır. Bundan sonra, sdcard arka plan programı, çekirdekten gelen bekleyen mesajlar için FUSE cihazını yoklar. Podcast'i dinlediyseniz, Bay Lemarchand'ın FUSE'ın I/O işlemleri sırasında ek yük getirdiğinden bahsettiğini duymuş olabilirsiniz - esas olarak olan budur.
Gerçek dünyada, bu performans isabeti şunları etkiler: herhangi harici depolama biriminde saklanan dosya.
Sorun #1 - G/Ç Ek Yükü
Diyelim ki “test.txt” adında basit bir metin dosyası oluşturduğumuzu ve bunu /sdcard/test.txt dosyasında sakladığımızı varsayalım (ki bu da izin verir) Size şunu hatırlatayım, aslında /data/media/0/test.txt geçerli kullanıcının birincil kullanıcı olduğunu varsayar. cihaz). Bu dosyayı okumak isteseydik (cat komutu), sistemin 3 komut vermesini beklerdik: aç, oku, sonra kapat. Gerçekten de Bay Kowalczyk'in şunu kullanarak gösterdiği gibi: strace, şöyle oluyor:
Ancak dosya, sdcard arka plan programı tarafından yönetilen harici depolama alanında bulunduğundan, gerçekleştirilmesi gereken birçok ek işlem vardır. Bay Kowalczyk'e göre esas olarak 8 ek adım daha gerekiyor bu 3 ayrı komutun her biri:
- Kullanıcı alanı uygulaması, çekirdekteki FUSE sürücüsü tarafından ele alınacak sistem çağrısını yayınlıyor (bunu ilk strace çıktısında görüyoruz)
- Çekirdekteki FUSE sürücüsü, kullanıcı alanı arka plan programını (sdcard) yeni istek hakkında bilgilendirir
- Kullanıcı alanı arka plan programı /dev/fuse okur
- Kullanıcı alanı arka plan programı komutu ayrıştırır ve dosya işlemini tanır (örn. açık)
- Kullanıcı alanı arka plan programı, gerçek dosya sistemine (EXT4) sistem çağrısı yapar
- Çekirdek, fiziksel veri erişimini yönetir ve verileri kullanıcı alanına geri gönderir
- Kullanıcı alanı verileri değiştirir (ya da değiştirmez) ve /dev/fuse aracılığıyla tekrar çekirdeğe iletir
- Çekirdek, orijinal sistem çağrısını tamamlar ve verileri gerçek kullanıcı alanı uygulamasına taşır (örnek kedimizde)
Bu gibi görünüyor çok fazla çalıştırılacak tek bir G/Ç komutuna ek yük. Ve haklı olurdun. Bunu göstermek için Bay Kowalczyk iki farklı I/O testi denedi: biri büyük bir dosyayı kopyalamayı, diğeri ise çok sayıda küçük dosyayı kopyalamayı içeriyordu. Bu işlemleri gerçekleştiren FUSE'nin (FAT32 olarak monte edilmiş sanal bölümdeki) hızını, çekirdek (EXT4 olarak biçimlendirilmiş veri bölümünde) ve FUSE'ın gerçekten önemli katkıda bulunduğunu buldu. yükü.
İlk testte her iki test koşulunda da 725 MB'lık bir dosyayı kopyaladı. FUSE uygulamasının büyük dosyaları aktardığını buldu %17 daha yavaş.
İkinci testte, her biri 5 KB boyutunda olan 10.000 dosyayı kopyaladı. Bu senaryoda FUSE uygulaması sona erdi 40 saniye daha yavaş Temel olarak 50 MB değerinde veriyi kopyalamak için.
Gerçek dünyada, bu performans isabeti şunları etkiler: herhangi harici depolama biriminde saklanan dosya. Bu, /sdcard üzerinde büyük dosyalar depolayan Haritalar, tonlarca müzik dosyası depolayan Müzik uygulamaları, Kamera uygulamaları ve fotoğraflar vb. uygulamalar anlamına gelir. Harici depolamayı içeren herhangi bir G/Ç işlemi FUSE'nin ek yükünden etkilenir. Ancak FUSE ile ilgili tek sorun G/Ç yükü değildir.
Sorun #2 - Çift Önbelleğe Alma
Verilerin önbelleğe alınması, veri erişim performansının iyileştirilmesi açısından önemlidir. Linux çekirdeği, önemli veri parçalarını bellekte depolayarak gerektiğinde bu verileri hızlı bir şekilde geri çağırabilir. Ancak FUSE'un uygulanma şekli nedeniyle, Android depoları gereken önbellek miktarını iki katına çıkarır.
Bay Kowalczyk'in gösterdiği gibi, 10 MB'lık bir dosyanın önbelleğe tam olarak 10 MB olarak kaydedilmesi, bunun yerine önbellek boyutuna yükseltilmesi bekleniyor yaklaşık 20 MB. Linux çekirdek depoları verileri depolamak için sayfa önbelleğini kullandığından, bu daha az RAM'e sahip cihazlarda sorunludur. hafıza. Bay Kowalczyk bu çift önbellekleme sorununu şu yaklaşımı kullanarak test etti:
- Bilinen boyutta bir dosya oluşturun (test için, 10 MB)
- /sdcard'a kopyalayın
- Sayfa önbelleğini bırakın
- Sayfa önbelleği kullanımının anlık görüntüsünü alın
- Test dosyasını okuyun
- Sayfa önbelleği kullanımının başka bir anlık görüntüsünü alın
Testinden önce çekirdek tarafından sayfa önbelleği için 241 MB'ın kullanıldığı görüldü. Test dosyasını okuduğunda sayfa önbelleği için 251 MB'ın kullanıldığını görmeyi bekliyordu. Bunun yerine, çekirdeğin kullandığını buldu. 263 MB sayfa önbelleği için - hakkında beklenenin iki katı. Bunun oluşmasının nedeni, verilerin ilk olarak G/Ç çağrısını (FUSE) yayınlayan kullanıcı uygulaması tarafından ve ikinci olarak sdcard arka plan programı (EXT4 FS) tarafından önbelleğe alınmasıdır.
Sorun #3 - FAT32'nin Eksik Uygulanması
FUSE'nin FAT32'yi taklit etmesinden kaynaklanan ve Android topluluğunda daha az bilinen iki sorun daha var.
İlki şunları içerir yanlış zaman damgaları. Bir dosyayı (fotoğraf gibi) aktardıysanız ve zaman damgasının yanlış olduğunu fark ettiyseniz bunun nedeni Android'in FUSE uygulamasıdır. Bu sorun var için vardı yıllar. Daha spesifik olmak gerekirse, konu şunları içerir: kullanım zamanı() Bir dosyanın erişim ve değişiklik zamanını değiştirmenizi sağlayan sistem çağrısı. Ne yazık ki, standart kullanıcı olarak sdcard arka plan programına yapılan çağrılar, bu sistem çağrısını yürütmek için uygun izne sahip değildir. Bunun için geçici çözümler var, ancak bunları yapmanızı gerektiriyor kök erişimine sahip olmak.
Bir dosyayı (fotoğraf gibi) aktardıysanız ve zaman damgasının yanlış olduğunu fark ettiyseniz bunun nedeni Android'in FUSE uygulamasıdır.
Bir sonraki sorun, daha çok böyle bir şey kullanan işletmeler için endişe vericidir. akıllı SD kart. FUSE'den önce uygulama geliştiricileri şunları izleyebiliyordu: O_DIRECT bayrağı Karttaki gömülü mikrodenetleyici ile iletişim kurmak için. FUSE ile geliştiriciler bir dosyanın yalnızca önbelleğe alınmış sürümüne erişebilir ve mikro denetleyici tarafından gönderilen komutları göremez. Bu, katma değerli microSD kartlarla iletişim kuran bazı kurumsal/kamu/bankacılık uygulamaları için sorunludur.
SDCardFS için FUSE'yi Atma
Bazı OEM'ler bu sorunları erkenden fark etti ve FUSE'ın yerini alacak çekirdek içi bir çözüm aramaya başladı. Örneğin Samsung geliştirdi SDCardFS WrapFS'yi temel alır. Bu çekirdek içi çözüm, tıpkı FUSE'nin yaptığı gibi FAT32'yi taklit eder, ancak G/Ç yükünden, çift önbelleğe almadan ve yukarıda bahsettiğim diğer sorunlardan vazgeçer. (Evet, bu noktayı tekrarlamama izin verin, Google'ın şu anda uyguladığı bu çözüm Samsung'un çalışmalarına dayanıyor).
Google nihayet FUSE ile ilgili dezavantajları kabul etti ve bu nedenle Samsung tarafından geliştirilen çekirdek içi FAT32 emülasyon katmanına doğru ilerlemeye başladılar. Şirket, açıklamada belirtildiği gibi Android Geliştiricileri Sahne Arkası podcast, çekirdeğin gelecek sürümünde SDCardFS'yi tüm cihazlar için kullanılabilir hale getirmek için çalışıyor. Şu anda ilerlemelerini görebilirsiniz AOSP'ta çalışıyor.
Olarak Google geliştiricisi daha önce açıkladıçekirdek içi bir çözümün uygulanmasındaki en büyük zorluk, paket adının nasıl eşleneceğidir. Bir paketin harici depolamadaki kendi verilerine herhangi bir gereksinim duymadan erişmesi için gerekli uygulama kimliği izinler. Ancak bu açıklama bir yıl önce yapıldı ve ekibin SDCardFS'yi "bir sonraki büyük şey" olarak adlandırdığı noktaya ulaştık. Zaten bunu doğruladılar korkunç zaman damgası hatası FUSE'den uzaklaşmamız sayesinde düzeltildi, dolayısıyla FUSE'ın terk edilmesiyle ortaya çıkan tüm değişiklikleri görmeyi sabırsızlıkla bekleyebiliriz.
Doğruluk Kontrolü Yanılgıları
Makalenin bu kadar ilerisine ulaştıysanız, şu ana kadar her şeyi takip ettiğiniz için teşekkür ederiz! Bu yazıyı yazarken kafama takılan birkaç soruyu açıklığa kavuşturmak istedim:
- SDCardFS'nin sahip olduğu gerçek SD Kartlarla ilgisi yok. /sdcard için G/Ç erişimini yönettiği için bu şekilde adlandırılmıştır. Hatırlayacağınız gibi /sdcard, cihazınızın "harici" deposuna (uygulamaların medyalarını depoladığı yer) atıfta bulunan eski bir etikettir.
- SDCardFS: geleneksel bir dosya sistemi değil FAT32, EXT4 veya F2FS gibi. Komutları daha düşük, öykünülmüş dosya sistemlerine ileten istiflenebilir bir sarmalayıcı dosya sistemidir (bu durumda, /sdcard'da FAT32 olacaktır).
- MTP açısından hiçbir şey değişmeyecek. Bilgisayarınıza/bilgisayarınızdan dosya aktarmak için MTP'yi kullanmaya devam edeceksiniz (Google daha iyi bir protokole karar verene kadar). Ama en azından zaman damgası hatası düzeltilecek!
- Daha önce de belirtildiği gibi, Google "Harici Depolama"dan bahsettiğinde ya (tüm amaçlar için) amaçları) dahili /sdcard sanal FAT32 bölümünden VEYA gerçek, fiziksel, çıkarılabilir bir microSD'den bahsediyorlar kart. Terminoloji kafa karıştırıcı ama asıl dikkatimizi çeken şey bu.
Çözüm
Google, FUSE'den uzaklaşarak ve çekirdek içi FAT32 emülasyon katmanını (SDCardFS) uygulayarak, önemli miktarda G/Ç ek yükü, çift önbelleğe almayı ortadan kaldırır ve FUSE'nin emülasyonuyla ilgili bazı belirsiz sorunları çözer. FAT32.
Bu değişiklikler çekirdeğe yapılacağından, Android'in yeni ve büyük bir sürümü olmadan da kullanıma sunulabilir. Bazı kullanıcılar bu değişikliklerin resmi olarak Android 8'de uygulanmasını bekliyor ancak bu mümkün Google'ın çalışmakta olduğu Linux çekirdeği 4.1 sürümünü getirmek için gelecekteki herhangi bir OTA'nın Pixel cihazına getirilmesi için Açık.
Bazılarınız için SDCardFS yeni bir kavram değil. Aslında Samsung cihazları bunu yıllardır kullanıyor (sonuçta onu geliştiren de onlardı). SDCardFS'nin geçen yıl AOSP'de tanıtılmasından bu yana, bazı özel ROM ve çekirdek geliştiricileri bunu çalışmalarında uygulamayı seçtiler. CyanogenMOD bir noktada bunu uygulamayı düşündü ancak kullanıcılar fotoğraflarıyla ilgili sorunlarla karşılaştığında bunu geri aldı. Ancak Google'ın bu projede kontrolü ele almasıyla, gelecekteki tüm cihazlardaki Android kullanıcılarının FUSE'den vazgeçilmesiyle ortaya çıkan iyileştirmelerden yararlanabileceğini umuyoruz.