Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Descripción general de Virtual A / B

Android tiene dos mecanismos de actualización: actualizaciones A / B (integradas) y actualizaciones no A / B. Para reducir la complejidad del código y mejorar el proceso de actualización, en Android 11 los dos mecanismos están unificados a través de A / B virtual para brindar actualizaciones integradas a todos los dispositivos con un costo de almacenamiento minimizado. Android 12 ofrece la opción de compresión A / B virtual para comprimir particiones instantáneas. Tanto en Android 11 como en Android 12, se aplica lo siguiente:

  • Actualizaciones A / B son virtuales continua como las actualizaciones de A / B. Las actualizaciones virtuales A / B minimizan el tiempo que un dispositivo está fuera de línea e inutilizable.
  • Actualizaciones A / B virtuales se pueden revertir. Si el nuevo sistema operativo no se inicia, los dispositivos vuelven automáticamente a la versión anterior.
  • Actualizaciones A / B virtuales utilizan un mínimo de espacio adicional mediante la duplicación de sólo las particiones que son utilizados por el cargador de arranque. Otras particiones actualizables se snapshotted .

Antecedentes y terminología

Esta sección define la terminología y describe la tecnología que admite A / B virtual.

Mapeador de dispositivos

El mapeador de dispositivos es una capa de bloques virtuales de Linux que se usa a menudo en Android. Con particiones dinámicas , como las particiones /system son una pila de dispositivos en capas:

  • En la parte inferior de la pila es la partición súper física (por ejemplo, /dev/block/by-name/super ).
  • En el medio es un dm-linear dispositivo, especificando que bloquea en forma partición súper la partición dada. Esto aparece como /dev/block/mapper/system_[a|b] en un dispositivo de A / B, o /dev/block/mapper/system en un dispositivo no-A / B.
  • En la parte superior reside una dm-verity dispositivo, creado para particiones verificados. Este dispositivo verifica que los bloques en la dm-linear dispositivo están firmados correctamente. Aparece como /dev/block/mapper/system-verity y es la fuente de la /system punto de montaje.

La Figura 1 muestra lo que la pila bajo el /system montaje apariencia de puntos similares.

Partition stacking underneath system

Figura 1. Pila bajo el / sistema de punto de montaje

dm-instantánea

A Virtual / B se basa en dm-snapshot , un módulo de mapeador de dispositivos para snapshotting el estado de un dispositivo de almacenamiento. Cuando se usa dm-snapshot , hay cuatro dispositivos en juego:

  • El dispositivo de base es el dispositivo que snapshotted. En esta página, el dispositivo base es siempre una partición dinámica, como sistema o proveedor.
  • El dispositivo de copia por escritura (CP), para registrar los cambios en el dispositivo base. Puede ser de cualquier tamaño, pero debe ser lo suficientemente grande para adaptarse a todos los cambios en el dispositivo base.
  • El dispositivo de instantánea se crea utilizando la snapshot de destino. Las escrituras en el dispositivo de instantáneas se escriben en el dispositivo COW. Las lecturas del dispositivo de instantánea se leen desde el dispositivo base o desde el dispositivo COW, dependiendo de si la instantánea ha cambiado los datos a los que se accede.
  • El dispositivo de origen se crea utilizando la snapshot-origin objetivo. Lee en el dispositivo de origen lee directamente desde el dispositivo base. Las escrituras en el dispositivo de origen escriben directamente en el dispositivo base, pero los datos originales se respaldan escribiendo en el dispositivo COW.

Device mapping for dm-snapshot

Figura 2. asignación de dispositivos para dm-instantánea

Instantáneas comprimidas

En Android 12, debido a los requisitos de espacio en el /data partición pueden ser altos, se puede habilitar instantáneas comprimido en su construcción para hacer frente a las necesidades de espacio superiores del /data de la partición.

Las instantáneas comprimidas virtuales A / B se crean sobre dos nuevos componentes que están disponibles en Android 12:

  • dm-user , un módulo de núcleo similar a la mecha que permite el espacio de usuario para implementar dispositivos de bloque.
  • snapuserd , un demonio de espacio de usuario para implementar un nuevo formato de instantánea.

Estos componentes permiten la compresión. Los otros cambios necesarios realizados para aplicar las instantáneas comprimidas capacidades se dan en las siguientes secciones: formato de vaca para instantáneas comprimidas , dm-usuario , y Snapuserd .

Formato COW para instantáneas comprimidas

En Android 12, las instantáneas comprimidas usan un nuevo formato COW. Similar al formato integrado del kernel que se usa para las instantáneas sin comprimir, el formato COW para las instantáneas comprimidas tiene secciones alternas de metadatos y datos. Los metadatos del formato original sólo se permite para "reemplazar" operaciones: Reemplazar bloque X en la imagen base con el contenido del bloque Y en la instantánea en. El formato COW de instantáneas comprimidas es más expresivo y admite tres operaciones:

  • Copia - bloque X en el dispositivo de base debe ser reemplazado con el bloque Y en el dispositivo de base.
  • Reemplazar - bloque X en el dispositivo de base debe ser reemplazado por el contenido de bloque Y en la instantánea. Cada uno de estos bloques está comprimido en gz.
  • Zero - Bloque X en el dispositivo de base debe ser reemplazado con todos ceros.

Actualizaciones OTA completo consisten en reemplazar y sólo cero operaciones. Actualizaciones incrementales OTA pueden tener, además, las operaciones de copia.

dm-user en Android 12

El módulo del núcleo dm-usuario habilita userspace para implementar dispositivos de bloque mapeador de dispositivos. Una entrada de la tabla dm-usuario crea un dispositivo Varios conforme a /dev/dm-user/<control-name> . Un userspace proceso puede sondear el dispositivo para recibir de lectura y escritura solicitudes del núcleo. Cada solicitud tiene un búfer asociado para que el espacio de usuario se complete (para una lectura) o se propague (para una escritura).

El dm-user módulo del núcleo proporciona una nueva interfaz visible para el usuario para el núcleo que no es parte de la base de código kernel.org aguas arriba. Hasta que sea, Google se reserva el derecho a modificar el dm-user de interfaz de Android.

Snapuserd

El snapuserd componente de espacio de usuario a dm-user implementos Virtual A B Compresión /.

En la versión sin comprimir de Virtual A / B, (ya sea en Android 11 y versiones anteriores, o en Android 12 sin la opción de instantánea comprimida), el dispositivo COW es un archivo sin formato. Cuando la compresión está activada, las funciones de vaca en su lugar como un dm-user del dispositivo, que está conectado a una instancia de la snapuserd daemon.

El kernel no usa el nuevo formato COW. Por lo que el snapuserd componente traduce solicitudes entre el formato VACA Android y el núcleo que está incorporado en el formato:

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

Diagrama de flujo de la Figura 3. snapuserd como traductor entre Android y el núcleo formatos COW

Esta traducción y descompresión nunca ocurre en el disco. Los snapuserd componente intercepta la vaca lecturas y escrituras que se producen en el núcleo, e implementos de ellos utilizando el formato VACA Android.

Procesos de compresión virtual A / B

Estas secciones proporcionan detalles sobre los procesos utilizados en la compresión A / B virtual: lectura de metadatos, fusión y realización de transiciones de inicio.

Leer metadatos

Los metadatos se construye mediante un snapuserd daemon. Los metadatos son principalmente un mapeo de 2 ID, 8 bytes cada uno, que representan los sectores que se fusionarán. En dm-snapshot que se llama como disk_exception .

struct disk_exception {
    uint64_t old_chunk;
    uint64_t new_chunk;
};

Se utiliza una excepción de disco cuando un fragmento de datos antiguo se reemplaza por uno nuevo.

A Snapuserd daemon lee el archivo COW interna a través de la biblioteca COW y construye los metadatos para cada una de las operaciones COW presente en el archivo COW.

Los metadatos se lee iniciada desde el dm-snapshot en el núcleo cuando la dm- snapshot se crea dispositivo.

La siguiente figura proporciona un diagrama de secuencia para la ruta IO para la construcción de metadatos.

Sequence diagram, IO path for metadata construction

Figura 4. Secuencia de flujo para la ruta de IO en la construcción de metadatos

Fusión

Una vez que el proceso de arranque se ha completado, las marcas de actualización del motor la ranura como inicio correcto e inicia la fusión de la conmutación del dm-snapshot de destino a la dm-snapshot-merge objetivo.

dm-snapshot camina a través de los metadatos e inicia una combinación de IO para cada excepción disco. A continuación se muestra una descripción general de alto nivel de la ruta de fusión de E / S.

Merge IO path

Figura 5. Combinar visión general trayectoria IO

Si el dispositivo se reinicia durante el proceso de combinación, la combinación se reanuda en el siguiente reinicio y se completa la combinación.

Transiciones de inicio

Cuando se arranca con instantáneas comprimidas, el inicio de la primera etapa debe comenzar snapuserd montar particiones. Esto plantea un problema: Cuando sepolicy es cargado y ejecutado, snapuserd se puso en el contexto equivocado, y sus peticiones de lectura fallan, con negaciones de SELinux.

Para abordar esto, snapuserd transiciones en bloqueo de paso con init , como sigue:

  1. La primera etapa init lanzamientos snapuserd del disco RAM, y guarda un archivo descriptor abierto a ella en una variable de entorno.
  2. La primera etapa init cambia el sistema de ficheros raíz de la partición del sistema, a continuación, ejecuta la copia del sistema de init .
  3. El sistema de copia de init lee el sepolicy combinado en una cadena.
  4. Init invoca mlock() páginas en toda la copia de ext4. A continuación, se desactivan todas las tablas del mapeador de dispositivos para dispositivos de instantáneas, y se detiene snapuserd . Después de esto, está prohibido leer desde particiones, ya que hacerlo provoca un punto muerto.
  5. Utilizando el descriptor abierta a la copia del disco de memoria de snapuserd , init relanza el demonio con el contexto SELinux correcto. Se reactivan las tablas de asignación de dispositivos para dispositivos de instantáneas.
  6. Invoca init munlockall() - que es seguro para llevar a cabo IO disponible.

Uso del espacio

La siguiente tabla proporciona una comparación del uso de espacio para diferentes mecanismos OTA que utilizan los tamaños de OTA y SO de Pixel.

Impacto de tamaño no A / B A / B Virtual A / B Virtual A / B (comprimido)
Imagen original de fábrica 4,5 GB super (imagen 3.8g + 700M reservados) 1 9GB super (3.8G + 700M reservados, para dos ranuras) 4.5GB super (imagen 3.8G + 700M reservados) 4.5GB super (imagen 3.8G + 700M reservados)
Otras particiones estáticas /cache Ninguno Ninguno Ninguno
Almacenamiento adicional durante OTA (espacio volvió después de aplicar OTA) 1,4 GB en / datos 0 3,8 GB 2 en / data 2,1 GB 2 en / data
Almacenamiento total requerido para aplicar OTA 5.9GB 3 (super y datos) 9GB (super) 8,3 GB 3 (super y datos) 6.6GB 3 (super y datos)

1 Indica el diseño supuesto en base a Pixel mapeo.

2 Asume nueva imagen del sistema es del mismo tamaño que el original.

3 Espacio necesario es transitoria hasta reiniciar.

Para poner en práctica virtual A / B, o para utilizar las capacidades de instantáneas comprimidas, consulte Implementación de Virtual A / B