Обзор Virtual A / B

В Android есть два механизма обновления: обновления A / B (бесшовные) и обновления не A / B. Чтобы снизить сложность кода и улучшить процесс обновления, в Android 11 два механизма объединены с помощью виртуальных A / B, чтобы обеспечить беспрепятственное обновление всех устройств с минимальной стоимостью хранения. Android 12 предлагает возможность виртуального сжатия A / B для сжатия разделов с моментальными снимками. Как в Android 11, так и в Android 12 применяется следующее:

  • Виртуальные обновления A / B незаметны как обновления A / B. Виртуальные обновления A / B минимизируют время, в течение которого устройство находится в автономном режиме и не может использоваться.
  • Виртуальные обновления A / B может быть произведен откат. Если новая ОС не загружается, устройства автоматически откатываются к предыдущей версии.
  • Виртуальные обновления A / B использует минимум дополнительного пространства путем дублирования только разделы, которые используются загрузчиком. Другие обновляемые разделы snapshotted .

Предпосылки и терминология

В этом разделе определяется терминология и описывается технология, поддерживающая виртуальный A / B.

Устройство-картограф

Device-mapper - это уровень виртуальных блоков Linux, часто используемый в Android. С динамических разделов , разделы как /system являются стопка слоистых устройств:

  • В нижней части стека является физическим супер раздела (например, /dev/block/by-name/super ).
  • В середине является dm-linear устройство, определяя , какие блоки в супер форме разделов данного раздела. Это , как представляется , как /dev/block/mapper/system_[a|b] на устройстве A / B или /dev/block/mapper/system на устройстве / не-A B.
  • На вершине находится в dm-verity устройство, созданное для верифицированных разделов. Это устройство проверяет , что блоки на dm-linear устройстве подписаны правильно. Он появляется как /dev/block/mapper/system-verity и является источником /system для монтирования.

На рисунке 1 показано , что стек под /system точку монтирования выглядит.

Partition stacking underneath system

Рисунок 1. Стек под / системой точки монтирования

dm-снимок

Виртуальный A / B полагается на dm-snapshot , модуль устройства картографа для мгновенных снимков состояния устройства хранения данных. При использовании dm-snapshot , четыре устройства в игре:

  • Базовое устройство является устройством , который snapshotted. На этой странице базовое устройство всегда является динамическим разделом, например системным или поставщиком.
  • Копирования при записи (КПС) устройства, для регистрации изменений в базовом устройстве. Он может быть любого размера, но должен быть достаточно большим, чтобы учесть все изменения в базовом устройстве.
  • Устройство снимок создается с помощью snapshot цели. Записи на устройство моментальных снимков записываются на устройство COW. Считывает из устройства моментального снимка, считываемого либо с базового устройства, либо с устройства COW, в зависимости от того, были ли данные, к которым осуществляется доступ, были изменены моментальным снимком.
  • Происхождение устройства создается с помощью snapshot-origin цели. Читает в исходное устройство, читается непосредственно с базового устройства. Записывает на исходное устройство Запись напрямую на базовое устройство, но исходные данные копируются путем записи на устройство COW.

Device mapping for dm-snapshot

Рисунок 2. Отображение устройств для ой-снимки

Сжатые снимки

В Android 12, потому что требования к пространству на /data раздела может быть высокими, вы можете включить сжимаетесь снимки в сборке для решения более высоких требований к расположению /data раздела.

Виртуальные сжатые снимки A / B создаются на основе двух новых компонентов, доступных в Android 12:

  • dm-user , модуль ядра похож на FUSE , которая позволяет реализовать в пользовательском пространстве блочных устройств.
  • snapuserd , демон пользовательского пространства реализовать новый формат снимок.

Эти компоненты включают сжатие. Другие необходимые изменения для реализации сжатых снимков возможностей приведены в следующих разделах: формат корова для сжатых снимок , ого-пользователя , и Snapuserd .

Формат COW для сжатых снимков

В Android 12 для сжатых снимков используется новый формат COW. Подобно встроенному формату ядра, используемому для несжатых снимков, формат COW для сжатых снимков имеет чередующиеся разделы метаданных и данных. Метаданные оригинального формата позволил только «заменить» операции: Заменить блок X в базовом изображении с содержимым блока Y в снимке. Формат сжатых снимков COW более выразителен и поддерживает три операции:

  • Копирование - Блок X в базовом устройстве должны быть заменены блоком Y в базовом устройстве.
  • Заменить - Блок X в базовом устройстве должны быть заменены с содержимым блока Y в снимок. Каждый из этих блоков сжат gz.
  • Ноль - Блок X в базовом устройстве должен быть заменен со всеми нулями.

Обновления Full OTA состоят из замены и нулевые операции только. Обновления Инкрементального OTA могут дополнительно иметь операции копирования.

dm-user в Android 12

Модуль ядра ого-пользователь включает в userspace для реализации блочных устройств устройства точек. Запись таблицы дм-пользователь создает различное устройство под /dev/dm-user/<control-name> . В userspace процесс может опрашивать устройство для приема запросов чтения и записи из ядра. С каждым запросом связан буфер для пользовательского пространства, который либо заполняется (для чтения), либо распространяется (для записи).

dm-user модуль ядра обеспечивает новый пользовательский интерфейс видимых к ядру , которое не является частью вверх по течению kernel.org кода. До тех пор, пока, Google оставляет за собой право вносить изменения в dm-user интерфейс в Android.

Snapuserd

snapuserd пользовательского пространство компоненты dm-user орудия Виртуального A / B сжатие.

В несжатой версии Virtual A / B (либо в Android 11 и ниже, либо в Android 12 без опции сжатого моментального снимка) устройство COW представляет собой необработанный файл. При включенном сжатии, корове вместо функции как dm-user устройства, которое соединено с экземпляром snapuserd демона.

Ядро не использует новый формат COW. Таким образом, snapuserd компонент переводит запросы между форматом Android КПСА и ядром встроенным в формате:

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

Рисунок 3. Технологическая схема snapuserd в качестве переводчика между Android и ядра форматов МСН

Это преобразование и распаковка никогда не происходит на диске. В snapuserd компонент перехватывает КПС чтения и записи , которые происходят в ядре и реализует их , используя формат Android корове.

Виртуальные процессы сжатия A / B

В этих разделах содержится подробная информация о процессах, используемых при виртуальном сжатии A / B: чтение метаданных, слияние и выполнение переходов init.

Чтение метаданных

Метаданные построена по snapuserd демона. Метаданные - это в первую очередь отображение 2 идентификаторов по 8 байтов каждый, которые представляют объединяемые секторы. В dm-snapshot он называется disk_exception .

struct disk_exception {
    uint64_t old_chunk;
    uint64_t new_chunk;
};

Дисковое исключение используется, когда старый фрагмент данных заменяется новым.

Snapuserd демон читает внутренний файл корове библиотеки КПС и создает метаданные для каждого из присутствующих COW операций в файле КПС.

Метаданные считывает инициируются из dm-snapshot в ядре , когда dm- snapshot создается устройство.

На рисунке ниже представлена ​​диаграмма последовательности для пути ввода-вывода для построения метаданных.

Sequence diagram, IO path for metadata construction

Рисунок 4. Последовательность операций на пути ввода - вывода в метаданных строительства

Слияние

После того, как процесс загрузки завершен, обновление двигатели марка прорезь , как ботинок успешного и инициирует слияние путем переключения dm-snapshot мишени на dm-snapshot-merge цели.

dm-snapshot проходит через метаданных и инициирует слияние ввода - вывода для каждого диска исключения. Ниже показан общий обзор пути ввода-вывода слияния.

Merge IO path

Рисунок 5. Объединить Обзор ввода - вывода путь

Если устройство перезагружается во время процесса слияния, слияние возобновляется при следующей перезагрузке, и слияние завершается.

Переходы инициализации

При загрузке с сжатыми снимками, первый этап инициализация должна начать snapuserd монтирования разделов. Это создает проблему: Когда sepolicy загружен и исполнено, snapuserd получает положить в неправильном контексте, и его запросов на чтение нарушиться, SELinux отказов.

Для решения этой проблемы , snapuserd переходов блокировки с шагом init , следующим образом :

  1. Первый этап- init запускает snapuserd из псевдодиска, и сохраняет открытый файл-дескриптор к нему в переменной окружения.
  2. Первая стадия init переключает корневую файловую систему в системный раздел, а затем выполняет системную копию init .
  3. Система копия init считывает комбинированную sepolicy в строку.
  4. Init вызывает mlock() на все поддерживаемые ext4 страницы. Затем он отключает все таблицы устройства картографа для моментальных устройств и останавливает snapuserd . После этого читать с разделов запрещено, так как это приводит к тупиковой ситуации.
  5. Используя открытый дескриптор виртуального диска , копию snapuserd , init запускается снова демон с правильным контекстом SELinux. Таблицы сопоставления устройств для устройств моментальных снимков повторно активируются.
  6. INIT вызывает munlockall() - это безопасно выполнять IO снова.

Использование пространства

В следующей таблице представлено сравнение использования пространства для различных механизмов OTA с использованием ОС Pixel и размеров OTA.

Влияние размера не A / B А / Б Виртуальный A / B Виртуальный A / B (сжатый)
Оригинальное заводское изображение 4,5 Гб супер (3.8g изображение + 700M зарезервирован) 1 9 ГБ super (3,8 ГБ + 700 МБ зарезервировано для двух слотов) 4,5 ГБ супер (3,8 ГБ образа + 700 МБ зарезервировано) 4,5 ГБ супер (3,8 ГБ образа + 700 МБ зарезервировано)
Другие статические разделы / кеш Никто Никто Никто
Дополнительное хранение Во время OTA (пространство возвращается после применения OTA) 1,4 ГБ на / данные 0 3.8GB 2 на / данных 2.1GB 2 на / данных
Общий объем памяти, необходимый для применения OTA 5.9GB 3 (супер и данных) 9 ГБ (супер) 8.3GB 3 (супер и данных) 6.6GB 3 (супер и данных)

1 Указывает , предполагается , макет , основанный на отображении Pixel.

2 Подразумевается новая система изображение имеет тот же размер , как оригинал.

3 Необходимое пространство преходяще до перезагрузки.

Для реализации Virtual A / B, или использовать сжатые возможности моментального снимка, см Реализация Virtual A / B