सुपर पार्टिशन का साइज़ तय करना

डिवाइस को अपडेट करने के लिए, super पार्टीशन का साइज़ सही होना ज़रूरी है. साइज से सीधे तौर पर यह पता चलता है कि कोई डिवाइस कितने अपडेट ले सकता है और कितने उपयोगकर्ता उन अपडेट को डाउनलोड कर सकते हैं.

कुछ ज़रूरी वैरिएबल हैं जिन पर विचार करना ज़रूरी है. पहला फ़ैक्ट्री साइज़ है. यह डिवाइस को पहली बार फ़्लैश करने पर, सभी डाइनैमिक पार्टिशन का साइज़ होता है. दूसरा, ग्रोथ रेट है. यह वह प्रतिशत है जिससे डिवाइस के अपडेट किए जा सकने की अवधि के दौरान, ओएस का साइज़ बढ़ता है.

इसके अलावा, वर्चुअल ए/बी डिवाइस, अपडेट के दौरान /data पर जगह का इस्तेमाल कर सकते हैं. इसलिए, super का साइज़ तय करते समय इस बात का ध्यान रखना ज़रूरी है. अगर /data पर बहुत ज़्यादा स्पेस की ज़रूरत होती है, तो कुछ उपयोगकर्ता अपडेट नहीं कर पाते या अपडेट नहीं करना चाहते. हालांकि, अगर यह पता चलता है कि ज़्यादातर उपयोगकर्ताओं के पास कुछ प्रतिशत स्टोरेज खाली है, तो डिवाइस उस स्टोरेज को super से आसानी से हटा सकते हैं. इसके अलावा, डिवाइस यह गारंटी दे सकते हैं कि /data की कभी ज़रूरत नहीं पड़ेगी. इसके लिए, super को काफ़ी बड़ा बनाना होगा.

नीचे कुछ मॉडल दिए गए हैं. इनकी मदद से, इन वैरिएबल के आधार पर super पार्टीशन के साइज़ का अनुमान लगाया जा सकता है.

/data पर भरोसा करना

वर्चुअल A/B टेस्ट में, /data का साइज़ बढ़ाने के लिए super को छोटा करने का सुझाव दिया जाता है. अपडेट के दौरान, कुछ जगह की ज़रूरत होती है. अपडेट करने की सुविधा पर पड़ने वाले असर को समझने के लिए, यह जानना ज़रूरी है कि समय के साथ कितने प्रतिशत डिवाइसों में उतना स्पेस खाली होने की संभावना है. इस नंबर का पता लगाना, डिवाइस के हार्डवेयर और उस डिवाइस का इस्तेमाल करने वाले लोगों के व्यवहार पर निर्भर करता है. यहां दिए गए उदाहरणों में, इस नंबर को AllowedUserdataUse के तौर पर दिखाया गया है.

बिना कंप्रेस किए

कंप्रेशन के बिना, पूरे ओटीए के लिए ओएस के साइज़ के बराबर स्नैपशॉट की ज़रूरत होती है. इसलिए, super का साइज़ तय करते समय इस बात का ध्यान रखना ज़रूरी है:

  FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth)
  Super = Max(FinalDessertUpdate, FinalDessertSize * 2 - AllowedUserdataUse)

उदाहरण के लिए, मान लें कि किसी वर्चुअल A/B डिवाइस का फ़ैक्ट्री साइज़ 4 जीबी है. साथ ही, यह उम्मीद की जा रही है कि इसका साइज़ 50% तक बढ़ सकता है. इसके अलावा, यह भी मान लें कि लगभग सभी उपयोगकर्ताओं के पास 1 जीबी स्टोरेज खाली है या वे अपडेट के लिए 1 जीबी तक स्टोरेज खाली करने के लिए तैयार हैं. इस डिवाइस के लिए, super का साइज़ इस तरह से तय किया जा सकता है:

  FinalDessertSize = 4GB + (4GB * 0.5) = 6GB
  Super = Max(6GB, 6GB * 2 - 1GB) = Max(6GB, 11GB)

इसलिए, इस डिवाइस में 11 जीबी का super पार्टीशन होना चाहिए.

कंप्रेशन के साथ

कंप्रेशन की मदद से, पूरे ओएस के अपडेट के लिए ओएस के साइज़ का करीब 70% स्नैपशॉट ज़रूरी होता है:

  FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth)
  FinalOTASnapshotSize = FinalDessertSize * 0.7
  Super = Max(FinalDessertUpdate, FinalDessertSize + FinalOTASnapshotSize - AllowedUserdataUse)

उदाहरण के लिए, मान लें कि किसी डिवाइस को वर्चुअल A/B कंप्रेशन के साथ कॉन्फ़िगर किया गया है. इसका फ़ैक्ट्री साइज़ 4 जीबी है और इसमें 50% की बढ़ोतरी होने की उम्मीद है. साथ ही, यह भी मान लें कि लगभग सभी उपयोगकर्ताओं के पास 1 जीबी स्टोरेज खाली है या वे अपडेट के लिए 1 जीबी तक स्टोरेज खाली करने के लिए तैयार हैं. इस डिवाइस के लिए, super को इस तरह से साइज़ किया जा सकता है:

  FinalDessertSize = 4GB + (4GB * 0.5) = 6GB
  FinalOTASnapshotSize = 6GB * 0.7 = 4.2GB
  Super = Max(6GB, 6GB + 4.2GB - 1GB) = Max(6GB, 9.2GB) = 9.2GB

इसलिए, इस डिवाइस में 9.2 जीबी का super पार्टीशन होना चाहिए.

/data पर भरोसा किए बिना

अगर आपको ऐसे ओटीए चाहिए जिन्हें /data पर स्नैपशॉट के लिए जगह की ज़रूरत नहीं होती है, तो साइज़िंग super करना आसान है.

बिना कंप्रेस किए

बिना कंप्रेशन वाले वर्चुअल A/B डिवाइस या सामान्य A/B डिवाइस के लिए:

  FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth)
  Super = FinalDessertSize * 2

उदाहरण के लिए, मान लें कि वर्चुअल A/B डिवाइस में फ़ैक्ट्री साइज़ 4 जीबी है और इसमें 50% की बढ़ोतरी होने की उम्मीद है. यह पक्का करने के लिए कि यह डिवाइस, ओटीए स्नैपशॉट के लिए कभी भी /data का इस्तेमाल न करे, इसकी गणना इस तरह की जाएगी:

  FinalDessertSize = 4GB + (4GB * 0.5) = 6GB
  Super = FinalDessertSize * 2 = 12GB

इसलिए, इस डिवाइस में 12 जीबी का super पार्टिशन होना चाहिए.

कंप्रेशन के साथ

कंप्रेशन की सुविधा वाले वर्चुअल A/B डिवाइस के लिए:

  FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth)
  FinalOTASnapshotSize = FinalDessertSize * 0.7
  Super = FinalDessertSize + FinalOTASnapshotSize

उदाहरण के लिए, वर्चुअल A/B कंप्रेशन डिवाइस के बारे में सोचें. इसका फ़ैक्ट्री साइज़ 4 जीबी है और इसमें 50% की बढ़ोतरी होने की उम्मीद है. यह पक्का करने के लिए कि यह डिवाइस, ओटीए स्नैपशॉट के लिए कभी /data का इस्तेमाल न करे, इसकी गणना इस तरह की जाएगी:

  FinalDessertSize = 4GB + (4GB * 0.5) = 6GB
  FinalOTASnapshotSize = 6GB * 0.7 = 4.2GB
  Super = 6GB + 4.2GB = 10.2GB

इसलिए, इस डिवाइस में 10.2 जीबी का super पार्टीशन होना चाहिए.

सीमाएं

ऐसा लग सकता है कि अगर फ़ैक्ट्री इमेज का साइज़ 4 जीबी है और फ़ाइनल अपडेट का साइज़ 5 जीबी है, तो super का साइज़ 10 जीबी के बजाय 9 जीबी होना चाहिए. हालांकि, अगर पहला अपडेट और फ़ाइनल अपडेट, दोनों 5 जीबी के हैं, तो हो सकता है कि super में फ़ाइनल अपडेट के लिए जगह कम हो. ऊपर दिए गए फ़ॉर्मूले में यह माना गया है कि पार्टीशन का साइज़ कभी भी बढ़ सकता है. फ़ाइनल अपडेट को लागू करने के लिए उतनी ही जगह की ज़रूरत हो सकती है जितनी पहले अपडेट को लागू करने के लिए ज़रूरी थी.

ध्यान दें कि कंप्रेस करने के अनुपात का अनुमान लगाया जाता है. ओएस इमेज को कंप्रेस करने का तरीका, उसके कॉन्टेंट के हिसाब से बेहतर या खराब हो सकता है. अगर EROFS जैसे कंप्रेस किए गए फ़ाइल सिस्टम का इस्तेमाल किया जा रहा है, तो वर्चुअल A/B से मिलने वाले अतिरिक्त कंप्रेस किए गए डेटा से कोई फ़ायदा नहीं होता. ऐसे में, बिना कंप्रेस किए गए फ़ॉर्मूले में से किसी एक का इस्तेमाल करना बेहतर होता है.

साइज़ का हिसाब लगाना

ऊपर दिए गए उदाहरणों में FactorySize की वैल्यू पता करने के लिए, सभी डाइनैमिक पार्टीशन के साइज़ को आपस में जोड़ें. AOSP के डाइनैमिक पार्टिशन की इमेज ये हैं:

• system.img
• vendor.img
• product.img
• system_ext.img
• vendor_dlkm.img
• system_dlkm.img

पक्का करें कि साइज़ का हिसाब, बिना स्पार्स की गई इमेज के आधार पर लगाया गया हो. Android 12 या इससे पहले के वर्शन के लिए इमेज बनाते समय, इमेज को डिफ़ॉल्ट रूप से स्पार्स किया जाता है. हालांकि, simg2img का इस्तेमाल करके, इमेज को अनस्पार्स किया जा सकता है.

ओटीए पैकेज से भी पार्टीशन के साइज़ का हिसाब लगाया जा सकता है. ऐसा करने से, हर पार्टीशन के लिए वर्चुअल ए/बी स्नैपशॉट के साइज़ का अनुमान भी लगाया जाता है:

  python3 system/update_engine/scripts/payload_info.py path/to/ota-package.zip

इसके अलावा, OTA Analysis Tool का इस्तेमाल भी किया जा सकता है. यह टूल, किसी भी फ़ाइल को अपलोड नहीं करता है. साथ ही, ओटीए पैकेज का विश्लेषण डिवाइस पर ही करता है.

ExpectedGrowth की वैल्यू का पता लगाने के लिए, पहले से रिलीज़ किए गए डिवाइस का इस्तेमाल करें. ग्रोथ का हिसाब लगाने के लिए, सबसे पुरानी और सबसे नई super इमेज का इस्तेमाल करें.