Ikhtisar A/B virtual

Android memiliki dua mekanisme pembaruan: pembaruan A/B (mulus) dan pembaruan non-A/B. Untuk mengurangi kompleksitas kode dan menyempurnakan proses update, di Android 11 kedua mekanisme tersebut disatukan melalui A/B virtual untuk menghadirkan update yang lancar ke semua perangkat dengan biaya penyimpanan yang minimal. Android 12 menawarkan opsi kompresi A/B Virtual untuk mengompresi partisi yang diambil snapshotnya. Di Android 11 dan Android 12, hal berikut ini berlaku:

  • Pembaruan A/B virtual berjalan mulus seperti pembaruan A/B. Pembaruan A/B virtual meminimalkan waktu perangkat offline dan tidak dapat digunakan.
  • Pembaruan A/B virtual dapat dibatalkan . Jika OS baru gagal melakukan booting, perangkat secara otomatis memutar kembali ke versi sebelumnya.
  • Pembaruan A/B virtual menggunakan ruang ekstra minimum dengan hanya menduplikasi partisi yang digunakan oleh bootloader. Partisi lain yang dapat diupdate akan diambil snapshotnya .

Latar belakang dan terminologi

Bagian ini mendefinisikan terminologi dan menjelaskan teknologi yang mendukung A/B virtual.

Pemeta perangkat

Device-mapper adalah lapisan blok virtual Linux yang sering digunakan di Android. Dengan partisi dinamis , partisi seperti /system adalah tumpukan perangkat berlapis:

  • Di bagian bawah tumpukan adalah partisi super fisik (misalnya, /dev/block/by-name/super ).
  • Di tengah adalah perangkat dm-linear , menentukan blok mana di partisi super yang membentuk partisi tertentu. Ini muncul sebagai /dev/block/mapper/system_[a|b] pada perangkat A/B, atau /dev/block/mapper/system pada perangkat non-A/B.
  • Di bagian atas terdapat perangkat dm-verity , dibuat untuk partisi terverifikasi. Perangkat ini memverifikasi bahwa blok pada perangkat dm-linear ditandatangani dengan benar. Tampaknya sebagai /dev/block/mapper/system-verity dan merupakan sumber titik pemasangan /system .

Gambar 1 menunjukkan seperti apa tumpukan di bawah titik pemasangan /system .

Partition stacking underneath system

Gambar 1. Tumpukan di bawah titik pemasangan /sistem

dm-snapshot

Virtual A/B mengandalkan dm-snapshot , modul pemetaan perangkat untuk mengambil snapshot status perangkat penyimpanan. Saat menggunakan dm-snapshot , ada empat perangkat yang dimainkan:

  • Perangkat dasar adalah perangkat yang diambil snapshotnya. Pada halaman ini, perangkat dasar selalu berupa partisi dinamis, seperti sistem atau vendor.
  • Perangkat copy-on-write (COW), untuk mencatat perubahan pada perangkat dasar. Ukurannya bisa berapa saja, namun harus cukup besar untuk mengakomodasi semua perubahan pada perangkat dasar.
  • Perangkat snapshot dibuat menggunakan target snapshot . Penulisan ke perangkat snapshot ditulis ke perangkat COW. Pembacaan dari perangkat snapshot dibaca dari perangkat dasar atau perangkat COW, bergantung pada apakah data yang diakses telah diubah oleh snapshot.
  • Perangkat asal dibuat menggunakan target snapshot-origin . Pembacaan ke perangkat asal dibaca langsung dari perangkat dasar. Menulis ke perangkat asal menulis langsung ke perangkat dasar, namun data asli dicadangkan dengan menulis ke perangkat COW.

Device mapping for dm-snapshot

Gambar 2. Pemetaan perangkat untuk dm-snapshot

Snapshot terkompresi

Di Android 12 dan yang lebih tinggi, karena kebutuhan ruang pada partisi /data bisa jadi tinggi, Anda dapat mengaktifkan snapshot terkompresi di build Anda untuk mengatasi kebutuhan ruang yang lebih tinggi pada partisi /data .

Snapshot terkompresi A/B virtual dibuat berdasarkan komponen berikut yang tersedia di Android 12 dan lebih tinggi:

  • dm-user , modul kernel mirip dengan FUSE yang memungkinkan ruang pengguna untuk mengimplementasikan perangkat blok.
  • snapuserd , daemon ruang pengguna untuk mengimplementasikan format snapshot baru.

Komponen-komponen ini memungkinkan kompresi. Perubahan lain yang diperlukan untuk mengimplementasikan kemampuan snapshot terkompresi diberikan di bagian berikutnya: format COW untuk snapshot terkompresi , dm-user , dan Snapuserd .

Format COW untuk snapshot terkompresi

Di Android 12 dan lebih tinggi, snapshot terkompresi menggunakan format COW. Mirip dengan format bawaan kernel yang digunakan untuk snapshot tidak terkompresi, format COW untuk snapshot terkompresi memiliki bagian metadata dan data yang bergantian. Metadata format asli hanya diperbolehkan untuk operasi penggantian : Ganti blok X di gambar dasar dengan konten blok Y di snapshot. Format COW snapshot terkompresi lebih ekspresif dan mendukung operasi berikut:

  • Copy : Blok X pada perangkat dasar harus diganti dengan blok Y pada perangkat dasar.
  • Ganti : Blok X di perangkat dasar harus diganti dengan konten blok Y di snapshot. Masing-masing blok ini dikompresi gz.
  • Nol : Blok X pada perangkat dasar harus diganti dengan semua angka nol.
  • XOR : Perangkat COW menyimpan byte terkompresi XOR antara blok X dan blok Y . (Tersedia di Android 13 dan lebih tinggi.)

Pembaruan OTA penuh hanya terdiri dari operasi penggantian dan nol . Pembaruan OTA tambahan juga dapat memiliki operasi penyalinan .

pengguna dm di Android 12

Modul kernel dm-user memungkinkan userspace untuk mengimplementasikan perangkat blok pemeta perangkat. Entri tabel dm-user membuat perangkat lain-lain di bawah /dev/dm-user/<control-name> . Proses userspace dapat melakukan polling pada perangkat untuk menerima permintaan baca dan tulis dari kernel. Setiap permintaan memiliki buffer terkait untuk ruang pengguna untuk diisi (untuk membaca) atau disebarkan (untuk menulis).

Modul kernel dm-user menyediakan antarmuka baru yang terlihat pengguna ke kernel yang bukan bagian dari basis kode kernel.org upstream. Hingga saat ini, Google berhak mengubah antarmuka dm-user di Android.

snapuserd

Komponen ruang pengguna snapuserd ke dm-user mengimplementasikan kompresi A/B Virtual.

Dalam versi Virtual A/B yang tidak terkompresi, (baik di Android 11 dan yang lebih rendah, atau di Android 12 tanpa opsi snapshot terkompresi), perangkat COW adalah file mentah. Ketika kompresi diaktifkan, COW berfungsi sebagai perangkat dm-user , yang terhubung ke instance daemon snapuserd .

Kernel tidak menggunakan format COW yang baru. Jadi komponen snapuserd menerjemahkan permintaan antara format Android COW dan format bawaan kernel:

Snapuserd component translating requests between Android COW format and kernel built-in format

Gambar 3. Diagram alir snapuserd sebagai penerjemah antara format COW Android dan Kernel

Terjemahan dan dekompresi ini tidak pernah terjadi pada disk. Komponen snapuserd mencegat pembacaan dan penulisan COW yang terjadi di kernel, dan mengimplementasikannya menggunakan format Android COW.

kompresi XOR

Untuk perangkat yang diluncurkan dengan Android 13 dan lebih tinggi, fitur kompresi XOR, yang diaktifkan secara default, memungkinkan snapshot ruang pengguna untuk menyimpan byte terkompresi XOR antara blok lama dan blok baru. Ketika hanya beberapa byte dalam satu blok diubah dalam pembaruan Virtual A/B, skema penyimpanan kompresi XOR menggunakan lebih sedikit ruang dibandingkan skema penyimpanan default karena snapshot tidak menyimpan 4K byte penuh. Pengurangan ukuran snapshot ini dimungkinkan karena data XOR berisi banyak angka nol dan lebih mudah dikompres dibandingkan data blok mentah. Pada perangkat Pixel, kompresi XOR mengurangi ukuran snapshot sebesar 25% hingga 40%.

Untuk perangkat yang diupgrade ke Android 13 dan lebih tinggi, kompresi XOR harus diaktifkan. Untuk detailnya, lihat Kompresi XOR .

Proses kompresi A/B virtual

Bagian ini memberikan detail tentang proses kompresi A/B Virtual yang digunakan di Android 13 dan Android 12.

Membaca metadata (Android 12)

Metadata dibuat oleh daemon snapuserd . Metadata pada dasarnya adalah pemetaan dua ID, masing-masing 8 byte, yang mewakili sektor yang akan digabungkan. Dalam dm-snapshot itu disebut disk_exception .

struct disk_exception {
    uint64_t old_chunk;
    uint64_t new_chunk;
};

Pengecualian disk digunakan ketika potongan data lama diganti dengan yang baru.

Daemon snapuserd membaca file COW internal melalui perpustakaan COW dan membuat metadata untuk setiap operasi COW yang ada dalam file COW.

Pembacaan metadata dimulai dari dm-snapshot di kernel ketika perangkat dm- snapshot dibuat.

Gambar di bawah menyediakan diagram urutan jalur IO untuk konstruksi metadata.

Sequence diagram, IO path for metadata construction

Gambar 4. Alur urutan jalur IO dalam konstruksi metadata

Penggabungan (Android 12)

Setelah proses boot selesai, mesin pembaruan menandai slot sebagai boot berhasil dan memulai penggabungan dengan mengalihkan target dm-snapshot ke target dm-snapshot-merge .

dm-snapshot menelusuri metadata dan memulai penggabungan IO untuk setiap pengecualian disk. Ikhtisar tingkat tinggi jalur penggabungan IO ditunjukkan di bawah.

Merge IO path

Gambar 5. Ikhtisar jalur gabungan IO

Jika perangkat di-boot ulang selama proses penggabungan, penggabungan akan dilanjutkan pada reboot berikutnya, dan penggabungan selesai.

Pelapisan pemetaan perangkat

Untuk perangkat yang diluncurkan dengan Android 13 dan lebih tinggi, proses penggabungan snapshot dan snapshot dalam kompresi A/B Virtual dilakukan oleh komponen ruang pengguna snapuserd . Untuk perangkat yang diupgrade ke Android 13 dan lebih tinggi, fitur ini harus diaktifkan. Untuk detailnya, lihat Penggabungan ruang pengguna .

Berikut ini penjelasan proses kompresi A/B Virtual:

  1. Kerangka kerja ini memasang partisi /system dari perangkat dm-verity , yang ditumpuk di atas perangkat dm-user . Ini berarti bahwa setiap I/O dari sistem file root dirutekan ke dm-user .
  2. dm-user merutekan I/O ke daemon snapuserd userspace, yang menangani permintaan I/O.
  3. Ketika operasi penggabungan selesai, kerangka kerja akan menciutkan dm-verity di atas dm-linear ( system_base ) dan menghapus dm-user .

Proses kompresi A/B virtual

Gambar 6. Proses kompresi A/B virtual

Proses penggabungan snapshot dapat terhenti. Jika perangkat di-boot ulang selama proses penggabungan, proses penggabungan akan dilanjutkan setelah reboot.

Init transisi

Saat mem-boot dengan snapshot terkompresi, init tahap pertama harus memulai snapuserd untuk memasang partisi. Hal ini menimbulkan masalah: Ketika sepolicy dimuat dan diterapkan, snapuserd ditempatkan dalam konteks yang salah, dan permintaan bacanya gagal, dengan penolakan selinux.

Untuk mengatasi hal ini, snapuserd melakukan transisi dalam langkah kunci dengan init , sebagai berikut:

  1. init tahap pertama meluncurkan snapuserd dari ramdisk, dan menyimpan deskriptor file yang terbuka ke dalamnya dalam variabel lingkungan.
  2. init tahap pertama mengalihkan sistem file root ke partisi sistem, kemudian mengeksekusi salinan sistem init .
  3. Salinan sistem init membaca sepolicy gabungan menjadi sebuah string.
  4. Init memanggil mlock() pada semua halaman yang didukung ext4. Ini kemudian menonaktifkan semua tabel pemeta perangkat untuk perangkat snapshot, dan menghentikan snapuserd . Setelah ini dilarang membaca dari partisi, karena hal itu menyebabkan kebuntuan.
  5. Menggunakan deskriptor terbuka ke salinan ramdisk snapuserd , init meluncurkan kembali daemon dengan konteks selinux yang benar. Tabel pemetaan perangkat untuk perangkat snapshot diaktifkan kembali.
  6. Init memanggil munlockall() - aman untuk melakukan IO lagi.

Penggunaan ruang

Tabel berikut memberikan perbandingan penggunaan ruang untuk mekanisme OTA yang berbeda menggunakan OS Pixel dan ukuran OTA.

Dampak Ukuran non-A/B A/B A/B maya A/B Virtual (terkompresi)
Gambar Asli Pabrik 4,5GB super (gambar 3,8G + cadangan 700M) 1 9GB super (dicadangkan 3,8G + 700M, untuk dua slot) 4,5GB super (gambar 3,8G + cadangan 700M) 4,5GB super (gambar 3,8G + cadangan 700M)
Partisi statis lainnya /cache Tidak ada Tidak ada Tidak ada
Penyimpanan tambahan Selama OTA (ruang dikembalikan setelah menerapkan OTA) 1,4GB pada /data 0 3,8GB 2 pada /data 2.1GB 2 pada /data
Total penyimpanan diperlukan untuk menerapkan OTA 5.9GB 3 (super dan data) 9GB (super) 8.3GB 3 (super dan data) 6.6GB 3 (super dan data)

1 Menunjukkan asumsi tata letak berdasarkan pemetaan Piksel.

2 Mengasumsikan gambar sistem baru memiliki ukuran yang sama dengan aslinya.

3 Kebutuhan ruang bersifat sementara hingga reboot.

Untuk mengimplementasikan Virtual A/B, atau untuk menggunakan kemampuan snapshot terkompresi, lihat Menerapkan Virtual A/B

,

Android memiliki dua mekanisme pembaruan: pembaruan A/B (mulus) dan pembaruan non-A/B. Untuk mengurangi kompleksitas kode dan menyempurnakan proses update, di Android 11 kedua mekanisme tersebut disatukan melalui A/B virtual untuk menghadirkan update yang lancar ke semua perangkat dengan biaya penyimpanan yang minimal. Android 12 menawarkan opsi kompresi A/B Virtual untuk mengompresi partisi yang diambil snapshotnya. Di Android 11 dan Android 12, hal berikut ini berlaku:

  • Pembaruan A/B virtual berjalan mulus seperti pembaruan A/B. Pembaruan A/B virtual meminimalkan waktu perangkat offline dan tidak dapat digunakan.
  • Pembaruan A/B virtual dapat dibatalkan . Jika OS baru gagal melakukan booting, perangkat secara otomatis memutar kembali ke versi sebelumnya.
  • Pembaruan A/B virtual menggunakan ruang ekstra minimum dengan hanya menduplikasi partisi yang digunakan oleh bootloader. Partisi lain yang dapat diupdate akan diambil snapshotnya .

Latar belakang dan terminologi

Bagian ini mendefinisikan terminologi dan menjelaskan teknologi yang mendukung A/B virtual.

Pemeta perangkat

Device-mapper adalah lapisan blok virtual Linux yang sering digunakan di Android. Dengan partisi dinamis , partisi seperti /system adalah tumpukan perangkat berlapis:

  • Di bagian bawah tumpukan adalah partisi super fisik (misalnya, /dev/block/by-name/super ).
  • Di tengah adalah perangkat dm-linear , menentukan blok mana di partisi super yang membentuk partisi tertentu. Ini muncul sebagai /dev/block/mapper/system_[a|b] pada perangkat A/B, atau /dev/block/mapper/system pada perangkat non-A/B.
  • Di bagian atas terdapat perangkat dm-verity , dibuat untuk partisi terverifikasi. Perangkat ini memverifikasi bahwa blok pada perangkat dm-linear ditandatangani dengan benar. Tampaknya sebagai /dev/block/mapper/system-verity dan merupakan sumber titik pemasangan /system .

Gambar 1 menunjukkan seperti apa tumpukan di bawah titik pemasangan /system .

Partition stacking underneath system

Gambar 1. Tumpukan di bawah titik pemasangan /sistem

dm-snapshot

Virtual A/B mengandalkan dm-snapshot , modul pemetaan perangkat untuk mengambil snapshot status perangkat penyimpanan. Saat menggunakan dm-snapshot , ada empat perangkat yang dimainkan:

  • Perangkat dasar adalah perangkat yang diambil snapshotnya. Pada halaman ini, perangkat dasar selalu berupa partisi dinamis, seperti sistem atau vendor.
  • Perangkat copy-on-write (COW), untuk mencatat perubahan pada perangkat dasar. Ukurannya bisa berapa saja, namun harus cukup besar untuk mengakomodasi semua perubahan pada perangkat dasar.
  • Perangkat snapshot dibuat menggunakan target snapshot . Penulisan ke perangkat snapshot ditulis ke perangkat COW. Pembacaan dari perangkat snapshot dibaca dari perangkat dasar atau perangkat COW, bergantung pada apakah data yang diakses telah diubah oleh snapshot.
  • Perangkat asal dibuat menggunakan target snapshot-origin . Pembacaan ke perangkat asal dibaca langsung dari perangkat dasar. Menulis ke perangkat asal menulis langsung ke perangkat dasar, namun data asli dicadangkan dengan menulis ke perangkat COW.

Device mapping for dm-snapshot

Gambar 2. Pemetaan perangkat untuk dm-snapshot

Snapshot terkompresi

Di Android 12 dan yang lebih tinggi, karena kebutuhan ruang pada partisi /data bisa jadi tinggi, Anda dapat mengaktifkan snapshot terkompresi di build Anda untuk mengatasi kebutuhan ruang yang lebih tinggi pada partisi /data .

Snapshot terkompresi A/B virtual dibuat berdasarkan komponen berikut yang tersedia di Android 12 dan lebih tinggi:

  • dm-user , modul kernel mirip dengan FUSE yang memungkinkan ruang pengguna untuk mengimplementasikan perangkat blok.
  • snapuserd , daemon ruang pengguna untuk mengimplementasikan format snapshot baru.

Komponen-komponen ini memungkinkan kompresi. Perubahan lain yang diperlukan untuk mengimplementasikan kemampuan snapshot terkompresi diberikan di bagian berikutnya: format COW untuk snapshot terkompresi , dm-user , dan Snapuserd .

Format COW untuk snapshot terkompresi

Di Android 12 dan lebih tinggi, snapshot terkompresi menggunakan format COW. Mirip dengan format bawaan kernel yang digunakan untuk snapshot tidak terkompresi, format COW untuk snapshot terkompresi memiliki bagian metadata dan data yang bergantian. Metadata format asli hanya diperbolehkan untuk operasi penggantian : Ganti blok X di gambar dasar dengan konten blok Y di snapshot. Format COW snapshot terkompresi lebih ekspresif dan mendukung operasi berikut:

  • Copy : Blok X pada perangkat dasar harus diganti dengan blok Y pada perangkat dasar.
  • Ganti : Blok X di perangkat dasar harus diganti dengan konten blok Y di snapshot. Masing-masing blok ini dikompresi gz.
  • Nol : Blok X pada perangkat dasar harus diganti dengan semua angka nol.
  • XOR : Perangkat COW menyimpan byte terkompresi XOR antara blok X dan blok Y . (Tersedia di Android 13 dan lebih tinggi.)

Pembaruan OTA penuh hanya terdiri dari operasi penggantian dan nol . Pembaruan OTA tambahan juga dapat memiliki operasi penyalinan .

pengguna dm di Android 12

Modul kernel dm-user memungkinkan userspace untuk mengimplementasikan perangkat blok pemeta perangkat. Entri tabel dm-user membuat perangkat lain-lain di bawah /dev/dm-user/<control-name> . Proses userspace dapat melakukan polling pada perangkat untuk menerima permintaan baca dan tulis dari kernel. Setiap permintaan memiliki buffer terkait untuk ruang pengguna untuk diisi (untuk membaca) atau disebarkan (untuk menulis).

Modul kernel dm-user menyediakan antarmuka baru yang terlihat pengguna ke kernel yang bukan bagian dari basis kode kernel.org upstream. Hingga saat ini, Google berhak mengubah antarmuka dm-user di Android.

snapuserd

Komponen ruang pengguna snapuserd ke dm-user mengimplementasikan kompresi A/B Virtual.

Dalam versi Virtual A/B yang tidak terkompresi, (baik di Android 11 dan yang lebih rendah, atau di Android 12 tanpa opsi snapshot terkompresi), perangkat COW adalah file mentah. Ketika kompresi diaktifkan, COW berfungsi sebagai perangkat dm-user , yang terhubung ke instance daemon snapuserd .

Kernel tidak menggunakan format COW yang baru. Jadi komponen snapuserd menerjemahkan permintaan antara format Android COW dan format bawaan kernel:

Snapuserd component translating requests between Android COW format and kernel built-in format

Gambar 3. Diagram alir snapuserd sebagai penerjemah antara format COW Android dan Kernel

Terjemahan dan dekompresi ini tidak pernah terjadi pada disk. Komponen snapuserd mencegat pembacaan dan penulisan COW yang terjadi di kernel, dan mengimplementasikannya menggunakan format Android COW.

kompresi XOR

Untuk perangkat yang diluncurkan dengan Android 13 dan lebih tinggi, fitur kompresi XOR, yang diaktifkan secara default, memungkinkan snapshot ruang pengguna untuk menyimpan byte terkompresi XOR antara blok lama dan blok baru. Ketika hanya beberapa byte dalam satu blok diubah dalam pembaruan Virtual A/B, skema penyimpanan kompresi XOR menggunakan lebih sedikit ruang dibandingkan skema penyimpanan default karena snapshot tidak menyimpan 4K byte penuh. Pengurangan ukuran snapshot ini dimungkinkan karena data XOR berisi banyak angka nol dan lebih mudah dikompres dibandingkan data blok mentah. Pada perangkat Pixel, kompresi XOR mengurangi ukuran snapshot sebesar 25% hingga 40%.

Untuk perangkat yang diupgrade ke Android 13 dan lebih tinggi, kompresi XOR harus diaktifkan. Untuk detailnya, lihat Kompresi XOR .

Proses kompresi A/B virtual

Bagian ini memberikan detail tentang proses kompresi A/B Virtual yang digunakan di Android 13 dan Android 12.

Membaca metadata (Android 12)

Metadata dibuat oleh daemon snapuserd . Metadata pada dasarnya adalah pemetaan dua ID, masing-masing 8 byte, yang mewakili sektor yang akan digabungkan. Dalam dm-snapshot itu disebut disk_exception .

struct disk_exception {
    uint64_t old_chunk;
    uint64_t new_chunk;
};

Pengecualian disk digunakan ketika potongan data lama diganti dengan yang baru.

Daemon snapuserd membaca file COW internal melalui perpustakaan COW dan membuat metadata untuk setiap operasi COW yang ada dalam file COW.

Pembacaan metadata dimulai dari dm-snapshot di kernel ketika perangkat dm- snapshot dibuat.

Gambar di bawah menyediakan diagram urutan jalur IO untuk konstruksi metadata.

Sequence diagram, IO path for metadata construction

Gambar 4. Alur urutan jalur IO dalam konstruksi metadata

Penggabungan (Android 12)

Setelah proses boot selesai, mesin pembaruan menandai slot sebagai boot berhasil dan memulai penggabungan dengan mengalihkan target dm-snapshot ke target dm-snapshot-merge .

dm-snapshot menelusuri metadata dan memulai penggabungan IO untuk setiap pengecualian disk. Ikhtisar tingkat tinggi jalur penggabungan IO ditunjukkan di bawah.

Merge IO path

Gambar 5. Ikhtisar jalur gabungan IO

Jika perangkat di-boot ulang selama proses penggabungan, penggabungan akan dilanjutkan pada reboot berikutnya, dan penggabungan selesai.

Pelapisan pemetaan perangkat

Untuk perangkat yang diluncurkan dengan Android 13 dan lebih tinggi, proses penggabungan snapshot dan snapshot dalam kompresi A/B Virtual dilakukan oleh komponen ruang pengguna snapuserd . Untuk perangkat yang diupgrade ke Android 13 dan lebih tinggi, fitur ini harus diaktifkan. Untuk detailnya, lihat Penggabungan ruang pengguna .

Berikut ini penjelasan proses kompresi A/B Virtual:

  1. Kerangka kerja ini memasang partisi /system dari perangkat dm-verity , yang ditumpuk di atas perangkat dm-user . Ini berarti bahwa setiap I/O dari sistem file root dirutekan ke dm-user .
  2. dm-user merutekan I/O ke daemon snapuserd userspace, yang menangani permintaan I/O.
  3. Ketika operasi penggabungan selesai, kerangka kerja akan menciutkan dm-verity di atas dm-linear ( system_base ) dan menghapus dm-user .

Proses kompresi A/B virtual

Gambar 6. Proses kompresi A/B virtual

Proses penggabungan snapshot dapat terhenti. Jika perangkat di-boot ulang selama proses penggabungan, proses penggabungan akan dilanjutkan setelah reboot.

Init transisi

Saat mem-boot dengan snapshot terkompresi, init tahap pertama harus memulai snapuserd untuk memasang partisi. Hal ini menimbulkan masalah: Ketika sepolicy dimuat dan diterapkan, snapuserd ditempatkan dalam konteks yang salah, dan permintaan bacanya gagal, dengan penolakan selinux.

Untuk mengatasi hal ini, snapuserd melakukan transisi dalam langkah kunci dengan init , sebagai berikut:

  1. init tahap pertama meluncurkan snapuserd dari ramdisk, dan menyimpan deskriptor file yang terbuka ke dalamnya dalam variabel lingkungan.
  2. init tahap pertama mengalihkan sistem file root ke partisi sistem, kemudian mengeksekusi salinan sistem init .
  3. Salinan sistem init membaca sepolicy gabungan menjadi sebuah string.
  4. Init memanggil mlock() pada semua halaman yang didukung ext4. Ini kemudian menonaktifkan semua tabel pemeta perangkat untuk perangkat snapshot, dan menghentikan snapuserd . Setelah ini dilarang membaca dari partisi, karena hal itu menyebabkan kebuntuan.
  5. Menggunakan deskriptor terbuka ke salinan ramdisk snapuserd , init meluncurkan kembali daemon dengan konteks selinux yang benar. Tabel pemetaan perangkat untuk perangkat snapshot diaktifkan kembali.
  6. Init memanggil munlockall() - aman untuk melakukan IO lagi.

Penggunaan ruang

Tabel berikut memberikan perbandingan penggunaan ruang untuk mekanisme OTA yang berbeda menggunakan OS Pixel dan ukuran OTA.

Dampak Ukuran non-A/B A/B A/B maya A/B Virtual (terkompresi)
Gambar Asli Pabrik 4.5GB super (gambar 3.8G + cadangan 700M) 1 9GB super (dicadangkan 3,8G + 700M, untuk dua slot) 4,5GB super (gambar 3,8G + cadangan 700M) 4,5GB super (gambar 3,8G + cadangan 700M)
Partisi statis lainnya /cache Tidak ada Tidak ada Tidak ada
Penyimpanan tambahan Selama OTA (ruang dikembalikan setelah menerapkan OTA) 1,4GB pada /data 0 3,8GB 2 pada /data 2.1GB 2 pada /data
Total penyimpanan diperlukan untuk menerapkan OTA 5.9GB 3 (super dan data) 9GB (super) 8.3GB 3 (super dan data) 6.6GB 3 (super dan data)

1 Menunjukkan asumsi tata letak berdasarkan pemetaan Piksel.

2 Mengasumsikan gambar sistem baru memiliki ukuran yang sama dengan aslinya.

3 Kebutuhan ruang bersifat sementara hingga reboot.

Untuk mengimplementasikan Virtual A/B, atau untuk menggunakan kemampuan snapshot terkompresi, lihat Menerapkan Virtual A/B