نمای کلی A/B مجازی

اندروید دو مکانیسم به‌روزرسانی دارد: به‌روزرسانی‌های A/B (بدون درز) و به‌روزرسانی‌های غیر A/B. برای کاهش پیچیدگی کد و بهبود فرآیند به‌روزرسانی، در اندروید 11 این دو مکانیسم از طریق A/B مجازی متحد شده‌اند تا به‌روزرسانی‌های یکپارچه را برای همه دستگاه‌ها با حداقل هزینه ذخیره‌سازی ارائه کنند. اندروید 12 گزینه فشرده سازی مجازی A/B را برای فشرده سازی پارتیشن های عکس فوری ارائه می دهد. در اندروید 11 و اندروید 12 موارد زیر اعمال می شود:

  • به‌روزرسانی‌های مجازی A/B مانند به‌روزرسانی‌های A/B یکپارچه هستند. به‌روزرسانی‌های مجازی A/B زمان آفلاین بودن و غیرقابل استفاده بودن دستگاه را به حداقل می‌رسانند.
  • به‌روزرسانی‌های مجازی A/B را می‌توان برگرداند . اگر سیستم عامل جدید راه اندازی نشود، دستگاه ها به طور خودکار به نسخه قبلی برمی گردند.
  • به‌روزرسانی‌های مجازی A/B با کپی کردن تنها پارتیشن‌هایی که توسط بوت‌لودر استفاده می‌شوند ، از حداقل فضای اضافی استفاده می‌کنند. سایر پارتیشن‌های قابل به‌روزرسانی عکس‌برداری شده‌اند .

پیشینه و اصطلاحات

این بخش اصطلاحات را تعریف می کند و فناوری را که از A/B مجازی پشتیبانی می کند، توضیح می دهد.

نقشه‌بردار دستگاه

Device-mapper یک لایه بلوک مجازی لینوکس است که اغلب در اندروید استفاده می شود. با پارتیشن های پویا ، پارتیشن هایی مانند /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 ، یک ماژول نقشه‌بردار دستگاه برای گرفتن عکس فوری از وضعیت یک دستگاه ذخیره‌سازی متکی است. هنگام استفاده از dm-snapshot ، چهار دستگاه در حال بازی هستند:

  • دستگاه پایه دستگاهی است که عکس فوری گرفته می شود. در این صفحه، دستگاه پایه همیشه یک پارتیشن پویا است، مانند سیستم یا فروشنده.
  • دستگاه کپی در نوشتن (COW)، برای ثبت تغییرات در دستگاه پایه. این می تواند هر اندازه ای باشد، اما باید به اندازه کافی بزرگ باشد تا تمام تغییرات دستگاه پایه را در خود جای دهد.
  • دستگاه عکس فوری با استفاده از هدف snapshot ایجاد می شود. نوشته های روی دستگاه عکس فوری در دستگاه COW نوشته می شود. بسته به اینکه داده های مورد دسترسی توسط عکس فوری تغییر کرده باشند، از دستگاه عکس فوری خوانده می شود یا از دستگاه پایه یا دستگاه COW.
  • دستگاه مبدا با استفاده از snapshot-origin target ایجاد می شود. به دستگاه مبدأ می خواند که مستقیماً از دستگاه پایه خوانده می شود. در دستگاه مبدأ مستقیماً روی دستگاه پایه می‌نویسد، اما از داده‌های اصلی با نوشتن در دستگاه COW پشتیبان‌گیری می‌شود.

Device mapping for dm-snapshot

شکل 2. نقشه برداری دستگاه برای dm-snapshot

عکس های فوری فشرده شده

در اندروید 12 و بالاتر، از آنجایی که فضای مورد نیاز در پارتیشن /data می‌تواند زیاد باشد، می‌توانید عکس‌های فوری فشرده‌شده را در ساخت خود فعال کنید تا فضای مورد نیاز پارتیشن /data را برطرف کند.

عکس‌های فوری فشرده A/B مجازی بر روی اجزای زیر ساخته شده‌اند که در اندروید ۱۲ و بالاتر در دسترس هستند:

  • dm-user ، یک ماژول هسته شبیه به FUSE که به فضای کاربران اجازه می دهد تا دستگاه های بلوک را پیاده سازی کنند.
  • snapuserd ، یک دیمون فضای کاربران برای پیاده سازی یک قالب عکس فوری جدید.

این اجزا باعث فشرده سازی می شوند. سایر تغییرات لازم برای اجرای قابلیت‌های snapshot فشرده در بخش‌های بعدی آورده شده است: فرمت COW برای عکس‌های فوری فشرده ، dm-user و Snapuserd .

فرمت COW برای عکس های فوری فشرده

در اندروید ۱۲ و بالاتر، عکس‌های فوری فشرده از فرمت COW استفاده می‌کنند. مشابه فرمت داخلی هسته که برای عکس‌های فوری غیرفشرده استفاده می‌شود، فرمت COW برای عکس‌های فوری فشرده دارای بخش‌های متناوب متادیتا و داده است. فراداده قالب اصلی فقط برای عملیات جایگزینی مجاز است: بلوک X را در تصویر پایه با محتوای بلوک Y در عکس فوری جایگزین کنید. فرمت عکس های فوری فشرده COW گویاتر است و از عملیات زیر پشتیبانی می کند:

  • کپی : بلوک X در دستگاه پایه باید با بلوک Y در دستگاه پایه جایگزین شود.
  • جایگزینی : بلوک X در دستگاه پایه باید با محتویات بلوک Y در عکس فوری جایگزین شود. هر کدام از این بلوک ها به صورت gz فشرده شده است.
  • صفر : بلوک X در دستگاه پایه باید با تمام صفرها جایگزین شود.
  • XOR : دستگاه COW بایت های فشرده شده XOR را بین بلوک X و بلوک Y ذخیره می کند. (در اندروید 13 و بالاتر موجود است.)

به روز رسانی کامل OTA فقط شامل عملیات جایگزینی و صفر است. به‌روزرسانی‌های OTA افزایشی می‌توانند عملیات کپی نیز داشته باشند.

dm-user در اندروید 12

ماژول هسته dm-user userspace قادر می سازد تا دستگاه های بلوک نقشه برداری دستگاه را پیاده سازی کنند. ورودی جدول dm-user یک دستگاه متفرقه در زیر /dev/dm-user/<control-name> ایجاد می کند. یک فرآیند userspace می تواند دستگاه را برای دریافت درخواست های خواندن و نوشتن از هسته نظرسنجی کند. هر درخواست دارای یک بافر مرتبط برای فضای کاربر است که یا برای پر کردن (برای خواندن) یا انتشار (برای نوشتن) است.

ماژول هسته dm-user یک رابط کاربری قابل مشاهده جدید برای هسته ارائه می کند که بخشی از پایه کد kernel.org بالادستی نیست. تا زمانی که انجام نشده است، گوگل این حق را برای خود محفوظ می دارد که رابط dm-user در اندروید تغییر دهد.

snapuserd

مولفه snapuserd userspace به dm-user فشرده سازی مجازی A/B را پیاده سازی می کند.

در نسخه غیر فشرده Virtual A/B، (چه در اندروید 11 و پایین تر، چه در اندروید 12 بدون گزینه عکس فوری فشرده)، دستگاه COW یک فایل خام است. هنگامی که فشرده سازی فعال است، COW در عوض به عنوان یک دستگاه dm-user عمل می کند که به نمونه ای از دیمون snapuserd متصل است.

هسته از قالب جدید COW استفاده نمی کند. بنابراین مؤلفه snapuserd درخواست ها را بین قالب Android COW و قالب داخلی هسته ترجمه می کند:

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

شکل 3. نمودار جریان snapuserd به عنوان مترجم بین قالب های Android و Kernel COW

این ترجمه و فشرده سازی هرگز روی دیسک اتفاق نمی افتد. مؤلفه snapuserd خواندن و نوشتن COW را که در هسته اتفاق می‌افتد رهگیری می‌کند و با استفاده از قالب Android COW آن‌ها را پیاده‌سازی می‌کند.

فشرده سازی XOR

برای دستگاه‌هایی که با Android 13 و بالاتر راه‌اندازی می‌شوند، ویژگی فشرده‌سازی XOR، که به‌طور پیش‌فرض فعال است، عکس‌های فوری فضای کاربران را قادر می‌سازد تا بایت‌های فشرده‌شده XOR را بین بلوک‌های قدیمی و بلوک‌های جدید ذخیره کنند. هنگامی که تنها چند بایت در یک بلوک در یک به‌روزرسانی مجازی A/B تغییر می‌کند، طرح ذخیره‌سازی فشرده XOR از فضای کمتری نسبت به طرح ذخیره‌سازی پیش‌فرض استفاده می‌کند، زیرا عکس‌های فوری بایت‌های کامل 4K را ذخیره نمی‌کنند. این کاهش در اندازه عکس فوری امکان پذیر است زیرا داده های XOR حاوی صفرهای زیادی است و فشرده سازی آن آسان تر از داده های بلوک خام است. در دستگاه‌های پیکسل، فشرده‌سازی XOR اندازه عکس فوری را ۲۵٪ تا ۴۰٪ کاهش می‌دهد.

برای دستگاه‌هایی که به Android 13 و بالاتر ارتقا می‌یابند، فشرده‌سازی XOR باید فعال باشد. برای جزئیات، فشرده سازی XOR را ببینید.

فرآیندهای فشرده سازی مجازی A/B

این بخش جزئیاتی در مورد فرآیند فشرده سازی مجازی A/B مورد استفاده در اندروید 13 و اندروید 12 ارائه می دهد.

خواندن متادیتا (اندروید 12)

ابرداده توسط یک دیمون snapuserd ساخته شده است. ابرداده در درجه اول نقشه برداری از دو شناسه، هر کدام 8 بایت است که نشان دهنده بخش هایی است که باید ادغام شوند. در dm-snapshot به آن disk_exception می گویند.

struct disk_exception {
    uint64_t old_chunk;
    uint64_t new_chunk;
};

یک استثنای دیسک زمانی استفاده می شود که یک تکه داده قدیمی با یک قطعه جدید جایگزین شود.

یک شبح snapuserd فایل COW داخلی را از طریق کتابخانه COW می خواند و ابرداده را برای هر یک از عملیات COW موجود در فایل COW می سازد.

خواندن فراداده از dm-snapshot در هسته زمانی که دستگاه dm- snapshot ایجاد می شود آغاز می شود.

شکل زیر یک نمودار توالی برای مسیر IO برای ساخت ابرداده ارائه می دهد.

Sequence diagram, IO path for metadata construction

شکل 4. جریان دنباله ای برای مسیر IO در ساخت ابرداده

ادغام (اندروید 12)

پس از تکمیل فرآیند بوت، موتور به‌روزرسانی، اسلات را به‌عنوان بوت موفق علامت‌گذاری می‌کند و با تغییر هدف dm-snapshot به هدف dm-snapshot-merge ادغام را آغاز می‌کند.

dm-snapshot از میان ابرداده ها عبور می کند و یک IO ادغام را برای هر استثنای دیسک آغاز می کند. یک نمای کلی از مسیر ادغام IO در زیر نشان داده شده است.

Merge IO path

شکل 5. نمای کلی مسیر IO را ادغام کنید

اگر دستگاه در طول فرآیند ادغام راه اندازی مجدد شود، ادغام در راه اندازی مجدد بعدی از سر گرفته می شود و ادغام کامل می شود.

لایه بندی Device-mapper

برای دستگاه‌هایی که با Android 13 و بالاتر راه‌اندازی می‌شوند، فرآیندهای ادغام عکس فوری و عکس فوری در فشرده‌سازی مجازی A/B توسط مؤلفه فضای کاربران snapuserd انجام می‌شود. برای دستگاه هایی که به اندروید 13 و بالاتر ارتقا می یابند، این ویژگی باید فعال باشد. برای جزئیات، به ادغام فضای کاربری مراجعه کنید.

در زیر فرآیند فشرده سازی مجازی A/B توضیح داده شده است:

  1. فریم ورک پارتیشن /system را از دستگاه dm-verity که در بالای دستگاه dm-user انباشته شده است نصب می کند. این بدان معناست که هر ورودی/خروجی از سیستم فایل ریشه به dm-user هدایت می شود.
  2. dm-user I/O را به دیمون snapuserd فضای کاربر هدایت می کند که درخواست I/O را مدیریت می کند.
  3. وقتی عملیات ادغام کامل شد، چارچوب dm-verity در بالای dm-linear ( system_base ) جمع می کند و dm-user حذف می کند.

فرآیند فشرده سازی مجازی A/B

شکل 6. فرآیند فشرده سازی مجازی A/B

فرآیند ادغام عکس فوری می تواند قطع شود. اگر دستگاه در حین فرآیند ادغام راه اندازی مجدد شود، فرآیند ادغام پس از راه اندازی مجدد از سر گرفته می شود.

انتقال ها را آغاز کنید

هنگام راه‌اندازی با عکس‌های فوری فشرده، init مرحله اول باید snapuserd برای نصب پارتیشن‌ها شروع کند. این یک مشکل ایجاد می‌کند: وقتی sepolicy بارگذاری و اجرا می‌شود، snapuserd در زمینه اشتباه قرار می‌گیرد و درخواست‌های خواندن آن با رد کردن سلینوکس شکست می‌خورد.

برای رفع این مشکل، snapuserd انتقال در مرحله قفل با init را به صورت زیر انجام دهید:

  1. init مرحله اول snapuserd از ramdisk راه اندازی می کند و یک توصیفگر فایل باز را در یک متغیر محیطی در آن ذخیره می کند.
  2. init مرحله اول سیستم فایل ریشه را به پارتیشن سیستم سوئیچ می کند، سپس نسخه سیستمی init را اجرا می کند.
  3. کپی سیستم init ، sepolicy ترکیبی را در یک رشته می خواند.
  4. Init mlock() در تمام صفحات ext4 فراخوانی می کند. سپس تمام جداول دستگاه-نقشه نگار را برای دستگاه های عکس فوری غیرفعال می کند و snapuserd متوقف می کند. پس از این، خواندن از پارتیشن ها ممنوع است، زیرا انجام این کار باعث بن بست می شود.
  5. با استفاده از توصیفگر باز برای کپی ramdisk snapuserd ، init دیمون را با زمینه سلینوکس درست راه اندازی می کند. جداول Device-mapper برای دستگاه های Snapshot دوباره فعال می شوند.
  6. Init munlockall() را فراخوانی می کند - اجرای مجدد IO بی خطر است.

استفاده از فضا

جدول زیر مقایسه ای از استفاده از فضا برای مکانیسم های OTA مختلف با استفاده از اندازه های سیستم عامل Pixel و OTA ارائه می دهد.

تاثیر اندازه غیر A/B A/B A/B مجازی A/B مجازی (فشرده شده)
تصویر اصلی کارخانه 4.5 گیگابایت فوق العاده (3.8G تصویر + 700M رزرو شده) 1 9 گیگابایت فوق العاده (3.8G + 700M رزرو شده، برای دو اسلات) 4.5 گیگابایت فوق العاده (3.8G تصویر + 700M رزرو شده) 4.5 گیگابایت فوق العاده (3.8G تصویر + 700M رزرو شده)
سایر پارتیشن های ثابت /cache هیچ یک هیچ یک هیچ یک
فضای ذخیره سازی اضافی در طول OTA (فضا پس از اعمال OTA برگردانده شد) 1.4 گیگابایت در /داده 0 3.8 گیگابایت 2 در /داده 2.1 گیگابایت 2 در /داده
کل فضای ذخیره‌سازی مورد نیاز برای اعمال OTA 5.9 گیگابایت 3 (فوق العاده و دیتا) 9 گیگابایت (فوق العاده) 8.3 گیگابایت 3 (فوق العاده و دیتا) 6.6 گیگابایت 3 (فوق العاده و دیتا)

1 طرح‌بندی فرضی را بر اساس نقشه‌برداری پیکسل نشان می‌دهد.

2 فرض می کند که تصویر سیستم جدید به اندازه اصلی است.

3 فضای مورد نیاز تا راه اندازی مجدد موقت است.

برای پیاده سازی Virtual A/B یا استفاده از قابلیت های فشرده شده عکس فوری، به پیاده سازی Virtual A/B مراجعه کنید.

،

اندروید دو مکانیسم به‌روزرسانی دارد: به‌روزرسانی‌های A/B (بدون درز) و به‌روزرسانی‌های غیر A/B. برای کاهش پیچیدگی کد و بهبود فرآیند به‌روزرسانی، در اندروید 11 این دو مکانیسم از طریق A/B مجازی متحد شده‌اند تا به‌روزرسانی‌های یکپارچه را برای همه دستگاه‌ها با حداقل هزینه ذخیره‌سازی ارائه کنند. اندروید 12 گزینه فشرده سازی مجازی A/B را برای فشرده سازی پارتیشن های عکس فوری ارائه می دهد. در اندروید 11 و اندروید 12 موارد زیر اعمال می شود:

  • به‌روزرسانی‌های مجازی A/B مانند به‌روزرسانی‌های A/B یکپارچه هستند. به‌روزرسانی‌های مجازی A/B زمان آفلاین بودن و غیرقابل استفاده بودن دستگاه را به حداقل می‌رسانند.
  • به‌روزرسانی‌های مجازی A/B را می‌توان برگرداند . اگر سیستم عامل جدید راه اندازی نشود، دستگاه ها به طور خودکار به نسخه قبلی برمی گردند.
  • به‌روزرسانی‌های مجازی A/B با کپی کردن تنها پارتیشن‌هایی که توسط بوت‌لودر استفاده می‌شوند ، از حداقل فضای اضافی استفاده می‌کنند. سایر پارتیشن‌های قابل به‌روزرسانی عکس‌برداری شده‌اند .

پیشینه و اصطلاحات

این بخش اصطلاحات را تعریف می کند و فناوری را که از A/B مجازی پشتیبانی می کند، توضیح می دهد.

نقشه‌بردار دستگاه

Device-mapper یک لایه بلوک مجازی لینوکس است که اغلب در اندروید استفاده می شود. با پارتیشن های پویا ، پارتیشن هایی مانند /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 ، یک ماژول نقشه‌بردار دستگاه برای گرفتن عکس فوری از وضعیت یک دستگاه ذخیره‌سازی متکی است. هنگام استفاده از dm-snapshot ، چهار دستگاه در حال بازی هستند:

  • دستگاه پایه دستگاهی است که عکس فوری گرفته می شود. در این صفحه، دستگاه پایه همیشه یک پارتیشن پویا است، مانند سیستم یا فروشنده.
  • دستگاه کپی در نوشتن (COW)، برای ثبت تغییرات در دستگاه پایه. این می تواند هر اندازه ای باشد، اما باید به اندازه کافی بزرگ باشد تا تمام تغییرات دستگاه پایه را در خود جای دهد.
  • دستگاه عکس فوری با استفاده از هدف snapshot ایجاد می شود. نوشته های روی دستگاه عکس فوری در دستگاه COW نوشته می شود. بسته به اینکه داده های مورد دسترسی توسط عکس فوری تغییر کرده باشند، از دستگاه عکس فوری خوانده می شود یا از دستگاه پایه یا دستگاه COW.
  • دستگاه مبدا با استفاده از snapshot-origin target ایجاد می شود. به دستگاه مبدأ می خواند که مستقیماً از دستگاه پایه خوانده می شود. در دستگاه مبدأ مستقیماً روی دستگاه پایه می‌نویسد، اما از داده‌های اصلی با نوشتن در دستگاه COW پشتیبان‌گیری می‌شود.

Device mapping for dm-snapshot

شکل 2. نقشه برداری دستگاه برای dm-snapshot

عکس های فوری فشرده شده

در اندروید 12 و بالاتر، از آنجایی که فضای مورد نیاز در پارتیشن /data می‌تواند زیاد باشد، می‌توانید عکس‌های فوری فشرده‌شده را در ساخت خود فعال کنید تا فضای مورد نیاز پارتیشن /data را برطرف کند.

عکس‌های فوری فشرده A/B مجازی بر روی اجزای زیر ساخته شده‌اند که در اندروید ۱۲ و بالاتر در دسترس هستند:

  • dm-user ، یک ماژول هسته شبیه به FUSE که به فضای کاربران اجازه می دهد تا دستگاه های بلوک را پیاده سازی کنند.
  • snapuserd ، یک دیمون فضای کاربران برای پیاده سازی یک قالب عکس فوری جدید.

این اجزا باعث فشرده سازی می شوند. سایر تغییرات لازم برای اجرای قابلیت‌های snapshot فشرده در بخش‌های بعدی آورده شده است: فرمت COW برای عکس‌های فوری فشرده ، dm-user و Snapuserd .

فرمت COW برای عکس های فوری فشرده

در اندروید ۱۲ و بالاتر، عکس‌های فوری فشرده از فرمت COW استفاده می‌کنند. مشابه فرمت داخلی هسته که برای عکس‌های فوری غیرفشرده استفاده می‌شود، فرمت COW برای عکس‌های فوری فشرده دارای بخش‌های متناوب متادیتا و داده است. فراداده قالب اصلی فقط برای عملیات جایگزینی مجاز است: بلوک X را در تصویر پایه با محتوای بلوک Y در عکس فوری جایگزین کنید. فرمت عکس های فوری فشرده COW گویاتر است و از عملیات زیر پشتیبانی می کند:

  • کپی : بلوک X در دستگاه پایه باید با بلوک Y در دستگاه پایه جایگزین شود.
  • جایگزینی : بلوک X در دستگاه پایه باید با محتویات بلوک Y در عکس فوری جایگزین شود. هر کدام از این بلوک ها به صورت gz فشرده شده است.
  • صفر : بلوک X در دستگاه پایه باید با تمام صفرها جایگزین شود.
  • XOR : دستگاه COW بایت های فشرده شده XOR را بین بلوک X و بلوک Y ذخیره می کند. (در اندروید 13 و بالاتر موجود است.)

به روز رسانی کامل OTA فقط شامل عملیات جایگزینی و صفر است. به‌روزرسانی‌های OTA افزایشی می‌توانند عملیات کپی نیز داشته باشند.

dm-user در اندروید 12

ماژول هسته dm-user userspace قادر می سازد تا دستگاه های بلوک نقشه برداری دستگاه را پیاده سازی کنند. ورودی جدول dm-user یک دستگاه متفرقه در زیر /dev/dm-user/<control-name> ایجاد می کند. یک فرآیند userspace می تواند دستگاه را برای دریافت درخواست های خواندن و نوشتن از هسته نظرسنجی کند. هر درخواست دارای یک بافر مرتبط برای فضای کاربر است که یا برای پر کردن (برای خواندن) یا انتشار (برای نوشتن) است.

ماژول هسته dm-user یک رابط کاربری قابل مشاهده جدید برای هسته ارائه می کند که بخشی از پایه کد kernel.org بالادستی نیست. تا زمانی که انجام نشده است، گوگل این حق را برای خود محفوظ می دارد که رابط dm-user در اندروید تغییر دهد.

snapuserd

مولفه snapuserd userspace به dm-user فشرده سازی مجازی A/B را پیاده سازی می کند.

در نسخه غیر فشرده Virtual A/B، (چه در اندروید 11 و پایین تر، چه در اندروید 12 بدون گزینه عکس فوری فشرده)، دستگاه COW یک فایل خام است. هنگامی که فشرده سازی فعال است، COW در عوض به عنوان یک دستگاه dm-user عمل می کند که به نمونه ای از دیمون snapuserd متصل است.

هسته از قالب جدید COW استفاده نمی کند. بنابراین مؤلفه snapuserd درخواست ها را بین قالب Android COW و قالب داخلی هسته ترجمه می کند:

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

شکل 3. نمودار جریان snapuserd به عنوان مترجم بین قالب های Android و Kernel COW

این ترجمه و فشرده سازی هرگز روی دیسک اتفاق نمی افتد. مؤلفه snapuserd خواندن و نوشتن COW را که در هسته اتفاق می‌افتد رهگیری می‌کند و با استفاده از قالب Android COW آن‌ها را پیاده‌سازی می‌کند.

فشرده سازی XOR

برای دستگاه‌هایی که با Android 13 و بالاتر راه‌اندازی می‌شوند، ویژگی فشرده‌سازی XOR، که به‌طور پیش‌فرض فعال است، عکس‌های فوری فضای کاربران را قادر می‌سازد تا بایت‌های فشرده‌شده XOR را بین بلوک‌های قدیمی و بلوک‌های جدید ذخیره کنند. هنگامی که تنها چند بایت در یک بلوک در یک به‌روزرسانی مجازی A/B تغییر می‌کند، طرح ذخیره‌سازی فشرده XOR از فضای کمتری نسبت به طرح ذخیره‌سازی پیش‌فرض استفاده می‌کند، زیرا عکس‌های فوری بایت‌های کامل 4K را ذخیره نمی‌کنند. این کاهش در اندازه عکس فوری امکان پذیر است زیرا داده های XOR حاوی صفرهای زیادی است و فشرده سازی آن آسان تر از داده های بلوک خام است. در دستگاه‌های پیکسل، فشرده‌سازی XOR اندازه عکس فوری را ۲۵٪ تا ۴۰٪ کاهش می‌دهد.

برای دستگاه‌هایی که به Android 13 و بالاتر ارتقا می‌یابند، فشرده‌سازی XOR باید فعال باشد. برای جزئیات، فشرده سازی XOR را ببینید.

فرآیندهای فشرده سازی مجازی A/B

این بخش جزئیاتی در مورد فرآیند فشرده سازی مجازی A/B مورد استفاده در اندروید 13 و اندروید 12 ارائه می دهد.

خواندن متادیتا (اندروید 12)

ابرداده توسط یک دیمون snapuserd ساخته شده است. ابرداده در درجه اول نقشه برداری از دو شناسه، هر کدام 8 بایت است که نشان دهنده بخش هایی است که باید ادغام شوند. در dm-snapshot به آن disk_exception می گویند.

struct disk_exception {
    uint64_t old_chunk;
    uint64_t new_chunk;
};

یک استثنای دیسک زمانی استفاده می شود که یک تکه داده قدیمی با یک قطعه جدید جایگزین شود.

یک شبح snapuserd فایل COW داخلی را از طریق کتابخانه COW می خواند و ابرداده را برای هر یک از عملیات COW موجود در فایل COW می سازد.

خواندن فراداده از dm-snapshot در هسته زمانی که دستگاه dm- snapshot ایجاد می شود آغاز می شود.

شکل زیر یک نمودار توالی برای مسیر IO برای ساخت ابرداده ارائه می دهد.

Sequence diagram, IO path for metadata construction

شکل 4. جریان دنباله ای برای مسیر IO در ساخت ابرداده

ادغام (اندروید 12)

پس از تکمیل فرآیند بوت، موتور به‌روزرسانی، اسلات را به‌عنوان بوت موفق علامت‌گذاری می‌کند و با تغییر هدف dm-snapshot به هدف dm-snapshot-merge ادغام را آغاز می‌کند.

dm-snapshot از میان ابرداده ها عبور می کند و یک IO ادغام را برای هر استثنای دیسک آغاز می کند. یک نمای کلی از مسیر ادغام IO در زیر نشان داده شده است.

Merge IO path

شکل 5. نمای کلی مسیر IO را ادغام کنید

اگر دستگاه در طول فرآیند ادغام راه اندازی مجدد شود، ادغام در راه اندازی مجدد بعدی از سر گرفته می شود و ادغام کامل می شود.

لایه بندی Device-mapper

برای دستگاه‌هایی که با Android 13 و بالاتر راه‌اندازی می‌شوند، فرآیندهای ادغام عکس فوری و عکس فوری در فشرده‌سازی مجازی A/B توسط مؤلفه فضای کاربران snapuserd انجام می‌شود. برای دستگاه هایی که به اندروید 13 و بالاتر ارتقا می یابند، این ویژگی باید فعال باشد. برای جزئیات، به ادغام فضای کاربری مراجعه کنید.

در زیر فرآیند فشرده سازی مجازی A/B توضیح داده شده است:

  1. فریم ورک پارتیشن /system را از دستگاه dm-verity که در بالای دستگاه dm-user انباشته شده است نصب می کند. این بدان معناست که هر ورودی/خروجی از سیستم فایل ریشه به dm-user هدایت می شود.
  2. dm-user I/O را به دیمون snapuserd فضای کاربر هدایت می کند که درخواست I/O را مدیریت می کند.
  3. وقتی عملیات ادغام کامل شد، چارچوب dm-verity در بالای dm-linear ( system_base ) جمع می کند و dm-user حذف می کند.

فرآیند فشرده سازی مجازی A/B

شکل 6. فرآیند فشرده سازی مجازی A/B

فرآیند ادغام عکس فوری می تواند قطع شود. اگر دستگاه در حین فرآیند ادغام راه اندازی مجدد شود، فرآیند ادغام پس از راه اندازی مجدد از سر گرفته می شود.

انتقال ها را آغاز کنید

هنگام راه‌اندازی با عکس‌های فوری فشرده، init مرحله اول باید snapuserd برای نصب پارتیشن‌ها شروع کند. این یک مشکل ایجاد می‌کند: وقتی sepolicy بارگذاری و اجرا می‌شود، snapuserd در زمینه اشتباه قرار می‌گیرد و درخواست‌های خواندن آن با رد کردن سلینوکس شکست می‌خورد.

برای رفع این مشکل، snapuserd انتقال در مرحله قفل با init را به صورت زیر انجام دهید:

  1. init مرحله اول snapuserd از ramdisk راه اندازی می کند و یک توصیفگر فایل باز را در یک متغیر محیطی در آن ذخیره می کند.
  2. init مرحله اول سیستم فایل ریشه را به پارتیشن سیستم سوئیچ می کند، سپس نسخه سیستمی init را اجرا می کند.
  3. کپی سیستم init ، sepolicy ترکیبی را در یک رشته می خواند.
  4. Init mlock() در تمام صفحات ext4 فراخوانی می کند. سپس تمام جداول دستگاه-نقشه نگار را برای دستگاه های عکس فوری غیرفعال می کند و snapuserd متوقف می کند. پس از این، خواندن از پارتیشن ها ممنوع است، زیرا انجام این کار باعث بن بست می شود.
  5. با استفاده از توصیفگر باز برای کپی ramdisk snapuserd ، init دیمون را با زمینه سلینوکس درست راه اندازی می کند. جداول Device-mapper برای دستگاه های Snapshot دوباره فعال می شوند.
  6. Init munlockall() را فراخوانی می کند - اجرای مجدد IO بی خطر است.

استفاده از فضا

جدول زیر مقایسه ای از استفاده از فضا برای مکانیسم های OTA مختلف با استفاده از اندازه های سیستم عامل Pixel و OTA ارائه می دهد.

تاثیر اندازه غیر A/B A/B A/B مجازی A/B مجازی (فشرده شده)
تصویر اصلی کارخانه 4.5 گیگابایت فوق العاده (3.8G تصویر + 700M رزرو شده) 1 9 گیگابایت فوق العاده (3.8G + 700M رزرو شده، برای دو اسلات) 4.5 گیگابایت فوق العاده (3.8G تصویر + 700M رزرو شده) 4.5 گیگابایت فوق العاده (3.8G تصویر + 700M رزرو شده)
سایر پارتیشن های ثابت /cache هیچ یک هیچ یک هیچ یک
فضای ذخیره سازی اضافی در طول OTA (فضا پس از اعمال OTA برگردانده شد) 1.4 گیگابایت در /داده 0 3.8 گیگابایت 2 در /داده 2.1 گیگابایت 2 در /داده
کل فضای ذخیره‌سازی مورد نیاز برای اعمال OTA 5.9 گیگابایت 3 (فوق العاده و دیتا) 9 گیگابایت (فوق العاده) 8.3 گیگابایت 3 (فوق العاده و دیتا) 6.6 گیگابایت 3 (فوق العاده و دیتا)

1 طرح‌بندی فرضی را بر اساس نقشه‌برداری پیکسل نشان می‌دهد.

2 فرض می کند که تصویر سیستم جدید به اندازه اصلی است.

3 فضای مورد نیاز تا راه اندازی مجدد موقت است.

برای پیاده سازی Virtual A/B یا استفاده از قابلیت های فشرده شده عکس فوری، به پیاده سازی Virtual A/B مراجعه کنید.