मुखपृष्ठ » कैसे » 'साइज़ ’और Disk साइज़ ऑन डिस्क’ में बड़ा अंतर क्यों है?

    'साइज़ ’और Disk साइज़ ऑन डिस्क’ में बड़ा अंतर क्यों है?

    अधिकांश समय, 'साइज़' और 'साइज़ ऑन डिस्क' के मान किसी फ़ोल्डर या फ़ाइल के आकार की जाँच करते समय मिलान के बहुत करीब होंगे, लेकिन अगर दोनों के बीच बहुत बड़ी विसंगति हो तो क्या होगा? आज की SuperUser Q & A पोस्ट इस भ्रामक समस्या के उत्तर को देखती है.

    आज का प्रश्न और उत्तर सत्र सुपरयूज़र के सौजन्य से आता है-स्टैक एक्सचेंज का एक उपखंड, क्यू एंड ए वेब साइटों का एक समुदाय-संचालित समूह है।.

    प्रश्न

    सुपरयूजर रीडर एंस्ट्रेब्लैक जानना चाहता है कि उसके फोन के एसडी कार्ड के फोल्डर में 'साइज' और 'साइज ऑन डिस्क' के बीच इतना बड़ा अंतर क्यों है:

    जैसा कि आप नीचे देख सकते हैं, इस फ़ोल्डर के लिए 'आकार' और 'डिस्क पर आकार' फ़ील्ड के बीच बहुत अंतर है। ऐसा क्यों है?

    मुझे पता है कि विंडोज में आवंटन इकाइयों की वजह से 'साइज ऑन डिस्क' 'साइज' से थोड़ा अधिक होना चाहिए, लेकिन इसमें इतना अंतर क्यों है? क्या यह बड़ी संख्या में फाइलों के कारण हो सकता है?

    BTW, यह फ़ोल्डर मेरे Android फ़ोन के SD कार्ड पर है। इसके अंदर, मेरे मैप्स ऐप अपने कैश्ड मैप्स को स्टोर करते हैं, और ऐप को Google मैप्स से अपने मैप्स मिलते हैं.

    स्क्रीनशॉट को देखते हुए, निश्चित रूप से 'आकार' और 'डिस्क पर आकार' के बीच एक बड़ी विसंगति है, इसलिए ऐसा करने के लिए क्या हुआ है?

    उत्तर

    SuperUser योगदानकर्ता बॉब हमारे लिए जवाब है:

    मुझे लगता है कि आप यहाँ FAT / FAT32 फ़ाइल सिस्टम का उपयोग कर रहे हैं, क्योंकि आप उल्लेख करते हैं कि यह एक एसडी कार्ड है। आवंटन इकाइयों के संबंध में NTFS और exFAT समान व्यवहार करते हैं। अन्य फ़ाइल सिस्टम अलग हो सकते हैं, लेकिन वे वैसे भी विंडोज पर समर्थित नहीं हैं.

    यदि आपके पास बहुत सारी छोटी फाइलें हैं, तो यह निश्चित रूप से संभव है। इस पर विचार करो:

    • 50,000 फाइलें
    • 32 KB क्लस्टर आकार (आवंटन इकाइयाँ), जो कि FAT32 के लिए अधिकतम है

    ठीक है, अब न्यूनतम लिया गया स्थान 50,000 * 32,000 = 1.6 GB है (गणित को सरल बनाने के लिए SI उपसर्गों का उपयोग, बाइनरी नहीं)। प्रत्येक फ़ाइल डिस्क पर जो स्थान लेती है वह हमेशा आवंटन इकाई के आकार का एक गुणक होता है - और यहाँ हम मान रहे हैं कि प्रत्येक फ़ाइल वास्तव में एक इकाई के भीतर फिट होने के लिए काफी छोटी है, जिसमें कुछ (व्यर्थ) जगह बची हुई है.

    यदि प्रत्येक फ़ाइल में 2 KB का औसत है, तो आपको लगभग 100 एमबी मिलेगा - लेकिन आप आवंटन इकाई आकार के कारण औसतन 15x (30 KB प्रति फ़ाइल) बर्बाद कर रहे हैं.

    इन-डेप्थ स्पष्टीकरण

    क्यों होता है ऐसा? खैर, FAT32 फ़ाइल सिस्टम को यह ट्रैक रखने की आवश्यकता है कि प्रत्येक फ़ाइल कहाँ संग्रहीत है। यदि यह हर एक बाइट की सूची रखने के लिए था, तो तालिका (एक पता पुस्तिका की तरह) डेटा के रूप में एक ही गति से बढ़ेगी - और बहुत सी जगह बर्बाद कर देगी। इसलिए वे जो करते हैं वह "आवंटन इकाइयों" का उपयोग करता है, जिसे "क्लस्टर आकार" के रूप में भी जाना जाता है। वॉल्यूम को इन आवंटन इकाइयों में विभाजित किया गया है, और जहां तक ​​फ़ाइल सिस्टम का संबंध है, उन्हें उप-विभाजित नहीं किया जा सकता है - वे सबसे छोटे ब्लॉक हैं जो इसे संबोधित कर सकते हैं। बहुत कुछ आपके पास एक घर का नंबर होता है, लेकिन आपके पोस्टमैन को इस बात की परवाह नहीं है कि आपके पास कितने बेडरूम हैं या उनमें कौन रहता है.

    यदि आपके पास बहुत छोटी फ़ाइल है तो क्या होगा? यदि फ़ाइल 0 केबी, 2 केबी, या 15 केबी भी है, तो फाइल सिस्टम को कोई परवाह नहीं है, यह इसे कम से कम स्थान देगा - ऊपर के उदाहरण में, यह 32 KB है। आपकी फ़ाइल केवल इस स्थान की एक छोटी राशि का उपयोग कर रही है, और बाकी मूल रूप से बर्बाद हो गई है, लेकिन अभी भी फ़ाइल के अंतर्गत आता है - बहुत कुछ जैसे कि एक बेडरूम जिसे आप खाली छोड़ देते हैं.

    अलग-अलग आवंटन इकाई आकार क्यों हैं? खैर, यह एक बड़ी तालिका (एड्रेस बुक) के बीच एक व्यापार-बंद हो जाता है, उदाहरण के लिए, जॉन 123 फ़ेक स्ट्रीट, 124 फ़ेक स्ट्रीट, 666 शैतान लेन, आदि) में एक घर का मालिक है, या प्रत्येक इकाई (घर) में अधिक बर्बाद जगह । यदि आपके पास बड़ी फाइलें हैं, तो यह बड़ी आवंटन इकाइयों का उपयोग करने के लिए अधिक समझ में आता है - क्योंकि एक फ़ाइल को एक नई इकाई (घर) नहीं मिलती है जब तक कि अन्य सभी भरे नहीं जाते हैं। यदि आपके पास बहुत सारी छोटी फाइलें हैं, तो ठीक है, आपके पास वैसे भी एक बड़ी तालिका (पता पुस्तिका) होने वाली है, इसलिए उन्हें छोटी इकाइयाँ (घर) दे सकते हैं.

    बड़ी आवंटन इकाइयां, एक सामान्य नियम के रूप में, यदि आपके पास बहुत सारी छोटी फाइलें हैं, तो बहुत सारी जगह बर्बाद हो जाएगी। आम तौर पर सामान्य उपयोग के लिए 4 KB से ऊपर जाने का एक अच्छा कारण नहीं है.

    विखंडन?

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

    संभव समाधान

    जैसा कि gladiator2345 ने सुझाव दिया है, इस बिंदु पर आपके एकमात्र वास्तविक विकल्प इसके साथ रहना है या छोटी आवंटन इकाइयों के साथ सुधार करना है.

    आपके कार्ड को FAT16 में स्वरूपित किया जा सकता है, जिसकी तालिका आकार की एक छोटी सीमा होती है और इसलिए बड़ी मात्रा को संबोधित करने के लिए बहुत बड़ी आवंटन इकाइयों की आवश्यकता होती है (32 KB आवंटन इकाइयों के साथ 2 जीबी की ऊपरी सीमा के साथ)। ब्रह्म के स्रोत शिष्टाचार यदि ऐसा है, तो आपको FAT32 के रूप में वैसे भी सुरक्षित रूप से प्रारूपित करने में सक्षम होना चाहिए.


    स्पष्टीकरण में कुछ जोड़ना है? टिप्पणियों में विचार व्यक्त करो। अन्य टेक-सेवी स्टैक एक्सचेंज उपयोगकर्ताओं से अधिक उत्तर पढ़ना चाहते हैं? पूरी चर्चा धागा यहाँ देखें.