ภาพรวม A/B เสมือน

Android มีกลไกการอัปเดตสองแบบ: การอัปเดต A/B (ที่ราบรื่น) และการอัปเดตที่ไม่ใช่ A/B เพื่อลดความซับซ้อนของโค้ดและปรับปรุงกระบวนการอัปเดต ใน Android 11 กลไกทั้งสองจะรวมเป็นหนึ่งเดียวผ่าน A/B เสมือนเพื่อนำการอัปเดตที่ราบรื่นมาสู่อุปกรณ์ทั้งหมดด้วยต้นทุนพื้นที่จัดเก็บที่ลดลง Android 12 เสนอตัวเลือกของการบีบอัด Virtual A/B เพื่อบีบอัดพาร์ติชั่นสแน็ปช็อต ทั้งใน Android 11 และ Android 12 มีข้อกำหนดดังต่อไปนี้:

  • เสมือน A / B การปรับปรุงเป็นอย่างราบรื่นเช่นปรับปรุง / B การอัปเดต A/B เสมือนช่วยลดเวลาที่อุปกรณ์ออฟไลน์และไม่สามารถใช้งานได้
  • การปรับปรุง A / B เสมือนสามารถรีดกลับ หากระบบปฏิบัติการใหม่ไม่สามารถบู๊ตได้ อุปกรณ์จะย้อนกลับเป็นเวอร์ชันก่อนหน้าโดยอัตโนมัติ
  • ปรับปรุงเสมือน / 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-snapshot

เสมือน A / B อาศัย dm-snapshot โมดูลอุปกรณ์ mapper สำหรับ snapshotting สถานะของอุปกรณ์จัดเก็บข้อมูลที่ เมื่อใช้ dm-snapshot มีสี่อุปกรณ์ในการเล่น:

  • อุปกรณ์ฐานเป็นอุปกรณ์ที่ snapshotted ในหน้านี้ อุปกรณ์หลักจะเป็นพาร์ติชันแบบไดนามิกเสมอ เช่น ระบบหรือผู้ขาย
  • สำเนาเมื่อเขียน (COW) อุปกรณ์สำหรับการเปลี่ยนแปลงเข้าสู่ระบบไปยังอุปกรณ์ฐาน ขนาดใดก็ได้ แต่ต้องใหญ่พอที่จะรองรับการเปลี่ยนแปลงทั้งหมดกับอุปกรณ์พื้นฐาน
  • อุปกรณ์ภาพรวมที่ถูกสร้างขึ้นโดยใช้ snapshot เป้าหมาย การเขียนไปยังอุปกรณ์สแน็ปช็อตจะถูกเขียนไปยังอุปกรณ์ COW อ่านจากอุปกรณ์สแนปชอตจะอ่านจากอุปกรณ์พื้นฐานหรืออุปกรณ์ COW ทั้งนี้ขึ้นอยู่กับว่าข้อมูลที่ถูกเข้าถึงมีการเปลี่ยนแปลงโดยสแน็ปช็อตหรือไม่
  • อุปกรณ์กำเนิดที่ถูกสร้างขึ้นโดยใช้ snapshot-origin เป้าหมาย อ่านไปยังอุปกรณ์ต้นทางที่อ่านโดยตรงจากอุปกรณ์ฐาน เขียนไปยังอุปกรณ์ต้นทางเขียนโดยตรงไปยังอุปกรณ์ฐาน แต่ข้อมูลดั้งเดิมจะถูกสำรองโดยการเขียนไปยังอุปกรณ์ COW

Device mapping for dm-snapshot

รูปที่ 2 การทำแผนที่ของอุปกรณ์สำหรับ DM-ภาพรวม

สแนปชอตที่บีบอัด

ใน Android 12 เพราะต้องการพื้นที่ใน /data พาร์ทิชันสามารถสูงคุณสามารถเปิดใช้การบีบอัดภาพรวมในการสร้างของคุณที่อยู่ที่ต้องการพื้นที่ที่สูงขึ้นของ /data พาร์ทิชัน

สแน็ปช็อตที่บีบอัด A/B เสมือนสร้างขึ้นจากสององค์ประกอบใหม่ที่มีอยู่ใน Android 12:

  • dm-user โมดูลเคอร์เนลที่คล้ายกับฟิวส์ที่ช่วยให้ userspace จะใช้อุปกรณ์ป้องกัน
  • snapuserd , ภูต userspace จะใช้รูปแบบภาพรวมใหม่

ส่วนประกอบเหล่านี้เปิดใช้งานการบีบอัด เปลี่ยนแปลงที่จำเป็นอื่น ๆ ที่ทำในการดำเนินการภาพรวมการบีบอัดความสามารถในการที่จะได้รับในหัวข้อถัดไป: รูปแบบวัวสำหรับภาพรวมการบีบอัด , DM-ผู้ใช้ และ Snapuserd

รูปแบบ COW สำหรับสแน็ปช็อตที่บีบอัด

ใน Android 12 สแน็ปช็อตที่บีบอัดจะใช้รูปแบบ COW ใหม่ คล้ายกับรูปแบบในตัวของเคอร์เนลที่ใช้สำหรับสแน็ปช็อตที่ไม่มีการบีบอัด รูปแบบ COW สำหรับสแน็ปช็อตที่บีบอัดมีส่วนของข้อมูลเมตาและข้อมูลสลับกัน เมตาดาต้ารูปแบบเดิมที่ได้รับอนุญาตเท่านั้นสำหรับ "แทนที่" การดำเนินงาน: แทนที่บล็อก X ในภาพฐานที่มีเนื้อหาของบล็อก Y ในภาพรวมนั้น รูปแบบ COW ของสแนปชอตที่บีบอัดนั้นสื่ออารมณ์ได้มากกว่าและรองรับการทำงานสามอย่าง:

  • คัดลอก - Block X ในเครื่องฐานจะถูกแทนที่ด้วยบล็อก Y ในอุปกรณ์ฐาน
  • แทนที่ - Block X ในเครื่องฐานควรจะถูกแทนที่ด้วยเนื้อหาของบล็อก Y ในภาพรวมนั้น แต่ละบล็อคเหล่านี้ถูกบีบอัด gz
  • ศูนย์ - Block X ในเครื่องฐานจะถูกแทนที่ด้วยเลขศูนย์ทั้งหมด

การปรับปรุงแบบเต็ม OTA ประกอบด้วยแทนที่และศูนย์การดำเนินงานเท่านั้น การปรับปรุงที่เพิ่มขึ้นนอกจากนี้ OTA สามารถมีดำเนินการคัดลอก

dm-user ใน Android 12

โมดูล DM-ใช้เคอร์เนลช่วย userspace จะใช้อุปกรณ์อุปกรณ์ mapper บล็อก รายการตาราง DM-ผู้ใช้สร้างอุปกรณ์อื่น ๆ ภายใต้ /dev/dm-user/<control-name> userspace กระบวนการสามารถสำรวจอุปกรณ์ที่จะได้รับการร้องขอการอ่านและเขียนจากเมล็ด คำขอแต่ละรายการมีบัฟเฟอร์ที่เกี่ยวข้องสำหรับ userspace เพื่อเติมข้อมูล (สำหรับการอ่าน) หรือเผยแพร่ (สำหรับการเขียน)

dm-user เคอร์เนลโมดูลมีอินเตอร์เฟซผู้ใช้มองเห็นใหม่เคอร์เนลที่ไม่ได้เป็นส่วนหนึ่งของต้นน้ำฐานรหัส kernel.org จนกว่าจะมี Google ขอสงวนสิทธิ์ในการปรับเปลี่ยน dm-user อินเตอร์เฟซใน Android

Snapuserd

snapuserd องค์ประกอบ userspace เพื่อ 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 ดักส่วนประกอบวัวอ่านและการเขียนที่เกิดขึ้นใน kernel และดำเนินการโดยใช้รูปแบบวัว Android

กระบวนการบีบอัด A/B เสมือน

ส่วนเหล่านี้ให้รายละเอียดเกี่ยวกับกระบวนการที่ใช้ในการบีบอัด Virtual A/B: การอ่านข้อมูลเมตา การผสาน และการดำเนินการเปลี่ยนเริ่มต้น

การอ่านข้อมูลเมตา

เมตาดาต้าถูกสร้างโดย snapuserd ภูต ข้อมูลเมตาส่วนใหญ่เป็นการแมปของ 2 ID แต่ละตัว 8 ไบต์ ซึ่งเป็นตัวแทนของเซกเตอร์ที่จะรวมเข้าด้วยกัน ใน dm-snapshot ก็เรียกว่าเป็น disk_exception

struct disk_exception {
    uint64_t old_chunk;
    uint64_t new_chunk;
};

ข้อยกเว้นของดิสก์จะใช้เมื่อกลุ่มข้อมูลเก่าถูกแทนที่ด้วยข้อมูลใหม่

Snapuserd ภูตอ่านแฟ้มวัวภายในผ่านห้องสมุดวัวและสร้างเมตาสำหรับแต่ละของการดำเนินงาน COW ปัจจุบันในแฟ้มวัว

เมตาดาต้าอ่านจะเริ่มต้นจาก dm-snapshot ใน kernel เมื่อ dm- snapshot อุปกรณ์จะถูกสร้างขึ้น

รูปด้านล่างแสดงแผนภาพลำดับสำหรับเส้นทาง IO สำหรับการสร้างข้อมูลเมตา

Sequence diagram, IO path for metadata construction

รูปที่ 4 การไหลลำดับสำหรับเส้นทาง IO ในการก่อสร้างเมตาดาต้า

ผสาน

เมื่อขั้นตอนการบูตเสร็จสมบูรณ์เครื่องหมายการปรับปรุงโปรแกรมสล็อตเป็นบูตที่ประสบความสำเร็จและเริ่มต้นการผสานโดยเปลี่ยน dm-snapshot เป้าหมายไป dm-snapshot-merge เป้าหมาย

dm-snapshot เดินผ่านข้อมูลเมตาและเริ่มต้นการผสาน IO ข้อยกเว้นแต่ละดิสก์ ภาพรวมระดับสูงของพาธการผสาน IO แสดงอยู่ด้านล่าง

Merge IO path

รูปที่ 5 ผสานภาพรวมเส้นทาง IO

หากรีบูตอุปกรณ์ระหว่างกระบวนการผสาน การผสานจะดำเนินการต่อในการรีบูตครั้งถัดไป และการผสานจะเสร็จสมบูรณ์

เริ่มต้นช่วงการเปลี่ยนภาพ

เมื่อบูตกับภาพรวมการบีบอัดที่ init ขั้นตอนแรกจะต้องเริ่มต้น snapuserd จะติดพาร์ทิชัน โพสท่านี้เป็นปัญหา: เมื่อ sepolicy มีการโหลดและการบังคับใช้ snapuserd ได้รับการใส่ในบริบทที่ไม่ถูกต้องและการร้องขอการอ่านของมันล้มเหลวกับการปฏิเสธ selinux

เพื่อแก้ปัญหานี้ snapuserd เปลี่ยนในการล็อคขั้นตอนที่มี init ดังต่อไปนี้:

  1. ขั้นตอนแรก init เปิดตัว snapuserd จาก ramdisk และช่วยเปิดไฟล์บ่งถึงในตัวแปรสภาพแวดล้อม
  2. ขั้นตอนแรก init สวิทช์ระบบแฟ้มรากพาร์ทิชันระบบจากนั้นดำเนินการสำเนาระบบการทำงานของ init
  3. สำเนาระบบการทำงานของ init อ่าน sepolicy รวมเป็นสตริง
  4. Init จะเรียก mlock() หน้าในทุก ext4 ได้รับการสนับสนุน จากนั้นจะยกเลิกการใช้งานทุกตารางอุปกรณ์ mapper สำหรับอุปกรณ์ภาพรวมและหยุด snapuserd หลังจากนี้ห้ามมิให้อ่านจากพาร์ติชั่นเนื่องจากการทำเช่นนั้นทำให้เกิดการหยุดชะงัก
  5. ใช้บ่งเปิดให้สำเนา ramdisk ของ snapuserd , init relaunches ภูตกับบริบท selinux ที่ถูกต้อง ตาราง Device-mapper สำหรับอุปกรณ์สแน็ปช็อตถูกเปิดใช้งานอีกครั้ง
  6. จะเรียก init munlockall() - มันปลอดภัยที่จะดำเนินการ IO อีกครั้ง

การใช้พื้นที่

ตารางต่อไปนี้แสดงการเปรียบเทียบการใช้พื้นที่สำหรับกลไก OTA ต่างๆ โดยใช้ขนาด OS และ OTA ของ Pixel

ขนาดผลกระทบ ไม่ใช่ A/B A/B เสมือน A/B A/B เสมือน (บีบอัด)
ภาพโรงงานเดิม 4.5GB ซุปเปอร์ (ภาพที่ 3.8G + 700M ลิขสิทธิ์) 1 9GB super (สงวนไว้ 3.8G + 700M สำหรับสองช่อง) ซุปเปอร์ 4.5GB (ภาพ 3.8G + สงวนไว้ 700M) ซุปเปอร์ 4.5GB (ภาพ 3.8G + สงวนไว้ 700M)
พาร์ติชั่นแบบคงที่อื่นๆ /cache ไม่มี ไม่มี ไม่มี
พื้นที่เก็บข้อมูลเพิ่มเติมในช่วง OTA (พื้นที่กลับมาหลังจากใช้ OTA) เปิด /data . 1.4GB 0 3.8GB 2 / ข้อมูล 2.1GB 2 / ข้อมูล
พื้นที่เก็บข้อมูลทั้งหมดที่ต้องใช้เพื่อใช้ OTA 5.9GB 3 (สุดและข้อมูล) 9GB (ซุปเปอร์) 8.3GB 3 (สุดและข้อมูล) 6.6GB 3 (สุดและข้อมูล)

1 ระบุรูปแบบสันนิษฐานว่าขึ้นอยู่กับการทำแผนที่พิกเซล

2 ถือว่าภาพระบบใหม่เป็นขนาดเดียวกับต้นฉบับ

3 ความต้องการพื้นที่ชั่วคราวจนกว่าจะรีบูต

ในการดำเนินการเสมือน A / B หรือจะใช้ความสามารถในการบีบอัดภาพรวมดู การดำเนินการเสมือน A / B