MB से TiB में बदलें

एक मेगाबाइट दस लाख बाइट है। भंडारण बनाने वाले हमेशा दशमलव में गिनते आए हैं, और इसीलिए उनकी संख्याएँ उससे बड़ी लगती हैं जो कंप्यूटर दिखाता है।

एक टेबीबाइट 1,024 गिबीबाइट की है। टेराबाइट से इसका फ़ासला हर सीढ़ी पर बढ़ता है: किलो पर 2.4%, मेगा पर 4.9%, गीगा पर 7.4% और टेरा पर 10%।

गुणक 0.000001 है, और इसे लगभग कोई साथ लेकर नहीं चलता। 0.000001 पर गोल करने से यह 0.06 % चूकता है — छोटे अंकों पर दिखता ही नहीं, और 10,000 MB के आसपास पूरी एक इकाई बन जाता है।

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

एक TiB अपने नीचे वाली इकाई का 1,024 गुना होता है; एक TB 1,000 गुना। इस पेज पर यह 1099511.6278 MB और 1000000 MB का फ़र्क़ है — 10 % — और हर सीढ़ी पर यह फ़ासला बढ़ता जाता है। इसीलिए एक तस्वीर पर यह गोलाई भर है और हार्ड डिस्क पर दिखने लायक़ हिस्सा।

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

अकेली फ़ाइलें मेगाबाइट में सहज बताई जाती हैं — कोई तस्वीर, कोई रिकॉर्डिंग — और उन्हें रखने वाला भंडार pool-सॉफ़्टवेयर tebibyte में बताता है।

एक tebibyte 1,099,511.63 MB रखता है, इसलिए काम का अंदाज़ा है 1.1 दस-लाख मेगाबाइट प्रति tebibyte। यह लगभग किसी को भी खड़े-खड़े गणित करने लायक़ बनाता है।

5 MB प्रति फ़ाइल पर एक tebibyte लगभग 219,900 फ़ाइलें रखता है। 30 MB पर — किसी फ़ुल-फ़्रेम कैमरे का RAW फ़्रेम — 36,650। 800 MB पर, किसी दबे डेटाबेस-डंप के लिए, 1,374।

ये तीनों अंक दो दर्जे फैले हुए हैं और एक ही क्षमता बताते हैं — जो योजना औसत फ़ाइल-आकार नहीं बताती, वह योजना नहीं है।

हर फ़ाइल पूरे allocation-block तक गोल होती है, इसलिए छोटी फ़ाइलों की लाइब्रेरी अपनी सामग्री से ज़्यादा जगह घेरती है। 4 KiB ब्लॉक-आकार पर औसत बर्बादी प्रति फ़ाइल लगभग 2 KiB है।

मीडिया-लाइब्रेरी अपना ओवरहेड ऊपर से जोड़ती है — edit रखने वाली sidecar फ़ाइलें, कई आकार के preview, बढ़ती हुई catalogue-डेटाबेस।

स्थिर कुल ग़लत सवाल का जवाब है। ख़रीद तय करती है दर — प्रति हफ़्ते, प्रति shoot मेगाबाइट। दर को बची क्षमता की उसी इकाई में बदलिए और बाँटिए, जवाब अंक नहीं तारीख़ है।

दर वह जगह है जहाँ इकाई की ग़लती जमा होती है, रुकती नहीं। हर हफ़्ते दस प्रतिशत कम पूर्वानुमान उसी दिशा में जमा होता जाता है जिसमें बढ़ोतरी हो रही है।

दशमलव और बाइनरी प्रीफ़िक्स के बीच असहमति हर क़दम पर बढ़ती है — किलो पर 2.4 प्रतिशत, मेगा पर 4.9, गीगा पर 7.4, टेरा पर 9.95। मेगाबाइट सिरे पर फ़र्क़ नगण्य है; tebibyte सिरे पर एक ही pool पर सौ गीगाबाइट है।

यह असंतुलन इस बदलाव को सावधानी से करने लायक़ बनाता है। दस लाख MB को 0.909 TiB मानना ग़लत है — tebibyte 1,099,512 MB रखता है, ठीक दस लाख नहीं।

औसत किसी मीडिया-लाइब्रेरी का ख़राब सारांश है। दो लाख तस्वीरों का संग्रह ज़्यादातर 4 MB की दबी फ़्रेम और कुछ हज़ार सौ-मेगाबाइट के panorama रख सकता है।

बिना कुछ ख़र्च किए सुधार है औसत से गुणा करने के बजाय पूरा संग्रहित आकार सीधे लेना। हर स्टोरेज-औज़ार directory-tree का कुल बताता है, जिसमें block-गोलाई और sidecar पहले से शामिल हैं।

कोई पुरालेख शायद ही कभी एक बार रखा जाता है। सामान्य backup-अनुशासन तीन प्रतियाँ दो तरह के माध्यम पर रखता है, एक बाहर — जो 1.46 TiB की लाइब्रेरी को 4 TiB से ज़्यादा तय-क्षमता बना देता है।

फ़ाइल-आकार से बना अंदाज़ा लगभग हमेशा सिर्फ़ मुख्य प्रति बताता है। गुणक साफ़ लिखना — असली आकार, गुणा प्रतियाँ, जोड़ snapshot-रिटेंशन — किसी वाजिब दिखते अंक को बहस लायक़ अंक बना देता है।

गणना जिस इकाई में भी हुई हो, नतीजा उसी इकाई में बताइए जो pool बताता है, क्योंकि अगले हफ़्ते कोई उसी से मिलाएगा।

जहाँ दोनों अंक चाहिए — दशमलव टेराबाइट में ख़रीद और tebibyte में भराव-स्तर — दोनों एक ही लाइन पर लिखिए, लेबल के साथ।