GiB से B में बदलें

एक गिबीबाइट 1,073,741,824 बाइट की है, यानी गीगाबाइट से क़रीब 7% ज़्यादा। Windows गिबीबाइट में नापता है पर उन्हें «GB» कहता है — और «जगह कम क्यों दिख रही है» वाली पूरी पहेली इसी में है।

एक बाइट आठ बिट की होती है, और यह हमेशा तय नहीं था: शुरुआती कंप्यूटर छह, सात या नौ इस्तेमाल करते थे। आठ इसलिए जीता कि उसमें एक अक्षर बैठ जाता है और वह संख्या साफ़-साफ़ आधों में बँटती है।

इस तरफ़ हिसाब गुणा का है, और वह भी पूरे अंक से: एक गिबीबाइट बराबर 1,07,37,41,824 बाइट, ठीक-ठीक। 1,07,37,41,824 कोई नाप नहीं है जो पास आ गई हो, यह परिभाषा है।

इसीलिए यह उन गिनी-चुनी गिनतियों में है जो दिमाग़ में करने लायक़ हैं, और नतीजा जाँचा भी जा सकता है: वापस भाग दीजिए और आपको ठीक उसी अंक पर लौटना होगा जहाँ से चले थे, बिना किसी बची हुई गुंजाइश के।

एक GiB अपने नीचे वाली इकाई का 1,024 गुना होता है; एक GB 1,000 गुना। इस पेज पर यह 1073741824 B और 1000000000 B का फ़र्क़ है — 7.4 % — और हर सीढ़ी पर यह फ़ासला बढ़ता जाता है। इसीलिए एक तस्वीर पर यह गोलाई भर है और हार्ड डिस्क पर दिखने लायक़ हिस्सा।

ग़ायब जगह का पूरा रहस्य इतना ही है, और इस पेज पर वह 7.4 % का बनता है। GB के नाम पर बिकी डिस्क में ठीक उतना ही होता है जितना डिब्बे पर लिखा है — दशमलव हिसाब से एक GB यानी 1000000000 B। विंडोज़ उसे 1,000 के बजाय 1,024 से बाँटता है और नाम दशमलव वाला ही रखता है, इसलिए उसका «एक GB» दरअसल 1073741824 B का निकलता है और डिस्क का अंक उतना ही छोटा दिखने लगता है। ऐपल का मैकओएस 10.6 से इन्हें दशमलव इकाइयों में ही गिनता है, और यही वजह है कि एक ही डिस्क दो मशीनों पर दो अलग आकार की दिख सकती है। न कुछ ग़ायब हुआ है, न कोई गोलाई हुई है — वही बाइट दो नामों से गिने जा रहे हैं।

बहुत सी सेटिंग्स संख्या लेती हैं, इकाई नहीं, और दस्तावेज़ बाइट कहता है। ऑब्जेक्ट स्टोरेज पार्ट साइज़, किसी फ़्रेमवर्क में रिक्वेस्ट बॉडी सीमा — सब पूर्णांक चाहते हैं, और एक गिबिबाइट का पूर्णांक 1,073,741,824 है।

बाइनरी इकाई की ओर जाने की वजह यह है कि आसपास का तंत्र लगभग पक्का पहले से बाइनरी है। मेमोरी पेज, ब्लॉक साइज़ दो की घातें हैं, और 1,073,741,824 की सीमा उसके नीचे मौजूद अलोकेटर से मेल खाती है।

ऑपरेशनल टूलिंग में परंपरा है कि नंगा k, m या g 1,024, 1,048,576 या 1,073,741,824 का मतलब रखे। JVM हीप फ़्लैग ऐसे ही काम करते हैं, तो -Xmx4g 4,294,967,296 बाइट आरक्षित करता है। Docker मेमोरी सीमाएँ भी वैसे ही करती हैं।

GNU coreutils एक क़दम आगे जाकर दोनों वर्तनी स्वीकार करते हैं: एक अक्षर बाइनरी है और B पर ख़त्म होने वाला दो-अक्षर रूप दशमलव है। dd bs=1G और dd bs=1GB शेल हिस्ट्री में लगभग एक जैसे दिखते हैं और हर ब्लॉक में सात प्रतिशत अलग होते हैं।

Kubernetes में संसाधन मात्रा अपने सिंटैक्स में ही यह फ़र्क़ ले जाती है। Gi प्रत्यय बाइनरी है, तो 1Gi 1,073,741,824 बाइट है; बिना i वाला G दशमलव है, तो 1G 1,000,000,000 है।

यह स्पष्टता एक तेज़ धार भी रखती है। 4Gi की बजाय 4G लिखी मेमोरी सीमा 294,967,296 बाइट छोटी है — लगभग सात प्रतिशत का फ़र्क़ और समीक्षा में पूरी तरह अदृश्य।

कुछ बाइट गिनतियाँ त्रुटि संदेशों और सीमा फ़ील्ड में बार-बार दिखती हैं। 1,048,576 एक मेबिबाइट है, 1,073,741,824 एक गिबिबाइट है, 4,294,967,296 2³² है — 32-बिट पते की जगह का ठीक आकार।

इन आँकड़ों से एक कम भी उतना ही मायने रखता है। 2,147,483,647 सबसे बड़ा साइन किया 32-बिट पूर्णांक है, और उसमें रखी बाइट गिनती वहीं रुकती है। 1.9 GiB पर सफल और 2.1 पर नाकाम होने वाला अपलोड आम तौर पर इसी सीमा से टकराता है।

ज़ोर से नाकाम होना ख़ुशक़िस्मती वाला मामला है। मेमोरी सीमा पार करने वाला कंटेनर पहचानी जाने लायक़ स्थिति के साथ रोका जाता है। दोनों उस सेटिंग की ओर इशारा करते हैं जिसने उन्हें पैदा किया।

ख़ामोश नाकामी ज़्यादा भारी पड़ती है। कंटेनर की इजाज़त से सात प्रतिशत बड़ी हीप स्टार्टअप पर नाकाम नहीं होती — यह हफ़्तों बाद, भार के तहत नाकाम होती है, जब प्रक्रिया आख़िरकार उतनी मेमोरी इस्तेमाल करने की कोशिश करती है जितनी उसे बताई गई थी।

8589934592 पढ़ने वाली कॉन्फ़िग लाइन समीक्षक को मंशा के बारे में कुछ नहीं बताती। वही मूल्य 8 1024 1024 * 1024 लिखा हो, जहाँ प्रारूप अभिव्यक्ति की इजाज़त दे, तो एक नज़र में जाँचा जा सकता है।

जहाँ सिंटैक्स प्रत्यय की इजाज़त दे, फैलाए अंकों पर उसे तरजीह दीजिए। 1Gi में लगभग हर टाइपो सिंटैक्स त्रुटि है; 1073741824 में टाइपो एक ऐसा चलता कॉन्फ़िगरेशन है जिसकी सीमा दस गुना बड़ी या छोटी है।

शृंखला 1,024 के गुणकों में आगे बढ़ती है: टेबिबाइट 2⁴⁰ है, यानी 1,099,511,627,776 बाइट, और पेबिबाइट 2⁵⁰ है। दोनों नाप की बजाय सीमाओं में दिखते हैं — अधिकतम ऑब्जेक्ट आकार, अधिकतम फ़ाइल आकार।

व्यवहार में सबसे ज़्यादा मायने रखने वाली सीमा इन सबसे ऊपर बैठती है। अनसाइन्ड 64-बिट बाइट गिनती 16 EiB तक पहुँचती है, जिसे मौजूदा कोई तंत्र छूता नहीं।

जो भी लिखा गया हो, फ़ाइल पर भरोसा करने की बजाय तंत्र से असली मूल्य वापस पढ़िए। कंटेनर रनटाइम वह मेमोरी सीमा दिखाते हैं जो उन्होंने लागू की, JVM माँगने पर अपनी सुलझी हीप सेटिंग छापता है।

यह सबसे ज़्यादा तब मायने रखता है जब दो परतें अलग-अलग इकाई में सीमा लगाती हैं। गिबिबाइट में लिखी प्रोसेस सीमा और दशमलव गीगाबाइट में लिखी कंटेनर सीमा के बीच सात प्रतिशत का ऐसा फ़ासला छूट जाता है जिसकी किसी ने योजना नहीं बनाई थी।