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

A/B เสมือนเป็นกลไกการอัปเดตหลักของ Android A/B เสมือนจะอิงตามการอัปเดต A/B เดิม (ดูการอัปเดตระบบ A/B) และไม่ใช่ A/B ซึ่งเลิกใช้งานใน 15 เพื่อลดพื้นที่เก็บข้อมูลส่วนเกินของการอัปเดต

จริงๆ แล้ว A/B เสมือนไม่มีสล็อตเพิ่มเติมสําหรับพาร์ติชันแบบไดนามิก โปรดดูพาร์ติชันแบบไดนามิก แต่ระบบจะเขียนข้อมูลส่วนต่างลงในสแนปชอต แล้วผสานเข้ากับพาร์ติชันฐานหลังจากยืนยันว่าการบูตสำเร็จ A/B เสมือนใช้รูปแบบสแนปชอตเฉพาะ Android ดูรูปแบบ COW สำหรับสแนปชอตที่บีบอัด ซึ่งช่วยให้บีบอัดสแนปชอตและลดการใช้พื้นที่ในดิสก์ได้ เมื่อใช้ OTA เต็มรูปแบบ ขนาดสแนปชอตจะลดลงประมาณ 45% เมื่อบีบอัด และขนาดสแนปชอตของ OTA ที่เพิ่มขึ้นจะลดลงประมาณ 55%

Android 12 มีตัวเลือกการบีบอัด A/B เสมือนจริงเพื่อบีบอัดพาร์ติชันที่บันทึกภาพไว้ การทดสอบ A/B เสมือนมีข้อดีดังนี้

  • การอัปเดต A/B เสมือนจะราบรื่น (การอัปเดตจะทํางานในเบื้องหลังทั้งหมดขณะที่อุปกรณ์ทํางานอยู่) เช่นเดียวกับการอัปเดต A/B การอัปเดต A/B เสมือนจะลดเวลาที่อุปกรณ์ออฟไลน์และใช้งานไม่ได้
  • การอัปเดต A/B เสมือนจริงจะเปลี่ยนกลับได้ หากระบบปฏิบัติการใหม่บูตไม่สำเร็จ อุปกรณ์จะเปลี่ยนกลับไปเป็นเวอร์ชันก่อนหน้าโดยอัตโนมัติ
  • การอัปเดต A/B เสมือนจะใช้พื้นที่เพิ่มเติมขั้นต่ำโดยการทำซ้ำเฉพาะพาร์ติชันที่ Bootloader ใช้เท่านั้น ส่วนพาร์ติชันอื่นๆ ที่อัปเดตได้จะสแนปชอตไว้

ความเป็นมาและคำศัพท์

ส่วนนี้จะอธิบายคําศัพท์และเทคโนโลยีที่รองรับการทดสอบ A/B เสมือนจริง ในระหว่างการติดตั้ง OTA ระบบจะเขียนข้อมูลระบบปฏิบัติการใหม่ลงในช่องใหม่สำหรับพาร์ติชันจริง หรืออุปกรณ์ COW สำหรับ Android โดยเฉพาะ หลังจากรีบูตอุปกรณ์แล้ว ระบบจะผสานข้อมูลพาร์ติชันแบบไดนามิกกลับไปยังอุปกรณ์พื้นฐานผ่านการใช้ dm-user และเดรัม snapuserd กระบวนการนี้จะดำเนินการทั้งหมดในพื้นที่ผู้ใช้

Device-mapper

Device-mapper เป็นเลเยอร์บล็อกเสมือนของ Linux ที่ใช้บ่อยใน Android เมื่อใช้พาร์ติชันแบบไดนามิก พาร์ติชันอย่าง /system จะเป็นกองอุปกรณ์ที่ซ้อนกัน ดังนี้

  • ที่ด้านล่างของกองคือพาร์ติชัน super จริง (เช่น /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

การซ้อนพาร์ติชันใต้ระบบ

รูปที่ 1 กองซ้อนใต้จุดต่อเชื่อม /system

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

ใน Android 12 ขึ้นไป เนื่องจากข้อกำหนดด้านพื้นที่ในพาร์ติชัน /data อาจสูง คุณจึงเปิดใช้สแนปชอตแบบบีบอัดในบิลด์เพื่อตอบสนองข้อกำหนดด้านพื้นที่ที่สูงขึ้นของพาร์ติชัน /data ได้

ภาพรวมแบบ A/B ที่บีบอัดเสมือนสร้างขึ้นจากคอมโพเนนต์ต่อไปนี้ซึ่งพร้อมใช้งานใน Android 12 ขึ้นไป

  • dm-user ซึ่งเป็นโมดูลเคอร์เนลที่คล้ายกับ FUSE ซึ่งช่วยให้พื้นที่ผู้ใช้ใช้อุปกรณ์บล็อกได้
  • snapuserd ซึ่งเป็นเดรัมใน Userspace เพื่อใช้รูปแบบสแนปชอตใหม่

คอมโพเนนต์เหล่านี้ช่วยให้การบีบอัดทำงานได้ ดูการเปลี่ยนแปลงที่จําเป็นอื่นๆ ในการใช้งานความสามารถของสแนปชอตที่บีบอัดไว้ในส่วนถัดไป ได้แก่ รูปแบบ COW สําหรับสแนปชอตที่บีบอัด, dm-user และ snapuserd

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

ใน Android 12 ขึ้นไป สแนปชอตที่บีบอัดจะใช้รูปแบบ COW สำหรับ Android โดยเฉพาะ รูปแบบ COW มีข้อมูลเมตาเกี่ยวกับ OTA และมีบัฟเฟอร์ที่ต่างกันซึ่งมีการดำเนินการ COW และข้อมูลระบบปฏิบัติการใหม่ เมื่อเทียบกับรูปแบบสแนปชอตเคอร์เนลซึ่งอนุญาตให้ใช้เฉพาะการดำเนินการแทนที่ (แทนที่บล็อก X ในอิมเมจฐานด้วยเนื้อหาของบล็อก Y ในสแนปชอต) รูปแบบ COW ที่บีบอัดของ Android นั้นสื่อความหมายได้ดีกว่าและรองรับการดำเนินการต่อไปนี้

  • คัดลอก: ควรแทนที่บล็อก X ในอุปกรณ์ฐานด้วยบล็อก Y ในอุปกรณ์ฐาน
  • แทนที่: ควรแทนที่เนื้อหาของบล็อก X ในอุปกรณ์ฐานด้วยเนื้อหาของบล็อก Y ในสแนปชอต แต่ละบล็อกมีการบีบอัด gz
  • 0: ควรเปลี่ยนบล็อก X ในอุปกรณ์พื้นฐานด้วยเลข 0 ทั้งหมด
  • XOR: อุปกรณ์ COW จะจัดเก็บไบต์ที่บีบอัดด้วย XOR ระหว่างบล็อก X กับบล็อก Y (พร้อมใช้งานใน Android 13 ขึ้นไป)

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

เลย์เอาต์สแนปชอตแบบเต็มในดิสก์จะมีลักษณะดังนี้

รูปแบบวัว

รูปที่ 2 รูปแบบ COW ของ Android ในดิสก์

dm-user

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

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

snapuserd

คอมโพเนนต์พื้นที่ผู้ใช้ snapuserd ของ dm-user จะใช้การบีบอัด A/B เสมือน Snapuserd เป็นเดรัมน์สเปซผู้ใช้ที่รับผิดชอบการเขียนและการอ่านอุปกรณ์ COW ของ Android I/O ทั้งหมดไปยังสแนปชอตต้องผ่านบริการนี้ ในระหว่างการติดตั้ง OTA ระบบจะเขียนข้อมูลระบบปฏิบัติการใหม่ลงในสแนปชอตโดย snapuserd (มีการบีบอัด) นอกจากนี้ ระบบจะจัดการการแยกวิเคราะห์ข้อมูลเมตาและการแตกไฟล์ข้อมูลบล็อกใหม่ที่นี่ด้วย

การบีบอัด XOR

สำหรับอุปกรณ์ที่เปิดตัวด้วย Android 13 ขึ้นไป ฟีเจอร์การบีบอัด XOR ซึ่งเปิดใช้โดยค่าเริ่มต้นจะเปิดใช้สแนปชอตพื้นที่ผู้ใช้เพื่อจัดเก็บไบต์ที่บีบอัดด้วย XOR ระหว่างบล็อกเก่ากับบล็อกใหม่ เมื่อมีการอัปเดต A/B เสมือนและมีการเปลี่ยนแปลงเพียงไม่กี่ไบต์ในบล็อก รูปแบบพื้นที่เก็บข้อมูลการบีบอัด XOR จะใช้พื้นที่น้อยกว่ารูปแบบพื้นที่เก็บข้อมูลเริ่มต้น เนื่องจากสแนปชอตไม่ได้จัดเก็บไบต์ 4K เต็ม การลดขนาดภาพรวมนี้เป็นไปได้เนื่องจากข้อมูล XOR มีเลข 0 จำนวนมากและบีบอัดได้ง่ายกว่าข้อมูลบล็อกดิบ ในอุปกรณ์ Pixel การบีบอัด XOR จะลดขนาดสแนปชอตลง 25% ถึง 40%

สำหรับอุปกรณ์ที่อัปเกรดเป็น Android 13 ขึ้นไป คุณต้องเปิดใช้การบีบอัด XOR โปรดดูรายละเอียดที่หัวข้อการบีบอัด XOR

ผสานสแนปชอต

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

ข้อมูลต่อไปนี้อธิบายกระบวนการบีบอัด A/B เสมือน

  1. เฟรมเวิร์กจะต่อเชื่อมพาร์ติชัน /system จากอุปกรณ์ dm-verity ซึ่งวางซ้อนอยู่บนอุปกรณ์ dm-user ซึ่งหมายความว่าระบบจะกำหนดเส้นทาง I/O ทั้งหมดจากระบบไฟล์รูทไปยัง dm-user
  2. dm-user จะกำหนดเส้นทาง I/O ไปยัง D snapuserd ของพื้นที่ผู้ใช้ ซึ่งจะจัดการคำขอ I/O
  3. เมื่อการผสานเสร็จสมบูรณ์แล้ว เฟรมเวิร์กจะยุบ dm-verity ไว้ด้านบน dm-linear (system_base) และนํา dm-user ออก

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

รูปที่ 3 กระบวนการบีบอัด A/B เสมือนจริง

กระบวนการผสานสแนปชอตอาจถูกขัดจังหวะ หากรีบูตอุปกรณ์ระหว่างกระบวนการผสาน ระบบจะผสานต่อหลังจากรีบูต

เริ่มการเปลี่ยน

เมื่อบูตด้วยสแนปชอตที่บีบอัดไว้ อินิจต์ระยะที่ 1 จะต้องเริ่มต้นขึ้นเพื่อมาунтพาร์ติชัน snapuserd การดำเนินการนี้ทำให้เกิดปัญหา เมื่อโหลดและบังคับใช้ sepolicy ระบบจะใส่ snapuserd ไว้ในบริบทที่ไม่ถูกต้อง และคำขออ่านจะดำเนินการไม่สำเร็จเนื่องจากถูกปฏิเสธโดย SELinux

ในการแก้ปัญหานี้ snapuserd จะเปลี่ยนในขั้นตอนล็อกด้วย init ดังนี้

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

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

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

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

1 ระบุเลย์เอาต์ที่คาดการณ์ตามการแมปพิกเซล

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

3ข้อกำหนดด้านพื้นที่จะเป็นชั่วคราวจนกว่าจะรีบูต

การทดสอบ A/B เสมือนของ Android 11

Android 11 ของ Virtual A/B เขียนลงในพาร์ติชันแบบไดนามิกโดยใช้รูปแบบ COW ของเคอร์เนล ในที่สุดเราก็เลิกใช้งานรูปแบบนี้เนื่องจากรูปแบบ COW ของเคอร์เนลไม่รองรับการบีบอัด

การทดสอบ A/B เสมือนของ Android 12

ใน Android 12 ระบบจะรองรับการบีบอัดในรูปแบบ COW สำหรับ Android โดยเฉพาะ A/B เสมือนจริงเวอร์ชันนี้จำเป็นต้องมีการแปล COW สำหรับ Android โดยเฉพาะเป็นรูปแบบ COW ของ Kernel ในที่สุด เราได้แทนที่ฟีเจอร์นี้ใน Android 13 ซึ่งทำให้ไม่ต้องใช้รูปแบบ COW ของ Kernel และ dm-snapshot

หากต้องการใช้ Virtual A/B หรือใช้ความสามารถของสแนปชอตที่บีบอัด โปรดดูหัวข้อการใช้ Virtual A/B