"आकार" और "डिस्क पर आकार" के बीच इतना बड़ा अंतर क्यों है?

Question

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

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

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

Comments

हेल्लोब्लाक, और सुपरयूज़र में आपका स्वागत है। मैंने डिफ्रैगमेंटिंग के बारे में भाग को हटाने के लिए आपके प्रश्न को संपादित किया, क्योंकि दो मौजूदा उत्तर डिस्क विसंगति पर आकार / आकार पर ध्यान केंद्रित करते हैं और स्टैक एक्सचेंज प्रारूप सबसे अच्छा काम करता है जब प्रत्येक प्रश्न पोस्ट किया जाता है। आप निश्चित रूप से एक अलग प्रश्न के रूप में फिर से पूछ सकते हैं, हालांकि मुझे लगता है कि इस सवाल पर अब तक आपको जो उत्तर मिले हैं, वे बताते हैं कि डीफ़्रैग्मेन्टेशन आपकी मदद नहीं करेगा। (यह आम तौर पर ठोस-राज्य मीडिया पर भी अच्छा नहीं करता है।) अपने प्रश्न को आगे संपादित करने के लिए स्वतंत्र महसूस करें यदि आपको लगता है कि मैंने किसी भी तरह से आपका इरादा बदल दिया है।

— एक CVn

@ माइकलकॉर्लिंग हेह, मैंने अभी विखंडन पर एक मामूली चर्चा में संपादित किया (पहले थोड़ा विचलित हो गया)

— Bob

@ माइकलकॉर्लिंग सवालों के जवाब देने के लिए आकर्षक ढंग से संपादित न करें। उत्तरों में से एक ओपी के प्रश्न के विखंडन भाग को संबोधित करता है। भ्रम से बचने के लिए आपके संपादन को पीछे ले जाने की आवश्यकता है।

— डांटेइंजेलोर

@DanteTheEgregore यदि आप बॉब के जवाब का जिक्र कर रहे हैं, जिसे वास्तव में संपादित किया गया है, तो विखंडन के प्रभावों पर भी चर्चा की जाएगी, तो बंदूक कूदने से पहले, कृपया उस उत्तर और प्रश्न पर संपादित इतिहास और टाइमस्टैम्प की जांच करें। मेरे संपादन के समय, बॉब के जवाब में विखंडन के मुद्दे को शामिल नहीं किया गया था। यदि ओपी ऐसा करना चाहता है, तो "मीडिया को डीफ्रैग्मेंट करने से" इससे मुझे मदद मिलेगी? किसी भी बकाया भ्रम को हल करना चाहिए, हालांकि मुझे अभी भी लगता है कि बेहतर रूप से एक अलग प्रश्न के रूप में पूछा जाता है; IMO दो मानों के बीच अंतर का मामला असंबंधित है।

— बजे एक CVn

मुझे लगता है कि यह ऐप गंभीरता से क्रमादेशित है - बग रिपोर्ट दर्ज करने पर विचार करें। मैं किसी भी तरह से एक पेशेवर प्रोग्रामर नहीं हूं, लेकिन मैंने एक बार JavaME में एक साथ कुछ इसी तरह से हैक किया था, और निश्चित रूप से एक समस्या जो मुझे हल करनी थी, वह थी कि उन सभी मैप मैप टाइल्स को कुशलतापूर्वक (स्टोरेज एंड एक्सेस) एक कंटेनर में कैसे स्टोर किया जाए। मैं असम्पीडित ज़िप फ़ाइलों का उपयोग कर समाप्त हो गया।

— ए। डोंडा

Answer 1

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

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

• 50,000 फाइलें।

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

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

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

---

गहराई से व्याख्या

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

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

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

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

---

विखंडन?

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

---

संभव समाधान

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

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

Comments

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

— हॉब्स

(कम तकनीकी रूप से, यह सिर्फ "ढीला" कहा जाता है।)

— हॉब्स

क्लस्टर आकार भी अधिकतम फ़ाइल सिस्टम आकार को सीमित करता है। उदाहरण के लिए, यदि आपका पता स्थान 32-बिट है, तो आपके पास कुल ~ 4.29 बिलियन संभव कुल क्लस्टर हैं। अब, यदि आप NTFS द्वारा समर्थित सबसे छोटे क्लस्टर आकार का उपयोग करते हैं (512 बाइट्स), तो आप अधिकतम 512 * 2 ^ 32 बाइट्स = 2 GiB को संबोधित कर सकते हैं। यदि आपको एक वॉल्यूम की आवश्यकता है जो 2 से अधिक GiB डेटा संग्रहीत कर सकता है, तो आपको क्लस्टर आकार को बढ़ाना होगा। यह आपके द्वारा संग्रहित किए जाने वाले वास्तविक सबसे बड़े फ़ाइल से स्वतंत्र है, बशर्ते आप किसी फ़ाइल को 2 GiB से बड़ी नहीं रख सकते जो आपकी समस्याओं में से कम से कम हो।

— एंडॉन एम। कोलमैन

4 KiB क्लस्टर आपको आकार में 16 TiB तक की मात्रा में फ़ाइलों को संबोधित करने की अनुमति देगा, जो कि भविष्य के भविष्य के लिए पर्याप्त होना चाहिए।

— एंडन एम। कोलमैन

ठीक है, वह छोटी फाइलों के अपने संग्रह को एक बड़ी फाइल में संपीड़ित कर सकता है।

— einpoklum

Answer 2

यह उन स्थितियों में से एक है जहां एक फ़ाइल में संपीड़ित / संग्रह करना मदद कर सकता है। क्या बॉब अपने जवाब में कहा कि सच है , लेकिन समाधान डिस्क reformating अन्य उत्तर पता चलता है के रूप में की तुलना में आसान हो सकता है। यदि आप निर्देशिका (ज़िप, टार, या किसी अन्य विधि का उपयोग करके) को संपीड़ित या संग्रहीत करते हैं, तो फ़ाइल सिस्टम यह देखेगा कि आपके पास एक छोटी फ़ाइल है, बजाय कई छोटी। यहां तक ​​कि संपीड़ित किए बिना आपको लगभग 1.4 गीब स्थान वापस मिल जाएगा, क्योंकि उन सभी "छोटी फाइलों" को एक बड़ी फाइल के रूप में गिना जाएगा।

इसके अंदर, मेरे मैप्स ऐप अपने कैश्ड मैप्स को स्टोर करते हैं और ऐप को गूगल मैप्स से अपना मैप मिलता है

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

Comments

> इसके अंदर, मेरे मैप्स ऐप अपने कैश्ड मैप्स को स्टोर कर लेते हैं और ऐप को गूगल मैप्स से अपना मैप मिल जाता है। - दुर्भाग्य से, इस मामले में, संपीड़न (जो प्रभावी रूप से आधार के ऊपर एक फ़ाइल सिस्टम है) को इस मैपिंग ऐप से समर्थन की आवश्यकता होगी।

— बॉब

@ याकूब को तब समाधान डेवलपर की ओर से आना चाहिए डी:

— Braiam

यह पूरी तरह सच है। मुझे लगता है कि इस समय के लिए, मुझे अपना ऐप बदलना चाहिए।

— vfsoraki

@Braiam यह केवल एक फ़ाइल है, यह सोचकर फ़ाइल सिस्टम को धोखा नहीं दे रहा है; वहाँ है केवल एक फ़ाइल। जैसा कि क्यों डेवलपर्स एक संग्रह में कैश जानकारी संग्रहीत नहीं करते हैं, यह शायद इसलिए है क्योंकि अधिकांश संग्रह प्रारूप तेज़ यादृच्छिक लेखन के लिए डिज़ाइन नहीं किए गए हैं, जिन्हें कैश की आवश्यकता है। एक बेहतर विकल्प SQLite जैसे हल्के डेटाबेस लाइब्रेरी का उपयोग करना हो सकता है।

— bcrist

बिलकुल सच ..... +1

— arundevma

Answer 3

यदि किसी को इस समस्या का सामना करना पड़ता है, तो यह जानना भी उपयोगी हो सकता है कि डिस्क पर फ़ाइल आकार / स्थान में बड़ा अंतर देखने का एक अन्य कारण वैकल्पिक डेटा स्ट्रीम (ADS) का उपयोग है

यह मेरी जानकारी में केवल NTFS पर लागू होता है। ADS को वैध और वैध उपयोग दोनों के लिए जाना जाता है:

• इंटरनेट से डाउनलोड की गई फ़ाइल को टैग करने के लिए
• मेटाडेटा को संग्रहीत करने के लिए (Microsoft Apple OS की कुछ विशेषताओं को शामिल करना चाहता था, जैसे फ़ाइल के प्रकार को निर्धारित करने के लिए फ़ाइल एक्सटेंशन का उपयोग नहीं करना)
• एक मैलवेयर के संदर्भ में डेटा या कोड को छिपाने के लिए ।

ADS बस: कोई भी NTFS फ़ाइल कई डेटा स्ट्रीम ("सबफ़ाइल" समझ सकती है) पकड़ सकती है। एक मुख्य स्ट्रीम है, जिसका उपयोग विंडोज एक्सप्लोरर और अन्य विंडोज टूल्स द्वारा किया जाता है, यह एक फाइल की सामान्य सामग्री को रखता है। वैकल्पिक डेटा स्ट्रीम में अन्य जानकारी हो सकती है, बिल्कुल मुख्य धारा के रूप में, लेकिन उन्हें सीधे विंडोज टूल द्वारा संभाला नहीं जा सकता है (विशेष रूप से एक्सप्लोरर एडीएस के आकार की परवाह किए बिना मुख्य स्ट्रीम के आकार के बराबर फ़ाइल आकार प्रदर्शित करता है), आपको ADS लिखने, पढ़ने और पता लगाने के लिए विशेष उपकरणों या कोड का उपयोग करना होगा।

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

एक और कड़ी ।

ADS के साथ सुरक्षित रूप से प्रयोग करने के लिए, DOS / CMD स्तर पर यह प्रयास करें ...

C की जड़ में फ़ाइल की सामग्री बनाएँ और फिर प्रदर्शित करें:

C:\> echo The main data stream> test.txt
C:\> type test.txt

परिणाम:

C:\> The main data stream

अब एक ही विधि के साथ एक ADS जोड़ें, बस फ़ाइल नाम के अलावा ADS नाम निर्दिष्ट करें:

C:\> echo The secret message> test.txt:secret

आपने फ़ाइल में केवल गुप्त संदेश छिपाया है। ध्यान दें कि एक्सप्लोरर में फ़ाइल का आकार एडीएस "गुप्त" में हमने बाइट्स के बावजूद नहीं बदला है।

ADS सामग्री प्रदर्शित करने का प्रयास करें:

C:\> type test.txt:secret

परिणाम:

The filename, directory name, or volume label syntax is incorrect.

सीएमडी typeएडीएस की सामग्री को प्रदर्शित करने में सक्षम नहीं है। हम इसके बजाय नोटपैड का उपयोग करेंगे:

notepad test.txt:secret

नोटपैड में हम ADS की सामग्री देख सकते हैं:

The secret message

आप एक निर्दोष पाठ फ़ाइल के एडीएस में एक पूर्ण निष्पादन योग्य भी छिपा सकते हैं, और इसे किसी भी समय चला सकते हैं। हैकर्स के लिए धन हानि नहीं करता है :-)

Comments

मैं खुद जीत-हार नहीं हूं, मेरा काम ज्यादातर लिनक्स में होता है। यह बहुत उपयोगी था। धन्यवाद

— vfsoraki

यह ADS उपयोग के लिए जाँच करने के लिए Sysinternals से स्ट्रीम जैसे उपकरण का उपयोग करने के लायक है । उदाहरण के लिए, विंडोज सिस्टम पर डाउनलोड की गई फाइलें ADS में एक स्रोत के साथ टैग की जा सकती हैं, हालांकि यह छोटी है और इसमें स्थान नहीं होना चाहिए। यह आम तौर पर dir या Explorer आउटपुट में नहीं दिखेगा। यह आपके द्वारा जांच की जा रही डिस्क उपयोग समस्या को ब्लॉक और बढ़ा सकता है। ।

— adric

Answer 4

क्लस्टर आकार के कारण समस्या हो सकती है।

Microsoft के अनुसार :

यदि आप वॉल्यूम पर निहित किसी भी फाइल या फोल्डर के लिए NTFS कंप्रेशन का उपयोग नहीं कर रहे हैं, तो SIZE और SIZE ON DISK के बीच का अंतर एक बड़े-से-आवश्यक क्लस्टर आकार के कारण बर्बाद हो जाता है। आपको एक इष्टतम क्लस्टर आकार का उपयोग करने का प्रयास करना चाहिए ताकि SIZE ON DISK मान जितना संभव हो उतना SIZE मान के करीब हो। SIZE ON DISK और SIZE मान के बीच एक अत्यधिक विसंगति एक संकेत है कि डिफ़ॉल्ट क्लस्टर आकार औसत फ़ाइल आकार के लिए बहुत बड़ा है जिसे आप वॉल्यूम पर संग्रहीत कर रहे हैं, और यह कि इसे कम किया जाना चाहिए। यह केवल वॉल्यूम का बैकअप लेने और फिर प्रारूप कमांड का उपयोग करके वॉल्यूम को सुधारने और / / उचित आवंटन आकार निर्दिष्ट करने के लिए स्विच द्वारा किया जा सकता है: IE: format D: /a:2048 (यह उदाहरण 2-KB क्लस्टर आकार का उपयोग करता है)।

अपने ड्राइव को छोटे क्लस्टर आकार के साथ फ़ॉर्मेट करने का प्रयास करें।

Comments

कहा गया है कि, किसी को क्लस्टर आकार 4096 बाइट्स से कम नहीं होना चाहिए और न ही इस संख्या का एक से अधिक होना चाहिए। 32 बिट OS उन पृष्ठों के साथ काम करता है जो (गैर-पीएई मामले में) 4096 बाइट्स के होते हैं, इसलिए गैर-एकाधिक क्लस्टर्स का उपयोग करने से फ़ाइल सिस्टम के प्रदर्शन पर नकारात्मक प्रभाव पड़ सकता है। यही कारण है कि डिफ़ॉल्ट आकार 4096 बाइट्स पर सेट है।

— रुस्लान

@Ruslan ने जो कहा, उसे जोड़ने के लिए, नई हार्ड ड्राइव में अब 4 kB सेक्टर का आकार है, और यह भौतिक क्षेत्रों के लिए फाइलसिस्टम को संरेखित करने के लिए इष्टतम होगा, और आवंटन इकाई आकार के रूप में भौतिक क्षेत्र के आकार का एक से अधिक होगा।

— बॉब

@Ruslan मेरा मानना ​​है कि आपके कहने का मतलब है कि यह दो बार 4096 की शक्ति होनी चाहिए। 12288 (3 × 4096) और 20480 (5 × 4096) महान विकल्प नहीं हैं।

— स्कॉट

Answer 5

मैं कई लोगों को एक छोटे क्लस्टर आकार के साथ आपकी ड्राइव को पुन: स्वरूपित करने की सलाह देता हूं। चूंकि यह एक एसडी कार्ड है, ध्यान दें कि कई विक्रेता NAND के क्लस्टर आकार के आकार से मेल खाने के लिए अनुशंसित क्लस्टर आकार को कार्ड को पूर्व-स्वरूपित करते हैं (सिंक में दोनों को रखना अधिकतम पठन / लेखन प्रदर्शन और पहनने के समय को कम करने के लिए बहुत महत्वपूर्ण है)

आप NAND के क्लस्टर आकार को नहीं बदल सकते (यह आपके SD कार्ड के हार्डवेयर का भौतिक गुण है)।

अपने एसडी कार्ड पर पहले स्कैंडिस्क / चॉक को चलाएं यह सुनिश्चित करने के लिए कि आकार की रिपोर्ट समस्या एक दूषित फाइल सिस्टम के भीतर नहीं है।

दूसरा, मैं आपको सुझाव दूंगा कि आप बग को Google मानचित्र देवों को रिपोर्ट करें, उनके लिए यहाँ दोष देने के लिए। उन्हें एक बेहतर भंडारण पद्धति का उपयोग करना चाहिए। इसे ठीक करने से ऐप को कम I / O और फ़ाइल सिस्टम की ड्राइवर गतिविधि के कारण कई उपकरणों पर तेज़ी से चलाने के लिए भी बनाया जाना चाहिए।

Comments

दरअसल, यह गूगल मैप्स नहीं था, बल्कि गूगल के मैप्स का इस्तेमाल करने वाला एक और ऐप था। मैंने डेवलपर को सूचित किया, और बस उन फाइलों को अपने एसडी से हटा दिया।

— vfsoraki

Answer 6

यह कई फाइल सिस्टम के साथ एक सामान्य मुद्दा है। यहां काम पर दो कारक हैं, एक फाइलसिस्टम की अधिकतम संख्या "ब्लॉक" है जो तार्किक मात्रा और भंडारण माध्यम के भौतिक प्रतिबंधों को संभाल सकता है। केवल 1 फ़ाइल को किसी भी ब्लॉक को आवंटित किया जा सकता है (फाइलें आमतौर पर उतने ही ब्लॉक लेती हैं जितनी उन्हें जरूरत होती है)। तो 64 बाइट वाली एक टेक्स्ट फ़ाइल अक्सर 4k से 32k तक कुछ भी ले सकती है, यह उस फाइल सिस्टम के ब्लॉक आकार पर निर्भर करता है, जिस पर वह रहता है।

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

चीजों को बक्से में रखने का एक नियम यह है कि आप दो असंबंधित चीजों को एक बॉक्स में नहीं रख सकते। उन्हें उसी दस्तावेज का हिस्सा बनना होगा। इसलिए अगर मुझे टेक्स्ट का एक पेज टाइप करना है, तो उसका खुद का बॉक्स होगा। यदि मेरे टाइप किए गए पाठ में इतने सारे पृष्ठ थे तो मैं इसे एक बॉक्स में फिट नहीं कर सकता था, मुझे बस एक और बॉक्स मिलेगा और जब तक मैं अपने सभी पेजों को दर्ज नहीं करता, तब तक इसमें पेजों को जारी रखना होगा। मैंने उस दस्तावेज़ के लिए उपयोग किए जाने वाले बक्से और उसे क्रम से पढ़ने के लिए बक्से के क्रम के नीचे भी लिखा होगा।

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

तो उस स्थिति में मेरा एक पृष्ठ दस्तावेज़ अभी भी एक बॉक्स पर कब्जा करेगा, और कुछ भी इसे साझा नहीं करेगा।

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

Answer 7

क्लस्टर आकार के अलावा, आपको निम्न स्थितियों के कारण भी विसंगति हो सकती है:

• संपीड़ित या एन्क्रिप्ट की गई फाइलें तार्किक फ़ाइल आकार की तुलना में एक अलग स्थान का उपयोग कर सकती हैं।
• लिंक की गई फ़ाइलें तार्किक फ़ाइल आकार के लिए फ़ाइल के आकार के लिंक की संख्या की n बार रिपोर्ट करेंगी , लेकिन आमतौर पर उपयोग की जाने वाली भौतिक जगह कम होती है।

Comments

आम तौर पर, यह सच हो सकता है। लेकिन मेरे मामले में, उच्च आवंटन इकाई समस्या थी।

— vfsoraki

हाँ, मैं विसंगति के अधिक संभावित कारण बताकर उत्तर में जोड़ने की कोशिश कर रहा हूं।

— आर्किमिडीज ट्राजनो

Answer 8

आपको विकिपीडिया में ब्लॉक सबलोकेशन एंट्री पर एक नजर डालनी चाहिए। वास्तव में आपके साथ यही हो रहा है। टेल पैकेजिंग के लिए समर्थन के साथ एक फ़ाइल सिस्टम का उपयोग करना आवंटन क्लस्टर आकार को बदलने के अलावा इस समस्या के लिए एक फ़ाइल सिस्टम स्तर समाधान है।

सभी को डिस्क को पुन: स्वरूपित करने की आवश्यकता की असुविधा है।

कुछ मामलों में केवल उन फ़ाइलों को एक संग्रह में संग्रहीत करना समस्या को ठीक करेगा (और फ़ाइलों के अंत में खोई जगह को रोकने के साथ छोटी फाइलें भी संपीड़ित होंगी)। इससे अपघटन के लिए कुछ समय बिताने की असुविधा होती है।

एक अन्य विकल्प यदि आपके पास कुछ विशिष्ट एप्लिकेशन संबंधी समस्या के कारण बहुत सारी छोटी फाइलें हैं, तो किसी अन्य विधि का उपयोग करके अपने सॉफ़्टवेयर डेटा को संग्रहीत कर सकते हैं (डेटाबेस में हो सकता है)। लेकिन निश्चित रूप से यह प्रोग्रामर के लिए एक समाधान है, अंत उपयोगकर्ताओं के लिए नहीं।

http://en.wikipedia.org/wiki/Tail_packing

Answer 9

मैंने एक व्यक्तिगत फ़ाइल पर विंडोज 10 में विशाल फ़ाइल आकार की विसंगतियों का उल्लेख किया है, लेकिन अगर मैं उसी स्थान (एक नेटवर्क ड्राइव) से एसएएमई फ़ाइल के गुणों को देखता हूं, तो विंडोज एक्सपी के साथ, बड़ी विसंगति नहीं होती है; बस एक छोटा सा अंतर है, जो आप उम्मीद करेंगे। मुझे लगता है कि विंडोज 10 में एक बग है। 449MB की एक फ़ाइल शायद 3.99GB नहीं लेती है, जो कि विंडोज 10 मुझे बता रही है।

Comments

सिर्फ एक FYI करें, सवाल का विंडोज़ 10 से कोई लेना-देना नहीं है। OP विंडोज़ 7 का इस्तेमाल कर रहा है।

— TheKB