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

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

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

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

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

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

वर्चुअल A/B, super को छोटा करने के लिए बढ़ावा देता है, ताकि /data का साइज़ बढ़ाया जा सके. अपडेट के दौरान, कुछ जगह की ज़रूरत होती है. अपडेट करने की सुविधा पर पड़ने वाले असर को समझने के लिए, यह जानना ज़रूरी है कि समय के साथ कितने प्रतिशत डिवाइसों में उतना स्टोरेज खाली होगा. यह संख्या, डिवाइस के हार्डवेयर और उस डिवाइस के उपयोगकर्ताओं के व्यवहार पर निर्भर करती है. नीचे दिए गए उदाहरणों में, इस नंबर को 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 GB है और आने वाले समय में इसमें 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 से होने वाले अतिरिक्त कंप्रेसन से फ़ायदा कम मिलता है. ऐसे में, दिशा-निर्देश के तौर पर किसी एक बिना संकुचित किए गए फ़ॉर्मूला का इस्तेमाल करना बेहतर होता है.

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

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

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

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

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

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

इसके अलावा, ओटीए (ऑनलाइन ट्रैवल एजेंसी) का विश्लेषण करने वाले टूल का इस्तेमाल किया जा सकता है. यह टूल, कोई फ़ाइल अपलोड नहीं करता और ओटीए पैकेज का स्थानीय तौर पर विश्लेषण करता है.

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