Eksplorasi mendalam tentang SDCardFS, pengganti FUSE Google, dan bagaimana penerapannya akan mengurangi overhead I/O.
Beberapa bulan lalu, Google menambahkan sesuatu yang disebut “Kartu SDFS” ke cabang AOSP resmi untuk kernel Linux. Pada saat itu, perpindahan tersebut hanya diketahui oleh beberapa pengembang kernel, tetapi sebaliknya tidak terdeteksi oleh sebagian besar pengguna. Tidak mengherankan mengingat fakta bahwa sebagian besar pengguna, termasuk saya, tidak begitu tahu apa yang terjadi di balik OS Android dan kernelnya.
Namun, episode terbaru dari Pengembang Android di Belakang Panggung podcast memperbarui minat pada topik ini. Podcast, yang dibawakan oleh Chet Haase (insinyur perangkat lunak senior di Google), mengeksplorasi perubahan terkini dan mendatang yang dilakukan pada kernel. Di acara itu ada pengembang kernel Linux yang bekerja di tim Android - Rom Lemarchand. Duo ini terutama membahas perubahan apa yang dilakukan untuk mengakomodasi pembaruan A/B, namun dalam 5 menit terakhir episode tersebut, Pak Lemarchand berbicara tentang “hal besar berikutnya” yang sedang dikerjakan timnya -
Harus saya akui bahwa saya mengetahui keberadaan SDCardFS setelah mendengarkan podcast ini. Tentu saja, saya bukan satu-satunya yang tertarik dengan topik ini, karena a utas Reddit terbaru telah menunjukan. Namun, saya kurang puas dengan penjelasan dasar yang ditawarkan di podcast, dan dalam upaya menghilangkan beberapa penjelasan tersebut. informasi yang salah tersebar, saya melakukan penelitian sendiri dan berbicara dengan beberapa pakar yang memiliki pengetahuan relevan mengenai hal tersebut urusan.
Terima kasih banyak kepada pengembang perangkat lunak Michal Kowalczyk karena telah menyumbangkan pengetahuannya untuk artikel ini dan meluangkan waktu untuk menjawab pertanyaan saya.
"Eksternal" Sebenarnya Internal
Langsung saja, pasti ada beberapa kesalahpahaman yang harus kita luruskan - jika tidak, sisa artikel ini akan sangat membingungkan. Sangat membantu untuk membahas sejarah kartu SD dan ponsel Android.
Pada masa-masa awal ponsel Android, hampir setiap perangkat mengandalkan penggunaan kartu microSD untuk penyimpanan. Hal ini disebabkan oleh fakta bahwa ponsel pada saat itu dikirimkan dengan kapasitas penyimpanan internal yang sangat kecil. Namun, kartu SD yang digunakan untuk menyimpan aplikasi seringkali tidak memberikan pengalaman pengguna yang luar biasa, setidaknya dibandingkan dengan kecepatan memori flash internal dalam membaca/menulis data. Oleh karena itu, meningkatnya penggunaan Kartu SD untuk penyimpanan data eksternal menjadi perhatian Google terhadap pengalaman pengguna.
Karena proliferasi awal kartu SD sebagai perangkat penyimpanan eksternal, konvensi penamaan penyimpanan Android didasarkan pada fakta bahwa setiap perangkat memiliki slot kartu microSD fisik yang sebenarnya. Namun bahkan pada perangkat yang tidak memiliki slot Kartu SD, label /sdcard masih digunakan untuk menunjuk ke chip penyimpanan internal sebenarnya. Yang lebih membingungkan adalah kenyataan bahwa perangkat yang menggunakan kartu SD fisik serta chip penyimpanan berkapasitas tinggi untuk penyimpanan sering kali menamai partisinya berdasarkan Kartu SD. Misalnya, pada perangkat ini, titik pemasangan /sdcard akan mengacu pada chip penyimpanan internal sebenarnya, sedangkan /storage/sdcard1 akan merujuk pada kartu eksternal fisik.
Oleh karena itu, meskipun kartu microSD secara praktis dianggap sebagai penyimpanan eksternal, konvensi penamaan tersebut mengakibatkan “SDCard” bertahan lama melampaui penggunaan kartu fisik yang sebenarnya. Kebingungan dengan penyimpanan ini juga membuat pengembang aplikasi pusing karena fakta bahwa data aplikasi dan medianya dipisahkan di antara dua partisi.
Rendahnya ruang penyimpanan pada chip penyimpanan internal awal mengakibatkan pengguna merasa frustrasi saat mengetahui bahwa mereka tidak dapat lagi menginstal aplikasi (karena partisi /data sudah penuh). Sementara itu, kartu microSD berkapasitas lebih besar hanya digunakan untuk menampung media (seperti foto, musik, dan film). Pengguna yang menelusuri forum kami mungkin ingat nama-nama ini: Link2SD dan Apps2SD. Ini adalah solusi (root) yang memungkinkan pengguna menginstal aplikasi mereka dan semua datanya di kartu SD fisik. Namun hal ini masih jauh dari solusi sempurna, sehingga Google harus turun tangan.
Yang terkenal, Google mencabut kartu SD sejak dini. Nexus One tetap menjadi satu-satunya perangkat Nexus dengan slot kartu microSD (dan akan selamanya demikian karena merek Nexus sudah mati). Dengan Nexus S, kini hanya ada satu partisi terpadu untuk menyimpan semua data aplikasi dan media - partisi /data. Apa yang dulunya dikenal sebagai titik pemasangan /sdcard sekarang hanya mengacu pada sistem file virtual (diimplementasikan di bawah file SEKERING protokol seperti dibahas di bawah) terletak di partisi data - /data/media/0.
Untuk menjaga kompatibilitas dan mengurangi kebingungan, Google masih menggunakan partisi “sdcard” yang sekarang virtual ini untuk menampung media. Tapi sekarang partisi virtual “sdcard” ini sebenarnya terletak di dalam /data, apa pun yang disimpan di dalamnya akan mengurangi ruang penyimpanan chip penyimpanan internal. Oleh karena itu, OEM harus mempertimbangkan berapa banyak ruang yang akan dialokasikan untuk aplikasi (/data) versus media (/data/media).
Google berharap produsen dapat mengikuti contoh mereka dan membuang kartu SD. Untungnya, seiring berjalannya waktu, produsen ponsel dapat menyediakan komponen-komponen ini dengan kapasitas yang lebih tinggi namun tetap hemat biaya, sehingga kebutuhan akan kartu SD mulai berkurang. Namun konvensi penamaan tetap ada untuk mengurangi jumlah upaya yang harus dilakukan pengembang dan OEM untuk melakukan penyesuaian. Saat ini, yang kami maksud adalah “penyimpanan eksternal”. salah satu dari dua hal: kartu microSD sebenarnya yang dapat dilepas atau partisi “SDCard” virtual yang terletak di /data/media. Yang terakhir ini, secara praktis, sebenarnya adalah penyimpanan internal, namun konvensi penamaan Google membedakannya karena fakta bahwa data ini dapat diakses oleh pengguna (seperti saat dicolokkan ke komputer).
Saat ini, yang kami maksud adalah “penyimpanan eksternal”. salah satu dari dua hal: kartu microSD sebenarnya yang dapat dilepas atau partisi “SDCard” virtual yang terletak di /data/media.
Sejarah Sistem File Virtual Android
Sekarang “sdcard” diperlakukan sebagai sistem file virtual, artinya dapat diformat sebagai sistem file apa pun yang diinginkan Google. Dimulai dengan Nexus S dan Android 2.3, Google memilih untuk memformat “sdcard” sebagai VFAT (virtual FAT). Langkah ini masuk akal pada saat itu, karena pemasangan VFAT akan memungkinkan hampir semua komputer mengakses data yang tersimpan di ponsel Anda. Namun, ada dua masalah besar dalam penerapan awal ini.
Yang pertama terutama menyangkut pengguna akhir (Anda). Untuk menghubungkan perangkat Anda ke komputer, Anda akan menggunakan Mode Penyimpanan Massal USB untuk mentransfer data. Namun, hal ini mengharuskan perangkat Android untuk meng-unmount partisi virtual sebelum komputer dapat mengakses data. Jika pengguna ingin menggunakan perangkatnya saat tersambung ke sumber listrik, banyak hal yang akan ditampilkan sebagai tidak tersedia.
Itu pengenalan Protokol Transfer Media (MTP) memecahkan masalah pertama ini. Saat dicolokkan, komputer Anda melihat perangkat Anda sebagai perangkat “penyimpanan media”. Ia meminta daftar file dari ponsel Anda, dan MTP mengembalikan daftar file yang dapat diunduh komputer dari perangkat. Ketika file diminta untuk dihapus, MTP mengirimkan perintah untuk menghapus file yang diminta dari penyimpanan. Tidak seperti Mode Penyimpanan Massal USB yang benar-benar memasang “sdcard”, MTP memungkinkan pengguna untuk terus menggunakan perangkat mereka saat tersambung. Selain itu, sistem file yang ada di ponsel Android tidak lagi menjadi masalah bagi komputer untuk mengenali file di perangkat.
Kedua, terdapat fakta bahwa VFAT tidak memberikan manajemen izin yang kuat seperti yang dibutuhkan Google. Pada awalnya, banyak pengembang aplikasi akan memperlakukan “sdcard” sebagai tempat pembuangan data aplikasi mereka, tanpa adanya kesatuan tempat untuk menyimpan file mereka. Banyak aplikasi hanya membuat folder dengan nama aplikasinya dan menyimpan filenya di sana.
Hampir setiap aplikasi di luar sana pada saat itu memerlukan TULIS_EXTERNAL_STORAGE izin untuk menulis file aplikasi mereka ke penyimpanan eksternal. Namun, yang lebih meresahkan adalah kenyataan bahwa hampir setiap aplikasi juga memerlukannya BACA_EXTERNAL_STORAGE izin - hanya untuk membaca file data mereka sendiri! Ini berarti aplikasi dapat dengan mudah mengakses data yang disimpan di mana saja di penyimpanan eksternal, dan izin seperti itu sering kali diberikan oleh pengguna karena diperlukan oleh banyak aplikasi fungsi.
Google jelas melihat ini sebagai masalah. Ide di balik manajemen izin adalah untuk memisahkan aplikasi apa yang dapat dan tidak dapat diakses. Jika hampir setiap aplikasi diberikan akses baca ke data pengguna yang berpotensi sensitif, maka izin tersebut tidak ada artinya. Oleh karena itu, Google memutuskan bahwa mereka memerlukan pendekatan baru. Di sinilah FUSE berperan.
Sistem file di Ruang Pengguna (FUSE)
Dimulai dengan Android 4.4, Google memutuskan untuk tidak lagi memasang partisi “sdcard” virtual sebagai VFAT. Sebaliknya, Google mulai menggunakan FUSE untuk meniru FAT32 pada partisi virtual “sdcard”. Dengan panggilan program sdcard FUSE untuk meniru izin direktori gaya FAT-on-sdcard, aplikasi dapat mulai mengakses datanya yang disimpan di penyimpanan eksternal tanpa memerlukan izin apa pun. Memang benar, mulai API Level 19, READ_EXTERNAL_STORAGE tidak lagi diperlukan untuk mengakses file yang berada di penyimpanan eksternal - asalkan folder data yang dibuat oleh daemon FUSE cocok dengan nama paket aplikasi. FUSE akan menanganinya mensintesis pemilik, grup, dan mode file di penyimpanan eksternal ketika aplikasi diinstal.
FUSE berbeda dari modul dalam kernel karena memungkinkan pengguna yang tidak memiliki hak istimewa untuk menulis sistem file virtual. Alasan Google menerapkan FUSE cukup sederhana - Google telah melakukan apa yang mereka inginkan dan sudah lakukan dipahami dan didokumentasikan dengan baik di dunia Linux. Mengutip a Pengembang Google tentang masalah ini:
"Karena FUSE adalah API stabil yang bagus, pada dasarnya tidak ada pekerjaan pemeliharaan yang diperlukan saat berpindah antar versi kernel. Jika kami bermigrasi ke solusi dalam kernel, kami akan mendaftar untuk memelihara serangkaian patch untuk setiap versi kernel yang stabil." -Jeff Sharkey, Insinyur Perangkat Lunak di Google
Namun, menjadi sangat jelas bahwa overhead FUSE menyebabkan penurunan kinerja di antara masalah-masalah lainnya. Pengembang yang saya ajak bicara mengenai masalah ini, Michal Kowalczyk, menulis posting blog yang sangat bagus lebih dari setahun yang lalu merinci masalah terkini dengan FUSE. Detail teknis lebih lanjut dapat dibaca di blognya, namun saya akan menjelaskan temuannya (dengan izinnya) dalam istilah yang lebih awam.
Masalah dengan FUSE
Di Android, daemon ruang pengguna “sdcard” menggunakan FUSE untuk memasang /dev/fuse ke direktori penyimpanan eksternal yang ditiru saat boot. Setelah itu, daemon sdcard melakukan polling pada perangkat FUSE untuk setiap pesan yang tertunda dari kernel. Jika Anda mendengarkan podcast, Anda mungkin pernah mendengar Mr. Lemarchand mengacu pada FUSE yang memperkenalkan overhead selama operasi I/O - inilah yang sebenarnya terjadi.
Di dunia nyata, kinerja ini berdampak buruk setiap file disimpan di penyimpanan eksternal.
Masalah #1 - Overhead I/O
Katakanlah kita membuat file teks sederhana, bernama “test.txt”, dan menyimpannya di /sdcard/test.txt (yang mana, misalkan saya ingatkan Anda, sebenarnya /data/media/0/test.txt dengan asumsi pengguna saat ini adalah pengguna utama di perangkat). Jika kita ingin membaca (perintah cat) file ini, kita mengharapkan sistem mengeluarkan 3 perintah: buka, baca, lalu tutup. Memang benar, seperti yang ditunjukkan oleh Tuan Kowalczyk dalam penggunaannya jejak, itulah yang terjadi:
Namun karena file terletak di penyimpanan eksternal yang dikelola oleh daemon sdcard, banyak operasi tambahan yang perlu dilakukan. Menurut Bapak Kowalczyk, pada dasarnya ada 8 langkah tambahan yang diperlukan masing-masing dari 3 perintah individu ini:
- Aplikasi Userspace mengeluarkan panggilan sistem yang akan ditangani oleh driver FUSE di kernel (kita melihatnya di keluaran strace pertama)
- Driver FUSE di kernel memberi tahu daemon ruang pengguna (sdcard) tentang permintaan baru
- Daemon ruang pengguna berbunyi /dev/fuse
- Daemon Userspace mem-parsing perintah dan mengenali operasi file (mis. membuka)
- Daemon ruang pengguna mengeluarkan panggilan sistem ke sistem file sebenarnya (EXT4)
- Kernel menangani akses data fisik dan mengirimkan data kembali ke ruang pengguna
- Userspace memodifikasi (atau tidak) data dan meneruskannya melalui /dev/fuse ke kernel lagi
- Kernel menyelesaikan panggilan sistem asli dan memindahkan data ke aplikasi ruang pengguna sebenarnya (dalam contoh kita cat)
Ini sepertinya banyak overhead hanya untuk satu perintah I/O yang akan dijalankan. Dan Anda benar. Untuk mendemonstrasikan hal ini, Pak Kowalczyk mencoba dua pengujian I/O yang berbeda: satu melibatkan penyalinan file besar dan yang lainnya menyalin banyak file kecil. Dia membandingkan kecepatan FUSE (pada partisi virtual yang dipasang sebagai FAT32) dalam menangani operasi ini versus kecepatan kernel (pada partisi data yang diformat sebagai EXT4), dan dia menemukan bahwa FUSE memang memberikan kontribusi yang signifikan atas.
Pada pengujian pertama, dia menyalin file 725MB dalam kedua kondisi pengujian. Dia menemukan bahwa implementasi FUSE mentransfer file besar 17% lebih lambat.
Pada pengujian kedua, dia menyalin 10.000 file - masing-masing berukuran 5KB. Dalam skenario ini, penerapan FUSE telah berakhir 40 detik lebih lambat untuk menyalin data senilai 50 MB.
Di dunia nyata, kinerja ini berdampak buruk setiap file disimpan di penyimpanan eksternal. Ini berarti aplikasi seperti Maps menyimpan file besar di /sdcard, aplikasi Musik menyimpan banyak file musik, aplikasi Kamera dan foto, dll. Setiap operasi I/O yang dilakukan yang melibatkan penyimpanan eksternal dipengaruhi oleh overhead FUSE. Namun overhead I/O bukan satu-satunya masalah dengan FUSE.
Masalah #2 - Caching Ganda
Caching data penting dalam meningkatkan kinerja akses data. Dengan menyimpan bagian-bagian penting data dalam memori, kernel Linux dapat dengan cepat mengingat data tersebut bila diperlukan. Namun karena cara penerapan FUSE, Android menyimpan dua kali lipat jumlah cache yang dibutuhkan.
Seperti yang ditunjukkan oleh Tuan Kowalczyk, file 10MB diharapkan disimpan dalam cache sama persis dengan 10 MB, namun malah ditingkatkan ke ukuran cache sekitar 20MB. Ini menjadi masalah pada perangkat dengan RAM lebih sedikit, karena penyimpanan kernel Linux menggunakan cache halaman untuk menyimpan data Penyimpanan. Tuan Kowalczyk menguji masalah cache ganda ini menggunakan pendekatan ini:
- Buat file dengan ukuran yang diketahui (untuk pengujian, 10MB)
- Salin ke /sdcard
- Jatuhkan cache halaman
- Ambil cuplikan penggunaan cache halaman
- Baca file tes
- Ambil cuplikan lain dari penggunaan cache halaman
Apa yang dia temukan adalah sebelum pengujiannya, 241MB digunakan oleh kernel untuk cache halaman. Setelah dia membaca file pengujiannya, dia berharap melihat 251MB digunakan untuk cache halaman. Sebaliknya, dia menemukan bahwa kernel itu sedang digunakan 263MB untuk cache halaman - tentang dua kali lipat dari yang diharapkan. Alasan terjadinya hal ini adalah karena data pertama kali di-cache oleh aplikasi pengguna yang pertama kali mengeluarkan panggilan I/O (FUSE), dan kedua oleh daemon sdcard (EXT4 FS).
Masalah #3 - Implementasi FAT32 Tidak Lengkap
Ada dua masalah lagi yang berasal dari penggunaan FUSE yang meniru FAT32 yang kurang dikenal luas di komunitas Android.
Yang pertama melibatkan stempel waktu yang salah. Jika Anda pernah mentransfer file (seperti foto) dan menyadari bahwa stempel waktunya salah, itu karena penerapan FUSE di Android. Masalah ini sudah ada untuk bertahun-tahun. Untuk lebih spesifiknya, permasalahan ini melibatkan waktu() panggilan sistem yang memungkinkan Anda mengubah waktu akses dan modifikasi suatu file. Sayangnya, panggilan yang dilakukan ke daemon sdcard sebagai pengguna standar tidak memiliki izin yang tepat untuk menjalankan panggilan sistem ini. Ada solusi untuk ini, tetapi Anda harus melakukannya memiliki akses root.
Jika Anda pernah mentransfer file (seperti foto) dan menyadari bahwa stempel waktunya salah, itu karena penerapan FUSE di Android.
Masalah berikutnya lebih memprihatinkan bagi bisnis yang menggunakan sesuatu seperti a kartu smartSD. Sebelum FUSE, pembuat aplikasi dapat memantau Bendera O_DIRECT untuk berkomunikasi dengan mikrokontroler yang tertanam di kartu. Dengan FUSE, pengembang hanya dapat mengakses versi file yang di-cache, dan tidak dapat melihat perintah apa pun yang dikirim oleh mikrokontroler. Hal ini menjadi masalah bagi beberapa aplikasi perusahaan/pemerintah/perbankan yang berkomunikasi dengan kartu microSD yang memiliki nilai tambah.
Membuang FUSE untuk SDCardFS
Beberapa OEM mengenali masalah ini sejak dini, dan mulai mencari solusi dalam kernel untuk menggantikan FUSE. Samsung, misalnya, mengembangkan Kartu SDFS yang didasarkan pada WrapFS. Solusi dalam kernel ini mengemulasi FAT32 seperti yang dilakukan FUSE, namun mengabaikan overhead I/O, cache ganda, dan masalah lain yang telah saya sebutkan di atas. (Ya, izinkan saya mengulangi hal itu, solusi yang sekarang diterapkan Google ini didasarkan pada karya Samsung).
Google sendiri akhirnya mengakui kelemahan yang terkait dengan FUSE, itulah sebabnya mereka mulai beralih ke lapisan emulasi FAT32 dalam kernel yang dikembangkan oleh Samsung. Perusahaan, sebagaimana disebutkan dalam Pengembang Android di Belakang Panggung podcast, telah berupaya membuat SDCardFS tersedia untuk semua perangkat di versi kernel yang akan datang. Saat ini Anda dapat melihat kemajuan mereka bekerja di AOSP.
Sebagai Pengembang Google menjelaskan sebelumnya, tantangan terbesar dalam mengimplementasikan solusi dalam kernel adalah bagaimana memetakan nama paket ID aplikasi yang diperlukan paket untuk mengakses datanya sendiri di penyimpanan eksternal tanpa memerlukan apa pun izin. Namun pernyataan tersebut dibuat setahun yang lalu, dan kami telah mencapai titik di mana tim menyebut SDCardFS sebagai “hal besar berikutnya.” Mereka sudah memastikan bahwa kesalahan stempel waktu yang ditakuti telah diperbaiki, berkat peralihan dari FUSE, sehingga kita dapat menantikan semua perubahan yang terjadi dengan ditinggalkannya FUSE.
Kesalahpahaman Pengecekan Fakta
Jika Anda sudah sampai sejauh ini dalam artikel ini, maka pujian untuk mengikuti semuanya sejauh ini! Saya ingin mengklarifikasi beberapa pertanyaan yang saya miliki saat menulis artikel ini:
- SDCardFS memiliki tidak ada hubungannya dengan Kartu SD yang sebenarnya. Dinamakan demikian karena menangani akses I/O untuk/sdcard. Dan seperti yang mungkin Anda ingat, /sdcard adalah label usang yang mengacu pada penyimpanan “eksternal” perangkat Anda (tempat aplikasi menyimpan medianya).
- SDCardFS adalah bukan sistem file tradisional seperti FAT32, EXT4, atau F2FS. Ini adalah sistem file pembungkus yang dapat ditumpuk yang meneruskan perintah ke sistem file yang lebih rendah dan ditiru (dalam hal ini, FAT32 di /sdcard).
- Tidak ada yang akan berubah sehubungan dengan MTP. Anda akan terus menggunakan MTP untuk mentransfer file ke/dari komputer Anda (sampai Google memilih protokol yang lebih baik). Tapi setidaknya kesalahan stempel waktu akan diperbaiki!
- Seperti disebutkan sebelumnya, ketika Google mengacu pada "Penyimpanan Eksternal", mereka berbicara tentang (untuk semua maksud dan tujuan) partisi FAT32 virtual internal / sdcard ATAU mereka berbicara tentang microSD yang sebenarnya, fisik, dan dapat dilepas kartu. Terminologinya membingungkan, tapi itulah yang membuat kami terkejut.
Kesimpulan
Dengan beralih dari FUSE dan menerapkan lapisan emulasi FAT32 dalam kernel (SDCardFS), Google akan mengurangi overhead I/O yang signifikan, menghilangkan cache ganda, dan menyelesaikan beberapa masalah tidak jelas terkait dengan emulasi FUSE FAT32.
Karena perubahan ini akan dilakukan pada kernel, perubahan tersebut dapat diluncurkan tanpa versi utama Android baru yang menyertainya. Beberapa pengguna mengharapkan perubahan ini diterapkan secara resmi di Android 8, tetapi hal itu mungkin saja terjadi untuk OTA masa depan apa pun pada perangkat Pixel untuk menghadirkan kernel Linux versi 4.1 yang telah digunakan Google pada.
Bagi sebagian dari Anda, SDCardFS bukanlah konsep baru. Faktanya, perangkat Samsung telah menggunakannya selama bertahun-tahun (merekalah yang mengembangkannya). Sejak SDCardFS diperkenalkan di AOSP tahun lalu, beberapa pengembang custom ROM dan kernel telah memilih untuk mengimplementasikannya ke dalam pekerjaan mereka. CyanogenMOD pernah mempertimbangkan untuk menerapkannya, namun membatalkannya ketika pengguna mengalami masalah dengan foto mereka. Namun semoga dengan Google yang mengambil alih proyek ini, pengguna Android di semua perangkat masa depan dapat memanfaatkan peningkatan yang diperkenalkan dengan mengabaikan FUSE.