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

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

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

एक 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 से इन्हें दशमलव इकाइयों में ही गिनता है, और यही वजह है कि एक ही डिस्क दो मशीनों पर दो अलग आकार की दिख सकती है। न कुछ ग़ायब हुआ है, न कोई गोलाई हुई है — वही बाइट दो नामों से गिने जा रहे हैं।

हर ट्रांसफ़र अंदाज़ा एक भाग है, और इसके दो इनपुट अलग-अलग इकाई सिस्टम से आते हैं। मात्रा वह चीज़ बताती है जो डेटा रखती है — बैकअप repository, array, फ़ाइलसिस्टम — और वे सब 1,024 की घातों में गिनती करते हैं, तो आँकड़ा टेबिबाइट में आता है। रफ़्तार नेटवर्क या डिवाइस स्पेसिफ़िकेशन से आती है, और वे बिना अपवाद दशमलव हैं।

बिना बदले एक को दूसरे से भाग देना क़रीब दस प्रतिशत ज़्यादा आशावादी जवाब देता है, जो माइग्रेशन विंडो पर maintenance अवधि के भीतर ख़त्म होने और न होने का फ़र्क़ है। एक टेबिबाइट 1,099,511.63 MB है, तो पहला ईमानदार क़दम है मात्रा को दशमलव मेगाबाइट में बदलना।

binary हिसाब मायने रखने से पहले, उसी वाक्य में एक बड़ा जाल है। Link की रफ़्तार बिट प्रति सेकंड में बताई जाती है और ट्रांसफ़र रेट बाइट प्रति सेकंड में, और एक बाइट आठ बिट है। 1,000 Mbit/s link ज़्यादा से ज़्यादा 125 MB प्रति सेकंड चलता है; 100 Mbit/s link 12.5।

इसे ग़लत समझना आठ गुना की ग़लती है, इस पेज के binary-बनाम-दशमलव फ़र्क़ से क़रीब सत्तर गुना बड़ी। इसे पहले और साफ़ तौर पर सुलझाना लायक़ है: मात्रा छूने से पहले रफ़्तार को MB प्रति सेकंड में लिख लीजिए, हिसाब समेत।

दोनों पक्ष दशमलव होने पर हिसाब छोटा है। एक टेबिबाइट 1,099,512 MB है; 100 MB प्रति सेकंड पर यह 10,995 सेकंड है, यानी 3 घंटे 3 मिनट। उसी रफ़्तार पर दस टेबिबाइट 30 घंटे 32 मिनट है। 1,250 MB प्रति सेकंड पर — दस-गीगाबिट link की सैद्धांतिक सीमा — दस टेबिबाइट 2 घंटे 27 मिनट है।

ये आँकड़े फ़र्श हैं, और जहाँ भी बताए जाएँ वैसे ही लेबल किए जाने चाहिए। ये पूरी रफ़्तार पर एक लगातार धारा मान लेते हैं बिना प्रति-फ़ाइल क़ीमत के, जो कोई असली ट्रांसफ़र हासिल नहीं करता।

हिसाब और घड़ी के बीच फ़र्क़ मात्रा से ज़्यादा फ़ाइल गिनती से तय होता है। हर फ़ाइल की क़ीमत है create, metadata लिखना, और नेटवर्क प्रोटोकॉल पर कम से कम एक round trip; दस लाख छोटी फ़ाइलें उनकी सामग्री हिलाने से ज़्यादा इन पर समय ख़र्च कर सकती हैं।

बाक़ी घटाव ज़्यादा स्थिर और अंदाज़ा लगाने लायक़ हैं। Protocol overhead कुछ प्रतिशत लेता है। Encryption और checksum CPU ख़र्च करते हैं जो शायद bottleneck हो या न हो। पाने वाले storage की एक write सीमा है जो अक्सर नेटवर्क से कम होती है।

जहाँ ट्रांसफ़र प्रोवाइडर से बाहर जाता है, शुल्क प्रति दशमलव गीगाबाइट है और मीटर उनका है। 10 TiB बताई repository अगर पूरी हिलती है तो 10,995 GB बिल-योग्य egress है, जो टेबिबाइट संख्या से कोई भी अंदाज़ा लगाए गोल आँकड़े से 9.95 प्रतिशत ऊपर है।

Provider का मीटर वह भी गिनता है जो आपका अपना आँकड़ा नहीं गिनता: retry, protocol overhead, और listing व verifying करते समय टूलिंग जो ट्रैफ़िक बनाती है। बदले आँकड़े से अंदाज़ा लगाना और फ़र्क़ को contingency मानना ज़्यादा ईमानदार है।

लंबे ट्रांसफ़र बीच में रुकते हैं, और रुकावट के बाद जो फिर निकाला जाता है वहीं अंदाज़े भटकते हैं। बची मात्रा आम तौर पर स्रोत फिर टेबिबाइट में बताता है, अब तक की देखी रफ़्तार मेगाबाइट प्रति सेकंड में है, और रात दो बजे हिसाब लगाने वाला इंसान सीधे दोनों को भाग देने की सबसे ज़्यादा संभावना रखता है।

बदलाव को estimate में नहीं, runbook में लिखना यही रोकता है। "बची TiB × 1,099,512 = MB; ÷ देखी MB/s = सेकंड" पढ़ने वाली लाइन एक लाइन लेती है, जाँची जा सकती है, और रात दो बजे वही जवाब देती है जो योजना बैठक में दिया था।

जो आँकड़े अंदाज़े को जाँचने लायक़ बनाते हैं वे बीच के हैं। स्रोत की बताई TiB में मात्रा; वही मात्रा MB में; MB प्रति सेकंड में रफ़्तार, बिट-से-बाइट बदलाव दिखाते हुए अगर कोई हुआ; सैद्धांतिक फ़र्श; मान ली गई कुशलता; नतीजे वाली विंडो। छह लाइनें, और हर एक ऐसी संख्या है जिसे कोई पूरा दोबारा निकाले बिना चुनौती दे सकता है।

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

ट्रांसफ़र पर रुकने वाला अंदाज़ा आम तौर पर एक पूरे pass से कम पड़ता है। जो कुछ माइग्रेट करने लायक़ है वह आम तौर पर verify करने लायक़ भी है, और checksum तुलना दोनों छोर पर पूरी मात्रा फिर पढ़ती है। अगर 10 TiB का ट्रांसफ़र तीस घंटे लेता है, verification हर तरफ़ 10,995,116 MB की एक और पढ़ाई है।

सस्ते विकल्प भी हैं और उन्हें डिफ़ॉल्ट की बजाय जान-बूझकर चुना जाना चाहिए। एक नमूना verify करना कम समय में संभावित भरोसा देता है। ट्रांसफ़र के दौरान checksum करने वाले टूल दूसरी पढ़ाई पूरी तरह टाल देते हैं, throughput की क़ीमत पर। जो भी चुना जाए, विंडो में इसे शामिल करना चाहिए।