Mengimplementasikan partisi dinamis

Partisi dinamis diimplementasikan menggunakan device-mapper dm-linear pada kernel Linux. Partisi super berisi metadata yang mencantumkan nama dan rentang blok setiap partisi dinamis dalam super. Selama init tahap pertama, metadata diuraikan dan divalidasi, dan perangkat blok virtual dibuat untuk yang mewakili setiap partisi dinamis.

Saat menerapkan OTA, partisi dinamis otomatis dibuat, diubah ukurannya, atau dihapus sesuai kebutuhan. Untuk perangkat A/B, ada dua salinan metadata, dan perubahan hanya diterapkan pada salinan yang mewakili slot target.

Karena partisi dinamis diimplementasikan dalam ruang pengguna, partisi diperlukan oleh {i>bootloader<i} tidak dapat dibuat dinamis. Misalnya boot, dtbo, dan vbmeta dibaca oleh bootloader, dan jadi harus tetap sebagai partisi fisik.

Setiap partisi dinamis dapat dimasukkan ke grup update. Ini grup membatasi ruang maksimum yang dapat digunakan oleh partisi dalam grup tersebut. Misalnya, system dan vendor dapat menjadi bagian dari yang membatasi ukuran total system dan vendor.

Mengimplementasikan partisi dinamis pada perangkat baru

Bagian ini menjelaskan cara menerapkan partisi dinamis pada perangkat baru diluncurkan dengan Android 10 dan yang lebih tinggi. Untuk memperbarui perangkat yang ada, lihat Mengupgrade Android perangkat.

Perubahan partisi

Untuk perangkat yang diluncurkan dengan Android 10, buat partisi yang disebut super. super partisi menangani slot A/B secara internal, sehingga perangkat A/B tidak perlu partisi super_a dan super_b terpisah. Semua partisi AOSP hanya-baca yang tidak digunakan oleh bootloader harus bersifat dinamis dan harus dihapus dari Tabel Partisi GUID (GPT). Partisi khusus vendor tidak harus dinamis dan dapat ditempatkan dalam GPT.

Untuk memperkirakan ukuran super, tambahkan ukuran partisi yang dihapus dari GPT. Untuk perangkat A/B, harus menyertakan ukuran kedua slot. Gambar 1 menunjukkan contoh tabel partisi sebelum dan sesudah melakukan konversi ke dinamis partisi.

Tata letak tabel partisi
Gambar 1. Tata letak tabel partisi fisik yang baru ketika mengonversi ke partisi dinamis

Partisi dinamis yang didukung adalah:

  • Sistem
  • Vendor
  • Produk
  • di Luar Sistem
  • Pengelolaan Pesanan dan Pemenuhan Produk

Untuk perangkat yang diluncurkan dengan Android 10, opsi command line kernel androidboot.super_partition harus kosong agar perintah sysprop ro.boot.super_partition kosong.

Perataan partisi

Modul mapper perangkat mungkin beroperasi kurang efisien jika Partisi super tidak disejajarkan dengan benar. Tujuan Partisi super HARUS diselaraskan dengan I/O minimum ukuran permintaan seperti yang ditentukan oleh lapisan blok. Secara default, sistem build (melalui lpmake, yang menghasilkan gambar partisi super), mengasumsikan bahwa penyelarasan 1 MiB sudah cukup untuk setiap partisi dinamis. Namun, vendor harus pastikan partisi super diselaraskan dengan benar.

Anda bisa menentukan ukuran permintaan minimum perangkat blok dengan memeriksa sysfs. Contoh: 

# ls -l /dev/block/by-name/super
lrwxrwxrwx 1 root root 16 1970-04-05 01:41 /dev/block/by-name/super -> /dev/block/sda17
# cat /sys/block/sda/queue/minimum_io_size
786432

Anda dapat memverifikasi perataan partisi super dalam file serupa: 

# cat /sys/block/sda/sda17/alignment_offset

Offset perataan HARUS 0.

Perubahan konfigurasi perangkat

Untuk mengaktifkan partisi dinamis, tambahkan flag berikut di device.mk: 

PRODUCT_USE_DYNAMIC_PARTITIONS := true

Perubahan konfigurasi board

Anda harus menetapkan ukuran partisi super: 

BOARD_SUPER_PARTITION_SIZE := <size-in-bytes>

Pada perangkat A/B, sistem build akan menampilkan error jika ukuran total lebih dari setengah super image partisi dinamis ukuran partisi.

Anda dapat mengonfigurasi daftar partisi dinamis sebagai berikut. Sebagai perangkat menggunakan grup pembaruan, buat daftar grup dalam Variabel BOARD_SUPER_PARTITION_GROUPS. Setiap nama grup kemudian memiliki BOARD_group_SIZE dan BOARD_group_PARTITION_LIST. Untuk perangkat A/B, ukuran maksimum grup hanya boleh mencakup satu {i>slot <i}karena nama grup telah diakhiri slot secara internal.

Berikut adalah contoh perangkat yang menempatkan semua partisi ke dalam sebuah grup disebut example_dynamic_partitions: 

BOARD_SUPER_PARTITION_GROUPS := example_dynamic_partitions
BOARD_EXAMPLE_DYNAMIC_PARTITIONS_SIZE := 6442450944
BOARD_EXAMPLE_DYNAMIC_PARTITIONS_PARTITION_LIST := system vendor product

Berikut adalah contoh perangkat yang menempatkan layanan produk dan sistem ke dalam group_foo, dan vendor, product, dan odm ke dalam group_bar: 

BOARD_SUPER_PARTITION_GROUPS := group_foo group_bar
BOARD_GROUP_FOO_SIZE := 4831838208
BOARD_GROUP_FOO_PARTITION_LIST := system product_services
BOARD_GROUP_BAR_SIZE := 1610612736
BOARD_GROUP_BAR_PARTITION_LIST := vendor product odm
  • Untuk perangkat peluncuran A/B Virtual, jumlah ukuran maksimum semua grup harus maksimal:
    BOARD_SUPER_PARTITION_SIZE - overhead
    Lihat Mengimplementasikan A/B Virtual.
  • Untuk perangkat peluncuran A/B, jumlah ukuran maksimum semua grup harus menjadi:
    BOARD_SUPER_PARTITION_SIZE / 2 - overhead
  • Untuk perangkat non-A/B dan retrofit perangkat A/B, jumlah ukuran semua grup harus:
    BOARD_SUPER_PARTITION_SIZE - overhead
  • Pada waktu build, jumlah ukuran image setiap partisi dalam grup update tidak boleh melebihi ukuran maksimum grup.
  • Overhead diperlukan dalam komputasi untuk memperhitungkan metadata, keselarasan, dan sebagainya. Overhead yang wajar adalah 4 MiB, tetapi Anda dapat memilih overhead yang lebih besar sesuai kebutuhan perangkat.

Mengukur partisi dinamis

Sebelum partisi dinamis, ukuran partisi dialokasikan secara berlebihan untuk memastikan bahwa mereka memiliki cukup ruang untuk pembaruan berikutnya. Ukuran sebenarnya digunakan sebagaimana adanya dan sebagian besar partisi {i>read-only<i} memiliki beberapa ruang penyimpanan di sistem file mereka. Dalam partisi dinamis, ruang kosong itu tidak dapat digunakan dan dapat digunakan untuk mengembangkan partisi selama OTA. Sangat penting untuk memastikan bahwa partisi tidak membuang-buang ruang dan dialokasikan ke ukuran yang seminimal mungkin.

Untuk image ext4 hanya-baca, sistem build secara otomatis mengalokasikan ukuran minimum jika tidak ada ukuran partisi {i>hardcode<i} yang ditentukan. Tujuan sesuai dengan gambar sehingga sistem file hanya memiliki sedikit ruang yang tidak digunakan mungkin. Hal ini memastikan bahwa perangkat tidak terbuang yang dapat digunakan untuk OTA.

Selain itu, gambar ext4 dapat dikompresi lebih lanjut dengan mengaktifkan penghapusan duplikat. Untuk mengaktifkannya, gunakan konfigurasi berikut: 

BOARD_EXT4_SHARE_DUP_BLOCKS := true

Jika alokasi otomatis ukuran minimum partisi tidak diinginkan, ada dua cara untuk mengontrol ukuran partisi. Anda dapat menentukan jumlah minimum ruang kosong dengan BOARD_partitionIMAGE_PARTITION_RESERVED_SIZE, atau Anda bisa menentukan BOARD_partitionIMAGE_PARTITION_SIZE untuk memaksa partisi dinamis ke ukuran tertentu. Tak satu pun dari ini adalah direkomendasikan kecuali jika diperlukan.

Contoh: 

BOARD_PRODUCTIMAGE_PARTITION_RESERVED_SIZE := 52428800

Tindakan ini memaksa sistem file di product.img untuk memiliki 50 MiB ruang yang tidak digunakan.

Perubahan sistem sebagai root

Perangkat yang diluncurkan dengan Android 10 tidak boleh menggunakan {i>system-as-root<i}.

Perangkat dengan partisi dinamis (baik yang diluncurkan dengan maupun yang retrofit dinamis) tidak boleh menggunakan {i>system-as-root<i}. Kernel Linux tidak bisa menafsirkan partisi super sehingga tidak dapat dipasang system itu sendiri. system kini dipasang oleh tahap pertama init, yang berada dalam ramdisk.

Jangan setel BOARD_BUILD_SYSTEM_ROOT_IMAGE. Di beberapa Android 10, Flag BOARD_BUILD_SYSTEM_ROOT_IMAGE hanya digunakan untuk membedakan apakah sistem dipasang oleh {i>kernel<i} atau oleh init tahap pertama di ramdisk.

Menetapkan BOARD_BUILD_SYSTEM_ROOT_IMAGE ke true yang menyebabkan error build PRODUCT_USE_DYNAMIC_PARTITIONS juga true.

Jika BOARD_USES_RECOVERY_AS_BOOT ditetapkan ke true, image pemulihan dibangun sebagai boot.img, yang berisi konfigurasi ramdisk. Sebelumnya, bootloader menggunakan kernel skip_initramfs parameter baris perintah untuk menentukan mode mana yang akan di-{i>booting<i}. Sebagai Perangkat Android 10, bootloader TIDAK BOLEH lulus skip_initramfs ke command line kernel. Sebagai gantinya, bootloader harus melewati androidboot.force_normal_boot=1 untuk melewati pemulihan dan mem-booting Android normal. Perangkat yang diluncurkan dengan Android 12 atau yang lebih baru harus menggunakan bootconfig untuk meneruskan androidboot.force_normal_boot=1.

Perubahan konfigurasi AVB

Saat menggunakan Android Booting Terverifikasi 2.0, jika perangkat tidak menggunakan partisi berantai deskripsi, maka tidak diperlukan perubahan. Jika menggunakan rantai partisi, namun, dan salah satu partisi terverifikasi bersifat dinamis, maka perubahan diperlukan.

Berikut adalah contoh konfigurasi untuk perangkat yang rantai vbmeta untuk system dan Partisi vendor. 

BOARD_AVB_SYSTEM_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_SYSTEM_ALGORITHM := SHA256_RSA2048
BOARD_AVB_SYSTEM_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_SYSTEM_ROLLBACK_INDEX_LOCATION := 1

BOARD_AVB_VENDOR_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_VENDOR_ALGORITHM := SHA256_RSA2048
BOARD_AVB_VENDOR_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_VENDOR_ROLLBACK_INDEX_LOCATION := 1

Dengan konfigurasi ini, bootloader akan menemukan file vbmeta footer di akhir system dan Partisi vendor. Karena partisi ini tidak lagi terlihat oleh bootloader (mereka berada di super), dua diperlukan perubahan.

  • Menambahkan vbmeta_system dan vbmeta_vendor partisi ke tabel partisi perangkat. Untuk perangkat A/B, tambahkan vbmeta_system_a, vbmeta_system_b, vbmeta_vendor_a, dan vbmeta_vendor_b. Jika menambahkan satu atau beberapa partisi ini, ukurannya harus sama sebagai partisi vbmeta.
  • Ganti nama flag konfigurasi dengan menambahkan VBMETA_ dan menentukan partisi mana yang diperluas oleh rantai: 
    BOARD_AVB_VBMETA_SYSTEM := system
BOARD_AVB_VBMETA_SYSTEM_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_VBMETA_SYSTEM_ALGORITHM := SHA256_RSA2048
BOARD_AVB_VBMETA_SYSTEM_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_VBMETA_SYSTEM_ROLLBACK_INDEX_LOCATION := 1

BOARD_AVB_VBMETA_VENDOR := vendor
BOARD_AVB_VBMETA_VENDOR_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_VBMETA_VENDOR_ALGORITHM := SHA256_RSA2048
BOARD_AVB_VBMETA_VENDOR_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_VBMETA_VENDOR_ROLLBACK_INDEX_LOCATION := 1

Perangkat mungkin menggunakan salah satu, keduanya, atau tidak menggunakan partisi ini. Perubahan diperlukan hanya saat membuat rantai ke partisi logis.

Perubahan bootloader AVB

Jika bootloader telah menyematkan libavb, menyertakan patch berikut:

Jika menggunakan partisi berantai, sertakan patch tambahan:

  • 49936b4c0109411fdd38bd4ba3a32a01c40439a9 — "libavb: Mendukung vbmeta blobs di awal partisi."

Perubahan command line kernel

Parameter baru, androidboot.boot_devices, harus ditambahkan ke baris perintah {i>kernel<i}. ID ini digunakan oleh init untuk mengaktifkan /dev/block/by-name symlink. Ini harusnya komponen jalur perangkat ke symlink menurut nama yang mendasarinya yang dibuat oleh ueventd, yaitu, /dev/block/platform/device-path/by-name/partition-name. Perangkat yang diluncurkan dengan Android 12 atau yang lebih baru harus menggunakan bootconfig untuk meneruskan androidboot.boot_devices ke init.

Misalnya, jika {i>symlink<i} menurut nama partisi super adalah /dev/block/platform/soc/100000.ufshc/by-name/super, Anda dapat menambahkan parameter baris perintah dalam file BoardConfig.mk sebagai berikut ini: 

BOARD_KERNEL_CMDLINE += androidboot.boot_devices=soc/100000.ufshc
Anda dapat menambahkan parameter bootconfig dalam file BoardConfig.mk sebagai berikut: 
BOARD_BOOTCONFIG += androidboot.boot_devices=soc/100000.ufshc

perubahan fstab

Overlay hierarki perangkat dan hierarki perangkat tidak boleh berisi fstab entri. Gunakan file fstab yang akan menjadi bagian dari ramdisk.

Perubahan harus dilakukan pada file fstab untuk partisi logis:

  • Kolom flag fs_mgr harus menyertakan tanda logical dan flag first_stage_mount, yang diperkenalkan di Android 10, yang menunjukkan bahwa partisi akan dipasang pada tahap pertama.
  • Partisi dapat menentukan avb=vbmeta partition name sebagai Flag fs_mgr, lalu vbmeta yang ditentukan partisi diinisialisasi oleh tahap pertama init sebelum mencoba memasang perangkat apa pun.
  • Kolom dev harus berupa nama partisi.

Entri fstab berikut menetapkan sistem, vendor, dan produk sebagai logis partisi dengan mengikuti aturan di atas. 

#<dev>  <mnt_point> <type>  <mnt_flags options> <fs_mgr_flags>
system   /system     ext4    ro,barrier=1        wait,slotselect,avb=vbmeta,logical,first_stage_mount
vendor   /vendor     ext4    ro,barrier=1        wait,slotselect,avb,logical,first_stage_mount
product  /product    ext4    ro,barrier=1        wait,slotselect,avb,logical,first_stage_mount

Salin file fstab ke ramdisk tahap pertama.

Perubahan SELinux

Perangkat blok partisi super harus ditandai dengan label super_block_device. Misalnya, jika {i>symlink<i} menurut nama partisi super adalah /dev/block/platform/soc/100000.ufshc/by-name/super, tambahkan baris berikut ke file_contexts: 

/dev/block/platform/soc/10000\.ufshc/by-name/super   u:object_r:super_block_device:s0

fastboot

Bootloader (atau alat flash non-userspace) tidak memahami dinamis, sehingga tidak dapat di-{i>flash<i}. Untuk mengatasinya, perangkat harus menggunakan implementasi ruang-pengguna dari protokol {i>fastboot<i}, yang disebut {i>fastbootd<i}.

Untuk mengetahui informasi selengkapnya tentang cara menerapkan fastbootd, lihat Memindahkan Fastboot ke User Space.

pemasangan ulang adb

Untuk developer yang menggunakan build eng atau userdebug, adb remount sangat berguna untuk iterasi yang cepat. Partisi dinamis menampilkan masalah untuk adb remount karena tidak ada lagi paket gratis ruang di dalam setiap sistem file. Untuk mengatasinya, perangkat dapat mengaktifkan overlayfs. Selama ada ruang kosong di dalam partisi super, adb remount otomatis membuat dinamis sementara dan menggunakan overlayfs untuk penulisan. Partisi sementara adalah bernama scratch, jadi jangan gunakan nama ini untuk orang lain partisi.

Untuk informasi selengkapnya tentang cara mengaktifkan overlay, lihat overlayf README di AOSP.

Mengupgrade perangkat Android

Jika Anda mengupgrade perangkat ke Android 10, dan ingin menyertakan dukungan partisi dinamis di OTA, Anda tidak perlu mengubah tabel partisi {i>built-in<i}. Beberapa konfigurasi tambahan tidak diperlukan.

Perubahan konfigurasi perangkat

Untuk memperbaiki partisi dinamis, tambahkan flag berikut di device.mk: 

PRODUCT_USE_DYNAMIC_PARTITIONS := true
PRODUCT_RETROFIT_DYNAMIC_PARTITIONS := true

Perubahan konfigurasi board

Anda harus menetapkan variabel board berikut:

  • Setel BOARD_SUPER_PARTITION_BLOCK_DEVICES ke daftar perangkat blok yang digunakan untuk menyimpan luasnya partisi dinamis. Ini adalah daftar nama nama fisik yang ada partisi pada perangkat.
  • Setel BOARD_SUPER_PARTITION_partition_DEVICE_SIZE ke ukuran dari setiap perangkat blok di BOARD_SUPER_PARTITION_BLOCK_DEVICES. Ini adalah daftar ukuran partisi fisik yang ada di perangkat. Hal ini biasanya BOARD_partitionIMAGE_PARTITION_SIZE pada papan yang ada konfigurasi standar.
  • Batalkan penetapan BOARD_partitionIMAGE_PARTITION_SIZE yang ada untuk semua partisi di BOARD_SUPER_PARTITION_BLOCK_DEVICES.
  • Tetapkan BOARD_SUPER_PARTITION_SIZE ke jumlah dari BOARD_SUPER_PARTITION_partition_DEVICE_SIZE.
  • Setel BOARD_SUPER_PARTITION_METADATA_DEVICE ke perangkat blok tempat metadata partisi dinamis. Ini harus berupa salah satu BOARD_SUPER_PARTITION_BLOCK_DEVICES. Biasanya, ini diatur ke system.
  • Setel BOARD_SUPER_PARTITION_GROUPS, BOARD_group_SIZE dan BOARD_group_PARTITION_LIST. Lihat Perubahan konfigurasi Board di perangkat baru untuk mengetahui detailnya.

Misalnya, jika perangkat sudah memiliki partisi sistem dan vendor, dan Anda ingin mengonversi ke partisi dinamis dan menambahkan partisi produk baru selama update, setel konfigurasi board ini: 

BOARD_SUPER_PARTITION_BLOCK_DEVICES := system vendor
BOARD_SUPER_PARTITION_METADATA_DEVICE := system

# Rename BOARD_SYSTEMIMAGE_PARTITION_SIZE to BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE.
BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE := <size-in-bytes>

# Rename BOARD_VENDORIMAGE_PARTITION_SIZE to BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE
BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE := <size-in-bytes>

# This is BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE + BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE
BOARD_SUPER_PARTITION_SIZE := <size-in-bytes>

# Configuration for dynamic partitions. For example:
BOARD_SUPER_PARTITION_GROUPS := group_foo
BOARD_GROUP_FOO_SIZE := <size-in-bytes>
BOARD_GROUP_FOO_PARTITION_LIST := system vendor product

Perubahan SELinux

Perangkat blok partisi super harus ditandai dengan atribut super_block_device_type. Misalnya, jika perangkat sudah memiliki Partisi system dan vendor, Anda ingin menggunakannya sebagai blok perangkat untuk menyimpan luasnya partisi dinamis, dan symlink menurut namanya ditandai sebagai system_block_device: 

/dev/block/platform/soc/10000\.ufshc/by-name/system   u:object_r:system_block_device:s0
/dev/block/platform/soc/10000\.ufshc/by-name/vendor   u:object_r:system_block_device:s0

Kemudian, tambahkan baris berikut ke device.te: 

typeattribute system_block_device super_block_device_type;

Untuk konfigurasi lainnya, lihat Menerapkan partisi dinamis pada perangkat baru.

Untuk informasi selengkapnya tentang update retrofit, lihat OTA untuk Perangkat A/B tanpa Dynamic Partisi.

Setelan pabrik

Untuk peluncuran perangkat dengan dukungan partisi dinamis, hindari penggunaan {i>userspace fastboot<i} untuk mem-flash setelan pabrik, karena {i>booting<i} ke ruang pengguna lebih lambat dibandingkan metode flash lainnya.

Untuk mengatasinya, make dist kini membuat super.img gambar yang dapat di-flash langsung ke super partisi. Paket ini secara otomatis menggabungkan partisi, yang berarti berisi system.img, vendor.img, dan seterusnya, selain super metadata partisi. Gambar ini dapat di-flash langsung ke Partisi super tanpa alat tambahan atau penggunaan {i>fastbootd<i}. Setelah build, super.img ditempatkan di ${ANDROID_PRODUCT_OUT}.

Untuk perangkat A/B yang diluncurkan dengan partisi dinamis, super.img berisi gambar dalam slot A. Setelah mem-flash super image secara langsung, tandai slot A sebagai bootable sebelum me-reboot perangkat seluler.

Untuk perangkat retrofit, make dist mem-build kumpulan super_*.img gambar yang dapat di-flash langsung ke partisi fisik yang sesuai. Misalnya, make dist build super_system.img dan super_vendor.img jika BOARD_SUPER_PARTITION_BLOCK_DEVICES adalah sistem vendor. Image ini ditempatkan di folder OTA di target_files.zip.

Penyesuaian perangkat penyimpanan mapper perangkat

Partisi dinamis mengakomodasi sejumlah peta perangkat yang tidak menentukan objek terstruktur dalam jumlah besar. Ini mungkin tidak semuanya dibuat instance-nya seperti yang diharapkan, jadi Anda harus melacak semua pemasangan, dan memperbarui properti Android dari semua partisi terkait dengan perangkat penyimpanan yang mendasarinya.

Mekanisme di dalam init melacak pemasangan dan secara asinkron memperbarui properti Android. Jumlah waktu yang dibutuhkan tidak dijamin dalam jangka waktu tertentu, sehingga Anda harus menyediakan waktu yang cukup untuk semua pemicu on property yang akan bereaksi. Propertinya adalah dev.mnt.blk.<partition> di mana <partition> adalah root, system, data, atau vendor, misalnya. Setiap properti dikaitkan dengan nama perangkat penyimpanan dasar, seperti yang ditunjukkan dalam contoh berikut:

taimen:/ % getprop | grep dev.mnt.blk
[dev.mnt.blk.data]: [sda]
[dev.mnt.blk.firmware]: [sde]
[dev.mnt.blk.metadata]: [sde]
[dev.mnt.blk.persist]: [sda]
[dev.mnt.blk.root]: [dm-0]
[dev.mnt.blk.vendor]: [dm-1]

blueline:/ $ getprop | grep dev.mnt.blk
[dev.mnt.blk.data]: [dm-4]
[dev.mnt.blk.metadata]: [sda]
[dev.mnt.blk.mnt.scratch]: [sda]
[dev.mnt.blk.mnt.vendor.persist]: [sdf]
[dev.mnt.blk.product]: [dm-2]
[dev.mnt.blk.root]: [dm-0]
[dev.mnt.blk.system_ext]: [dm-3]
[dev.mnt.blk.vendor]: [dm-1]
[dev.mnt.blk.vendor.firmware_mnt]: [sda]

Bahasa init.rc memungkinkan properti Android diperluas sebagai bagian dari aturan, dan perangkat penyimpanan dapat disesuaikan oleh platform sesuai kebutuhan dengan perintah seperti berikut:

write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb 128
write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb 128

Setelah pemrosesan perintah dimulai di init tahap kedua, epoll loop menjadi aktif, dan nilai mulai diperbarui. Namun, karena pemicu properti tidak aktif sampai akhir init, pemicu tersebut tidak dapat digunakan pada tahap booting awal untuk menangani root, system, atau vendor. Anda mungkin mengharapkan default kernel read_ahead_kb cukup memadai hingga Skrip init.rc dapat diganti di early-fs (saat berbagai {i>daemon<i} dan fasilitas dimulai). Oleh karena itu, Google merekomendasikan agar Anda akan menggunakan fitur on property, ditambah dengan Properti yang dikontrol init.rc seperti sys.read_ahead_kb, untuk menangani pengaturan waktu operasi dan untuk mencegah kondisi race, seperti dalam contoh:

on property:dev.mnt.blk.root=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on property:dev.mnt.blk.system=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.system}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on property:dev.mnt.blk.vendor=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.vendor}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on property:dev.mnt.blk.product=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.system_ext}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on property:dev.mnt.blk.oem=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.oem}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on property:dev.mnt.blk.data=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on early-fs:
    setprop sys.read_ahead_kb ${ro.read_ahead_kb.boot:-2048}

on property:sys.boot_completed=1
   setprop sys.read_ahead_kb ${ro.read_ahead_kb.bootcomplete:-128}