Динамическое секционирование реализовано с помощью модуля dm-linear device-mapper в ядре Linux. super
содержит метаданные, в которых перечислены имена и диапазоны блоков каждого динамического раздела в super
. Во время первого этапа init
эти метаданные анализируются и проверяются, и создаются виртуальные блочные устройства для представления каждого динамического раздела.
При применении OTA динамические разделы автоматически создаются, изменяются или удаляются по мере необходимости. Для устройств A/B существует две копии метаданных, и изменения применяются только к копии, представляющей целевой слот.
Поскольку динамические разделы реализованы в пользовательском пространстве, разделы, необходимые загрузчику, не могут быть сделаны динамическими. Например, boot
, dtbo
и vbmeta
считываются загрузчиком и поэтому должны оставаться физическими разделами.
Каждый динамический раздел может принадлежать группе обновлений . Эти группы ограничивают максимальное пространство, которое могут занимать разделы в этой группе. Например, system
и vendor
могут принадлежать к группе, которая ограничивает общий размер system
и vendor
.
Реализация динамических разделов на новых устройствах
В этом разделе подробно описано, как реализовать динамические разделы на новых устройствах, запускаемых с Android 10 и более поздних версий. Чтобы обновить существующие устройства, см. Обновление устройств Android .
Изменения раздела
Для устройств, запускаемых с Android 10, создайте раздел под названием super
. super
обрабатывает слоты A/B внутри себя, поэтому устройствам A/B не нужны отдельные разделы super_a
и super_b
. Все разделы AOSP только для чтения, которые не используются загрузчиком, должны быть динамическими и должны быть удалены из таблицы разделов GUID (GPT). Разделы, зависящие от поставщика, не обязательно должны быть динамическими и могут быть помещены в GPT.
Чтобы оценить размер super
, добавьте размеры разделов, удаляемых из GPT. Для устройств A/B сюда следует включать размер обоих слотов. На рис. 1 показан пример таблицы разделов до и после преобразования в динамические разделы.
Поддерживаемые динамические разделы:
- Система
- Продавец
- Продукт
- Системный доб.
- ОДМ
Для устройств, запускаемых с Android 10, параметр командной строки ядра androidboot.super_partition
должен быть пустым, чтобы команда sysprop ro.boot.super_partition
была пустой.
Выравнивание разделов
Модуль сопоставления устройств может работать менее эффективно, если super
не выровнен должным образом. super
ДОЛЖЕН быть выровнен по минимальному размеру запроса ввода-вывода , определенному уровнем блока. По умолчанию система сборки (через lpmake
, которая генерирует образ super
) предполагает, что выравнивания в 1 МБ достаточно для каждого динамического раздела. Однако поставщики должны убедиться, что super
правильно выровнен.
Вы можете определить минимальный размер запроса блочного устройства, проверив sysfs
. Например:
# 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
Вы можете проверить выравнивание super
аналогичным образом:
# cat /sys/block/sda/sda17/alignment_offset
Смещение выравнивания ДОЛЖНО быть равно 0.
Изменения конфигурации устройства
Чтобы включить динамическое секционирование, добавьте следующий флаг в device.mk
:
PRODUCT_USE_DYNAMIC_PARTITIONS := true
Изменения конфигурации платы
Вам необходимо установить размер super
:
BOARD_SUPER_PARTITION_SIZE := <size-in-bytes>
На устройствах A/B система сборки выдает ошибку, если общий размер образов динамических разделов превышает половину размера super
.
Вы можете настроить список динамических разделов следующим образом. Для устройств, использующих группы обновлений, перечислите группы в переменной BOARD_SUPER_PARTITION_GROUPS
. Каждое имя группы затем имеет переменную BOARD_ group _SIZE
и BOARD_ group _PARTITION_LIST
. Для устройств A/B максимальный размер группы должен охватывать только один слот, поскольку имена групп имеют внутренний суффикс слота.
Вот пример устройства, которое помещает все разделы в группу под названием 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
Вот пример устройства, которое помещает сервисы системы и продукта в group_foo
, а vendor
, product
и odm
в 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
- Для устройств запуска Virtual A/B сумма максимальных размеров всех групп не должна превышать:
BOARD_SUPER_PARTITION_SIZE
— накладные расходы
См. Реализация Virtual A/B . - Для устройств запуска A/B сумма максимальных размеров всех групп должна составлять:
BOARD_SUPER_PARTITION_SIZE
/2 — накладные расходы - Для устройств, отличных от A/B, и модернизированных устройств A/B сумма максимальных размеров всех групп должна составлять:
BOARD_SUPER_PARTITION_SIZE
— накладные расходы - Во время сборки сумма размеров образов каждого раздела в группе обновления не должна превышать максимальный размер группы.
- При вычислениях требуются накладные расходы для учета метаданных, выравниваний и т. д. Разумные накладные расходы составляют 4 МБ, но вы можете выбрать более крупные накладные расходы, если это необходимо устройству.
Размер динамических разделов
До появления динамических разделов размеры разделов выделялись слишком много, чтобы обеспечить достаточно места для будущих обновлений. Фактический размер был взят как есть, и большинство разделов, доступных только для чтения, имели некоторое количество свободного места в файловой системе. В динамических разделах это свободное пространство непригодно для использования и может быть использовано для увеличения разделов во время OTA. Крайне важно убедиться, что разделы не тратят зря пространство и им выделяется минимально возможный размер.
Для образов ext4, доступных только для чтения, система сборки автоматически выделяет минимальный размер, если не указан жестко закодированный размер раздела. Система сборки подгоняет образ так, чтобы в файловой системе оставалось как можно меньше неиспользуемого пространства. Это гарантирует, что устройство не будет тратить место, которое можно использовать для OTA.
Кроме того, образы ext4 можно дополнительно сжать, включив дедупликацию на уровне блоков. Чтобы включить это, используйте следующую конфигурацию:
BOARD_EXT4_SHARE_DUP_BLOCKS := true
Если автоматическое выделение минимального размера раздела нежелательно, существует два способа управления размером раздела. Вы можете указать минимальный объем свободного места с помощью BOARD_ partition IMAGE_PARTITION_RESERVED_SIZE
или указать BOARD_ partition IMAGE_PARTITION_SIZE
чтобы принудительно установить динамические разделы определенного размера. Ни один из этих способов не рекомендуется без необходимости.
Например:
BOARD_PRODUCTIMAGE_PARTITION_RESERVED_SIZE := 52428800
Это приводит к тому, что файловая система в product.img
будет иметь 50 МБ неиспользуемого пространства.
Изменения в системе как root
Устройства, запускаемые с Android 10, не должны использовать систему с правами root.
Устройства с динамическими разделами (независимо от того, запускаются ли они с динамическими разделами или модифицируются ими) не должны использовать систему с правами root. Ядро Linux не может интерпретировать super
и поэтому не может смонтировать саму system
. system
теперь монтируется с помощью init
первого этапа, который находится на виртуальном диске.
Не устанавливайте BOARD_BUILD_SYSTEM_ROOT_IMAGE
. В Android 10 флаг BOARD_BUILD_SYSTEM_ROOT_IMAGE
используется только для того, чтобы различать, монтируется ли система ядром или init
первого этапа на виртуальном диске.
Установка BOARD_BUILD_SYSTEM_ROOT_IMAGE
значения true
приводит к ошибке сборки, если PRODUCT_USE_DYNAMIC_PARTITIONS
также имеет true
.
Если BOARD_USES_RECOVERY_AS_BOOT
установлено значение true, образ восстановления создается как boot.img, содержащий виртуальный диск восстановления. Раньше загрузчик использовал параметр командной строки ядра skip_initramfs
чтобы решить, в каком режиме загружаться. Для устройств Android 10 загрузчик НЕ ДОЛЖЕН передавать skip_initramfs
в командную строку ядра. Вместо этого загрузчик должен передать androidboot.force_normal_boot=1
чтобы пропустить восстановление и загрузить обычный Android. Устройства, запускаемые с Android 12 или более поздней версии, должны использовать bootconfig для передачи androidboot.force_normal_boot=1
.
Изменения конфигурации AVB
Если при использовании Android Verified Boot 2.0 устройство не использует связанные дескрипторы разделов , никаких изменений не требуется. Однако если используются связанные разделы и один из проверенных разделов является динамическим, тогда необходимы изменения.
Вот пример конфигурации устройства, которое объединяет vbmeta
для system
и 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
При такой конфигурации загрузчик ожидает найти нижний колонтитул vbmeta в конце system
и vendor
разделов. Поскольку эти разделы больше не видны загрузчику (они находятся в super
), необходимо внести два изменения.
- Добавьте разделы
vbmeta_system
иvbmeta_vendor
в таблицу разделов устройства. Для устройств A/B добавьтеvbmeta_system_a
,vbmeta_system_b
,vbmeta_vendor_a
иvbmeta_vendor_b
. При добавлении одного или нескольких таких разделов они должны иметь тот же размер, что и разделvbmeta
. - Переименуйте флаги конфигурации, добавив
VBMETA_
, и укажите, на какие разделы распространяется цепочка: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
Устройство может использовать один, оба или ни один из этих разделов. Изменения необходимы только при привязке к логическому разделу.
Изменения загрузчика AVB
Если в загрузчик встроена библиотека libavb , включите следующие исправления:
- 818cf56740775446285466eda984acedd4baeac0 — «libavb: запрашивать GUID разделов только тогда, когда они нужны командной строке».
- 5abd6bc2578968d24406d834471adfd995a0c2e9 — «Разрешить отсутствие системного раздела»
- 9ba3b6613b4e5130fa01a11d984c6b5f0eb3af05 — «Исправить AvbSlotVerifyData->cmdline, который мог иметь значение NULL»
Если вы используете связанные разделы, включите дополнительный патч:
- 49936b4c0109411fdd38bd4ba3a32a01c40439a9 — «libavb: поддержка больших объектов vbmeta в начале раздела».
Изменения командной строки ядра
В командную строку ядра необходимо добавить новый параметр androidboot.boot_devices
. Это используется init
для включения символических ссылок /dev/block/by-name
. Это должен быть компонент пути устройства к базовой символической ссылке по имени, созданной ueventd
, то есть /dev/block/platform/ device-path /by-name/ partition-name
. Устройства, запускаемые с Android 12 или более поздней версии, должны использовать bootconfig для передачи androidboot.boot_devices
в init
.
Например, если символическая ссылка по имени суперраздела — /dev/block/platform/ soc/100000.ufshc /by-name/super
, вы можете добавить параметр командной строки в файл BoardConfig.mk следующим образом:
BOARD_KERNEL_CMDLINE += androidboot.boot_devices=soc/100000.ufshcВы можете добавить параметр bootconfig в файл BoardConfig.mk следующим образом:
BOARD_BOOTCONFIG += androidboot.boot_devices=soc/100000.ufshc
изменения в fstab
Дерево устройств и наложения дерева устройств не должны содержать записи fstab. Используйте файл fstab, который будет частью виртуального диска.
Изменения необходимо внести в файл fstab для логических разделов:
- Поле fs_mgr flags должно включать
logical
флаг и флагfirst_stage_mount
, представленный в Android 10, который указывает, что раздел должен быть смонтирован на первом этапе. - Раздел может указать
avb= vbmeta partition name
в качестве флагаfs_mgr
, а затем указанный разделvbmeta
инициализируется на первом этапеinit
перед попыткой подключения каких-либо устройств. - Поле
dev
должно содержать имя раздела.
Следующие записи fstab определяют систему, поставщика и продукт как логические разделы в соответствии с приведенными выше правилами.
#<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
Скопируйте файл fstab на виртуальный диск первого этапа.
Изменения в SELinux
Блочное устройство суперраздела должно быть помечено меткой super_block_device
. Например, если символическая ссылка по имени суперраздела — /dev/block/platform/ soc/100000.ufshc /by-name/super
, добавьте следующую строку в file_contexts
:
/dev/block/platform/soc/10000\.ufshc/by-name/super u:object_r:super_block_device:s0
фастбутд
Загрузчик (или любой другой инструмент для прошивки, не относящийся к пользовательскому пространству) не понимает динамические разделы, поэтому не может их прошить. Чтобы решить эту проблему, устройства должны использовать реализацию протокола fastboot в пользовательском пространстве, называемую fastbootd.
Дополнительные сведения о том, как реализовать fastbootd, см. в разделе «Перемещение Fastboot в пространство пользователя» .
adb перемонтировать
Для разработчиков, использующих сборки eng или userdebug, adb remount
чрезвычайно полезен для быстрой итерации. Динамические разделы создают проблему для adb remount
поскольку в каждой файловой системе больше нет свободного места. Чтобы решить эту проблему, устройства могут включить overlayfs. Пока в суперразделе есть свободное место, adb remount
автоматически создает временный динамический раздел и использует overlayfs для записи. Временный раздел называется scratch
, поэтому не используйте это имя для других разделов.
Дополнительную информацию о том, как включить overlayfs, см. в README overlayfs в AOSP.
Обновите Android-устройства
Если вы обновляете устройство до Android 10 и хотите включить поддержку динамических разделов в OTA, вам не нужно изменять встроенную таблицу разделов. Требуется некоторая дополнительная настройка.
Изменения конфигурации устройства
Чтобы модифицировать динамическое секционирование, добавьте следующие флаги в device.mk
:
PRODUCT_USE_DYNAMIC_PARTITIONS := true PRODUCT_RETROFIT_DYNAMIC_PARTITIONS := true
Изменения конфигурации платы
Вам необходимо установить следующие переменные платы:
- Установите
BOARD_SUPER_PARTITION_BLOCK_DEVICES
в список блочных устройств, используемых для хранения экстентов динамических разделов. Это список имен существующих физических разделов на устройстве. - Установите для
BOARD_SUPER_PARTITION_ partition _DEVICE_SIZE
размеры каждого блочного устройства вBOARD_SUPER_PARTITION_BLOCK_DEVICES
соответственно. Это список размеров существующих физических разделов на устройстве. Обычно этоBOARD_ partition IMAGE_PARTITION_SIZE
в существующих конфигурациях платы. - Отмените настройку существующего
BOARD_ partition IMAGE_PARTITION_SIZE
для всех разделов вBOARD_SUPER_PARTITION_BLOCK_DEVICES
. - Установите
BOARD_SUPER_PARTITION_SIZE
в суммуBOARD_SUPER_PARTITION_ partition _DEVICE_SIZE
. - Установите для
BOARD_SUPER_PARTITION_METADATA_DEVICE
блочное устройство, на котором хранятся метаданные динамического раздела. Это должен быть один изBOARD_SUPER_PARTITION_BLOCK_DEVICES
. Обычно для этого параметра установлено значениеsystem
. - Установите
BOARD_SUPER_PARTITION_GROUPS
,BOARD_ group _SIZE
иBOARD_ group _PARTITION_LIST
соответственно. Подробности см. в разделе Изменения конфигурации платы на новых устройствах .
Например, если на устройстве уже есть системный раздел и раздел поставщика, и вы хотите преобразовать их в динамические разделы и добавить новый раздел продукта во время обновления, установите следующую конфигурацию платы:
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
Изменения в SELinux
Блочные устройства суперраздела должны быть отмечены атрибутом super_block_device_type
. Например, если на устройстве уже есть system
и раздел vendor
, вы хотите использовать их в качестве блочных устройств для хранения экстентов динамических разделов, а их символические ссылки по имени помечаются как 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
Затем добавьте следующую строку в device.te
:
typeattribute system_block_device super_block_device_type;
Дополнительные сведения о других конфигурациях см. в разделе «Реализация динамических разделов на новых устройствах» .
Дополнительные сведения об обновлениях см. в разделе OTA для устройств A/B без динамических разделов .
Заводские изображения
Если устройство запускается с поддержкой динамических разделов, избегайте использования быстрой загрузки пользовательского пространства для прошивки заводских образов, поскольку загрузка в пользовательское пространство происходит медленнее, чем другие методы прошивки.
Чтобы решить эту проблему, make dist
теперь создает дополнительный образ super.img
, который можно записать непосредственно в суперраздел. Он автоматически объединяет содержимое логических разделов, то есть содержит system.img
, vendor.img
и т. д., в дополнение к метаданным super
. Этот образ можно прошить непосредственно в super
без каких-либо дополнительных инструментов или использования fastbootd. После сборки super.img
помещается в ${ANDROID_PRODUCT_OUT}
.
Для устройств A/B, которые запускаются с динамическими разделами, super.img
содержит изображения в слоте A. После прошивки суперобраза напрямую отметьте слот А как загрузочный перед перезагрузкой устройства.
Для модифицированных устройств make dist
создает набор образов super_*.img
, которые можно записать непосредственно в соответствующие физические разделы. Например, make dist
создает super_system.img
и super_vendor.img
если BOARD_SUPER_PARTITION_BLOCK_DEVICES
является поставщиком системы. Эти изображения помещаются в папку OTA в target_files.zip
.
Настройка устройства хранения данных устройства сопоставления
Динамическое секционирование вмещает ряд недетерминированных объектов-сопоставителей устройств. Не все они могут создаваться так, как ожидалось, поэтому необходимо отслеживать все подключения и обновлять свойства Android всех связанных разделов с их базовыми устройствами хранения.
Механизм внутри init
отслеживает монтирование и асинхронно обновляет свойства Android. Время, которое это занимает, не обязательно попадает в определенный период, поэтому вы должны предоставить достаточно времени, чтобы все триггеры on property
среагировали. Свойства: dev.mnt.blk. <partition>
где <partition>
— это, например, root
, system
, data
vendor
. Каждое свойство связано с именем базового устройства хранения, как показано в следующих примерах:
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]
Язык init.rc
позволяет расширять свойства Android как часть правил, а устройства хранения могут настраиваться платформой по мере необходимости с помощью таких команд:
write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb 128 write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb 128
Как только обработка команды начинается на втором этапе init
, epoll loop
становится активным, и значения начинают обновляться. Однако, поскольку триггеры свойств не активны до поздней init
, их нельзя использовать на начальных этапах загрузки для обработки root
, system
vendor
. Вы можете ожидать, что стандартного read_ahead_kb
ядра будет достаточно до тех пор, пока сценарии init.rc
не смогут переопределить его в early-fs
(когда запускаются различные демоны и средства). Поэтому Google рекомендует использовать функцию on property
в сочетании со свойством, контролируемым init.rc
, например sys.read_ahead_kb
, для управления синхронизацией операций и предотвращения состояний гонки, как в этих примерах:
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}